What part of the workflow do you have difficulties with? I’d be interested to know if there’s something we could improve.
Well, the difficulties lie in the added inefficiencies that appear for us when doing it. If that workflow had been amazing then one would wonder why the vray proxy setup was created in the first place 
When “referencing” an alembic cache into Maya, it basically means that Maya is converting it to “Maya Geometry”, with a alembicNode loader for the dynamic geometry.
Vray proxy nodes makes for very small and clean render scenes, whereas alembic references becomes way more “complex” (in comparison) with thousands more nodes being loaded in the DG (including Maya alembicNodes and their connections)
I also slightly distrust the stability of the setup because of that complexity, though sofar its been ok.
We do want to occasionally dial assets into that mode (if the lighter feels the need to do local setups on individual geometries), but it should only be on a absolutely need to basis.
The primary issue appears when we want to render and we export our vrayscenes for the farm, each frame becomes silly big because it needs to translate the Maya geometry for all our assets on the specific frame.
Somewhat duplicating the data that is available in the alembic caches already. Using the vray proxies our vrayscene exports are extremely small, but with the maya geometry they grow into the hundreds of mb.
Assets which are animated but only at a top-transform level is basically a vrayproxy of the static mesh with transform animation, so on disk its only a single instance of the geometry.
With the vrayscene exports for rendering the full geometry then gets duplicated out each frame.
I guess we could do the vrayscene export into a single file to avoid the duplication, but im afraid that it will become way to big when we have deforming geometries on assets, and Im unsure of how efficient Vray is at random-access loading a scenefile to only get the current frame?
We could also go back to “rendering though maya” to get rid of that issue but that kills flexibility on the farm and adds the overhead of Maya (both in terms of memory and time to load maya itself)
Another thing that seems to work well with the vray-proxy setup is the distributed rendering (or even distributed RT) that our lighters and shader artists make use of.
Seems that Vray proxy nodes allows the host to only send very little data to the slaves(info about the proxy), and then each slave loads the geometry directly from the fileservers(which can push out a lot of data quickly).
With Maya geometry the host machine becomes a bottleneck, because all the geometry needs to be sent out to the slaves.
When using vrayproxy setups for an asset we also make use of Maya gpu node for preview in the viewport (seems more efficient than the gpu mode on the vrayproxy for some reason, but either could be used for my point here).
That allows us to do a viewport abstraction to the raw render material, allowing for us to have very lightweight viewports for our lighters, speeding up their interactions and scene loading.
Maya-alembic references does not allow that in any easy or efficient way and therefore the full render LOD material needs to be loaded.
So, we just want our workflow to be as light and streamlined as possible for the majority of the time, and then only when issues arise we revert down to more brutish methods.
This is still not working, although it’s on the to-do list. It won’t be easy to get it done, according to the devs, but it’s not impossible. There’s work being done on some cryptomatte issues at the moment and hopefully one of the next things related would be to get it working its way down into the proxy. I’ll make a note to keep everyone in this thread in the loop.
Again, as mentioned. The less complicated part (from what I can only assume admittedly ) with having at least material cryptomatte working with the MtlMulti setup would get us a long way and would cover a large part of masking scenarios we have. Is that part also hard/complicated, or could that be a step one?
The full integration would off course always be most desirable.
This was added at some point before 3.60.04, I was just mentioning that it works there (for certain) but I had not checked what version exactly had the initial support for it. But this should be all working now.
So, the scenario where we would use it is if we have a “location” asset that consists of hundreds of “sub-assets”. In this case we would like to render out a vrayscene so that we have containment of shaders and geometries into a single node/file.
Unfortunately our set/location assets are are built up of proxy nodes and then that part becomes a bit of a blocker again.
We could post export change all the assets to be maya geometry and then do the export (which again adds to the diskspace used) but thats again less “elegant” to some extent.
Hope this all makes sense.
Jimmi
