Issue getting cryptomatte working with vray proxy

I have a simple hierarchy of cubes which I’ve exported as an alembic from maya. I’m reading that .abc file back into maya with a vray proxy node. My cryptomatte is set to “sub object name” (which I believe should give a working crypto pass with a vray proxy), but I still get a single value for all the geometry in my file. Am I on the right track? Is there anything else I need to do?

Using
V-Ray v6.10.00 and Maya 2023


Pretty sure those boxes are instances, which as stated in the docs, won’t receive separate ids with the Sub object name ID type.

Hi, yes I saw that as well. No they are not instances. I’ve attached a maya file if you want to take a look.
vray_proxy_crypto_v001.zip (12.2 KB)

Ok, here’s what’s going on (it took us a while). It seems that when exporting identical objects, even though they are not instances, Maya exports them as such (no checkbox for this). If you export three random objects in a similar fashion, you’ll notice that the cryptomatte is correct. You can fix the cubes as well by disabling instancing in the VRayProxy settings (VRayProxy> Alembic proxy parameters > Instancing > None). This explains why exporting .vrmeshes works as expected, too.

Hey there, sorry just getting back around to this. Thanks for the tip about instancing, that does fix the issue in that example file.

There is a second issue however. If I apply a displacement to the vray proxy, it breaks the crypto and it’s treated as one object. And if I subdivide the vray proxy using the subd attributes on the vrayDisplacement node, it also breaks. It’s worth noting I can use the vray proxy subdivision tick box, but then I believe I lose the control over view dependent tessellation. I can work around the subdivision issue, but it would be great to sort out the displacement bit.

I’ve attached an updated example file if you want to take a look.
vray_proxy_crypto_v002.zip (12.9 KB)


This is a known bug (internal bug-tracker id: VMAYA-11744). I’ll notify the project manager about prioritizing it.

Great, thank you

And I have to ask… is there an eta for a nightly with this fix? We’re in a bind without it at the moment.

Sorry to say, no. Judging by the dev’s comment that the issue is more complex than it seems, it will take some time.

EDIT: The following might suffice as a workaround. It is possible to bake the displacement/subdivision to a .vrmesh. Using this method instead should bypass the Cryptomatte issue:

1. Set this piece of code as a Post Translate Python Script (Render Settings >Common> MEL/Python callbacks)


from vray.utils import *

node=findByName('pCubeShape1@node')[0]
node.set('bake_subdiv_filepath', 'C:/Users/Alexander/Desktop/baked.vrmesh')​

2. Replace pCubeShape1 with a geo of your choice. If you are uncertain about the name, export a .vrscene, open it via Notepad, and search for “node” until you find it.
3. Make sure you use “/” instead of “” in the path.
4. Render
5. The .vrmesh should be in the selected folder

Note: It might be a good idea to turn the displacement’s view dependent off, and choose a suitable subdiv/edge length instead.