Cryptomatte support for VrayProxy and VrayScene nodes

[Jimmi]

Hi Guys.

I have had this issue in the ChaosGroup support system since the CryptoMatte feature was released, but I hope you don't mind if I now also make a forum ticket on the matter.
Its easier to keep track of this than the emails and I figured that it was a big enough feature request to warrant some community interaction.
(I also made a brief comment on it in another thread, which I wanted to avoid derailing more than I had already, https://forums.chaosgroup.com/forum/...102#post964102 )

We were very! exited by the the new CryptoMatte feature and it had the potential to ease our workflows considerably on the "matte" front.

Unfortunately the current implementation of the CryptoMatte system, doesn't support Vray proxy nodes nor does it support VrayScenes.
A proxy node will come out with a single color in the Cryptomatte passes, both for "shaders" but also for "geometry" modes.

That is a slight drawback for us, as all our assets are rendered as Vray Proxy(alembic) and we would also be using vray-scenes(static assets with only transform animation) if it was not due to our existing way of handling per asset matte elements.

So, I would like to raise my hand on this point again, but I would also be happy to hear if I'm the only person out there with this particular problem.

Our current way of handling masks are on a per asset level where we define ObjectSelect(using materialID) render-elements within our asset building phase which then gets exported and then later on brought into the lighting scene with the assets.
That does tend to create a tonne of elements and quickly gets out of hand if the lighter is not on top of things.
Alternatively we could be doing a framework for the lighters so they could easily create the elements in the lighting scene, but that will also take a fair amount of time and will probably end up being "complicated.

CryptoMatte would really save our asses here (especially with the full hierarchy which would allow us to separate assets easily within our Nuke frameworks).

A small plea from us here, would be an awesome feature to have available.

[vlado]

It is on the "to do" list to circumvent this limitation for proxies and VRayScene nodes. Let me know how urgent it is and we'll see what can be done about it.

Best regards,
Vlado

[Jimmi]

Hi Vlado.

For us at the company, this fix/feature is at the moment the most important thing we could wish for in VRay.
Being able to avoid our current need for all the matte elements though a method like cryptomatte would free up a bunch of other options for us that I have been wanting to roll out in our frameworks for quite a while now.
Like using vrayscenes for instance, where we havent really found a way to handle mattes and therefore cant use them.
Also, it would make our workflows and frameworks much more elegant and simple, which then in turn would allow us do even more elaborate scenes and shots.
If we had it within the next month or so then I have a couple of projects I would love to deploy it on as soon as its made available.

My hope was that putting it all out here on the forum would have other people raise their hands also.
In the hope that it would also be a priority for them and therefore could contribute to raising the priority on it for you guys.

[hypotheticalinc]

I second the vote that this would be a really huge improvement! We use Max here, but hopefully any base code for Maya would translate? Definitely at the top of our list of things we'd like to see next in Vray.

Cryptomatte as it is gets us about 50% towards not having to use Multimatte and the attendant changes and mistakes that come up in a fast moving project. Being able to have Cryptomatte "reach in" to vrayproxies and multimaterials would pretty much eliminate that headache for us entirely.

[vlado]

This is already working in our internal builds, so hopefully it will be out soon.

Best regards,
Vlado

[Jimmi]

This is already working in our internal builds, so hopefully it will be out soon.

Best regards,
Vlado

That is some very sweet music in my ears! If you give us a heads up as soon as its in the nightlies and I will immediately test it on our scenes and setups.
( random note on nightlies, I been noticing that there is barely any diff between the release nodes of the latest build and one from around 3.6002. Any reason for that? I usually check in on a regular basis to see if there are any upcoming things, but its been unusually quiet since then )

[Fredrik Averpil]

This is something which was requested here internally as well. Very nice to hear about this!

[TheScope]

I would like to add my vote for Cryptomatte support of vrscene and Vray proxies. We rarely have a scene that is not using them.

Cheers, Florian

[Buck]

Same here, proxy/vrscene support is the last thing we need to go full crypto matte and get away from hand-placed matte IDs. can't wait!

[Jimmi]

This is already working in our internal builds, so hopefully it will be out soon.

Best regards,
Vlado

Hi Vlado.

Hope you guys have had a some well deserved rest/partying over the last week and my query here is in no way an expectation of things having happened over the holidays.

But I would like to ask if you could give any further updates on this matter?
We have a few projects that we would really love to apply this setup to, and I would also love to just give it a spin though the nightlies as soon as possible.
I know its not been that long since my last query, but I'm really exited about getting this.
Also I didn't really get any good Christmas gifts this year and the child in me still has one last hope for getting one.

Thanks,
Jimmi

[Jimmi]

Hi Guys.
Sorry to be nagging on this, but can I give this a little bump in a try to get an idea of when it might be available, would really love to start using it fully in our scenes?

[Jimmi]

So, I figured it was about time for me to do another "bump" on this.

We are about to start on a new batch of projects soon and I would as always really love this part of our workflows fixed.

We use the cryptomatte a fair bit now and can at least separate out the individual assets though the crypto-matte setup(each in their own proxy/vrayscene).

But it hurts my soul every time our lighting artists brings our assets into a mode(in our frameworks) where we load our alembic caches as a Maya reference in order to be able to get cryptomatte for the individual pieces of geometry/shaders.
Also, from a workflow point of view, it goes back to the depressing setup of having to do extra iterations between the lighting and comp people JUST to get another mask/matte in.

Is there any news on this? Please?

[yolov]

The latest V-Ray 3.60.04 for Maya should work with VRayScene nodes, as long as the vrscene itself contains the scene_name parameter in its plugins (it may as well be in 3.60.03, but I haven't checked that).
So VRayScenes should work now. As for referenced files - the "Asset (reference scene) name" mode of the Cryptomatte should take care of this (let me know if there's a case where it doesn't).
The only thing that we haven't solved yet (since it's quite complicated) is a proxy that contains multiple objects within a single file in the node name mode of the cryptomatte. It works if each object has a different material with the material name mode, but without anti-aliasing.

Which of these issues is the one that's holding back your workflow? Or is it a different one?

[Jimmi]

I will check up on the VRayScene stuff in 3.60.04, as there as been no mention of it in the changelogs since I last tested I didn't figure there would be any updates on that front.

Referenced files (or in our case alembic caches "referenced" in though Maya) works just fine as you mention, and its our fallback mechanism in our frameworks to get cryptomatte data for our assets. But its a terrible mode to dial in for us in terms of efficiency.

As mentioned in previous posts, what we would like to do is to have an alembic cache(static or "dynamic" for animation) loaded though an VrayProxy node (so single file containing many geometries) with materials assigned though the vrayMeshMaterial shader.
As far as our tests have shown, no modes or setups on the cryptomatte works down "into" the proxy.
The ideal thing would be to have "node-name with hierarchy" working with the proxyNode name being part of the full name, and then also off course the material name mode based on the assignments happening through the vrayMeshMaterial.

I can see that the delayed loaded geometry might give cause to some complexities, but perhaps the vrahMeshMaterial setup ( MtlMulti plugin I believe its called ) could be handled since everything on that front is predeclared?
Just having that part supported for the cryptomatte would get us quite far along the way.

Vlado did in a previous post hint that it was working in the internal builds, but I gather that you guys hit a few walls along the way.?

Its been over 4 months since my initial query(both here and though support channels) and my hope has so far been that it would be resolved at some point within a not to distant future.
A heads up saying if it wont be would be great, then I can start looking into other solutions for how we might handle those things in our setup.

[yolov]

I will check up on the VRayScene stuff in 3.60.04, as there as been no mention of it in the changelogs since I last tested I didn't figure there would be any updates on that front.

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.

Referenced files (or in our case alembic caches "referenced" in though Maya) works just fine as you mention, and its our fallback mechanism in our frameworks to get cryptomatte data for our assets. But its a terrible mode to dial in for us in terms of efficiency.

What part of the workflow do you have difficulties with? I'd be interested to know if there's something we could improve.

As mentioned in previous posts, what we would like to do is to have an alembic cache(static or "dynamic" for animation) loaded though an VrayProxy node (so single file containing many geometries) with materials assigned though the vrayMeshMaterial shader.
As far as our tests have shown, no modes or setups on the cryptomatte works down "into" the proxy.
The ideal thing would be to have "node-name with hierarchy" working with the proxyNode name being part of the full name, and then also off course the material name mode based on the assignments happening through the vrayMeshMaterial.

I can see that the delayed loaded geometry might give cause to some complexities, but perhaps the vrahMeshMaterial setup ( MtlMulti plugin I believe its called ) could be handled since everything on that front is predeclared?
Just having that part supported for the cryptomatte would get us quite far along the way.

Vlado did in a previous post hint that it was working in the internal builds, but I gather that you guys hit a few walls along the way.?

Its been over 4 months since my initial query(both here and though support channels) and my hope has so far been that it would be resolved at some point within a not to distant future.
A heads up saying if it wont be would be great, then I can start looking into other solutions for how we might handle those things in our setup.

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.