Ability to recognize and export Alembic geometry directly from maya

[Zach Gray]

2. Regular Alembic import loses the connection between a given mesh and the .abc file and Alembic object that it was imported from.

So, for 2. not only would you have to specify which Alembic file generated a given mesh, but also *which* mesh it is in the file, so that we can do a proper multi/sub-object material.

Right. I see your point. I was thinking you only needed the .abc file, but the alembicNode only outputs an array of mesh data. It probably wouldn't be safe to assume that the name of the mesh is the name of the mesh in the .abc file, but it does appear that the imported mesh name is generated from the .abc file.

Looking at the alembic source for the may plugin on the alembic site, it's just populating the 'mOutPolyArrayAttr' numbered with the mesh data with their readPoly function. We'd need to add another linked string array, and modify the plugin, which brings it's own set of problems.

What about the python bindings? Can we get the name by searching through the archive, as shown here?

http://docs.alembic.io/python/examples.html

And finally, would this be feasible to do in the post translate .py? I could check for an attr, and dig up the mesh names myself, if I knew how it needed to be formatted in the .vrscene.

[vlado]

What about the python bindings? Can we get the name by searching through the archive, as shown here? http://docs.alembic.io/python/examples.html

You probably could, but I don't think this has anything to do with V-Ray specifically. You should be able to load the Python module on its own.

And finally, would this be feasible to do in the post translate .py? I could check for an attr, and dig up the mesh names myself, if I knew how it needed to be formatted in the .vrscene.

Certainly, you can do that. You'd have to create a MtlMulti plugin with the material for each mesh and that's pretty much it.

Best regards,
Vlado

[Zach Gray]

Here is what I'm seeing in the exported file. This alembic file has 15 meshes.

From my hacking on the .vrscene file, if I just attach a MtlMulti, it's assigned by index. It looks like order for MtlMulti is the same as the mesh output array from the alembicNode.

So I think I could figure out the shader/mesh relationships, then build a MtlMulti in the post translate. Then vray could skip the full geo export for those files. I'm not sure how custom render stats for geo would be handled...that will take more testing.

GeomMeshFile latigoShape@mesh3 {
  file="P:/..../Finaling/Geocache/Alembic/Latigo_Rig.Latigo_cacheFlowSet/Latigo_Rig.Body_cacheFlowSet.abc";
  smooth_uv=1;
}

MtlMulti latigo_vraymeshmtl {
  mtls_list=List(
    VRayMtl1@material,
    VRayMtl2@material,
    VRayMtl3@material,
    VRayMtl4@material,
    VRayMtl4@material,
    VRayMtl4@material,
    VRayMtl4@material,
    VRayMtl4@material,
    VRayMtl4@material,
    VRayMtl4@material,
    VRayMtl4@material,
    VRayMtl4@material,
    VRayMtl4@material,
    VRayMtl4@material,
    VRayMtl3@material
  );
  ids_list=ListInt(
    0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15);
}

Just to confirm, there isn't a way to read a .abc file once, and then have @mesh# access to it's individual sub-meshes for render stats and geometry settings? For me, that would be the best of both worlds for characters.

So you could have:

pointerToOpenedCache="P:/..../Finaling/Geocache/Alembic/Latigo_Rig.Latigo_cacheFlowSet/Latigo_Rig.Body_cacheFlowSet.abc";

GeomMeshFile geoShape@mesh3{
    file=pointerToOpenedCache;
    index=0;

GeomMeshFile geoShape@mesh4{
    file=pointerToOpenedCache;
    index=1;

I did discover something quite by accident! Your VRayMesh node reads .abc files just fine! And it publishes the shape names in the VRayMeshMaterial node! That's pretty great! I'm still thinking about how that impacts our current workflow.

By the way, having the scene export in .1 seconds vs 1 second per frame... awesome! (Using GPU cache for testing)

[vlado]

I'm not sure how custom render stats for geo would be handled...that will take more testing.

Render stats in V-Ray are done through materials, so it should be perhaps not too hard to implement them, if you need it...

Just to confirm, there isn't a way to read a .abc file once, and then have @mesh# access to it's individual sub-meshes for render stats and geometry settings? For me, that would be the best of both worlds for characters.

For the moment, this is not possible (but it may be in the future; we'll see).

I did discover something quite by accident! Your VRayMesh node reads .abc files just fine! And it publishes the shape names in the VRayMeshMaterial node! That's pretty great!

Of course it does that's how we implemented the direct rendering of GPU Alembic caches - internally we just create a proxy for it.

Best regards,
Vlado

[Zach Gray]

Of course it does that's how we implemented the direct rendering of GPU Alembic caches - internally we just create a proxy for it.

Well, it's working great for regular alembic files too!

I'll probably develop reading the .abc files as proxies and re-write our shader hookup to work with the MtlMulti. Then I'll probably build something where the artist can use the alembic node if they need something more specific in the scene.

As far as gaining more control over the sub-meshes in the alembic file, I think the main efficiency would be in tweaking displacement settings. For organization/simplicity, say you wanted to have a single .abc for all the clothing, but only the coat needed high subdivs for displacement. Obviously you could write out a separate cache, (and that might be the right thing to do), but having that granular control seems nice. So the other way to think about this would be handling displacement like a MtlMulti - something that splits control for the mesh without splitting the mesh itself.

I guess we are really talking about complex scene assembly... katana is too complex for what I'm working with at the moment, but at some point, a tool like that would probably address most of these issues.