VrayMultiSubTex for MaterialID

[thablanch]

As the title says. VrayMultiSubTex for MaterialID
We are already using using this map for generating masks based on Gbuffer, as it allowing us more flexibility in our pipeline than MultiMatte or more ontrol than the VrayMtlID.
I don't know if it is a low hanging fruit or if it would be helpful for other's pipeline, but would be a nice little add-on on our side.
Thanks!

[hermit.crab]

Could you please elaborate more on why you think 'material ids' in the VrayMultiSubTex are more flexible than the already existing methods of mask generation (multimatte, vraymtlid, cryptomatte, etc.)?

Could you explain what exactly are you trying to achieve and maybe provide a sample scene/screenshots that illustrate your desired effect?

[thablanch]

Hi Aleksandar

You will find attached a sample rps file, the one we actually use.
Also attached, the Photoshop automated masking system we are using to work with the provided render elements. (sample of 'automated' rgb masking)
And the link to the kind of images we are doing; https://www.ski-doo.com/ca/build-and-price.html

It is working quite fine, and we are happy about it, but hey, the thread is called wishlist

First of all, my goal is to have this for a mass production tool, as we produce thousands of 'very similar' images.

The things that's not working for us;
Cryptomate; Cant' use as we are working with Photoshop in post-production
VrayMtl ID; Generate tons of unprecise and random colors. we are after RGB channels to use them as masks. Also, not consistent when adding new objects. Therefor VrayMtlID is not applicable.

You will see, in the rps file attached, that we are using both, multimatte and VrayMutliTex. We are using multimatte only for the stickers. This workflow is 'object based'
Which means we are adding an Gbuffer / objectID to the objects;

We are working with xref material libraries, we got quite a few materials. We would be able to pre-assing all the ID - this would help us greatly for the uniformity of the production. It would push the info directly, and we could script the reading of the different present ID and push them in the VrayMultiTex ( thing we could also do with the multimatte, I agree)
With a VrayMutliTex, this allows to have the required data in the material directly, works better with stickers/decals (doing automotive), can have more than 3 channels if required, better understanding by the team of artist as it is a very simple material and not a render element (would become one, but not directly in the workflow for the user)

All that we are now using as object ID now, we were with multimatte before, and now it is just simpler for the team as a VrayMutliTex. Guess it all comes down to the ease of use.

That's the Idea. As mentioned, it's far from being a showstopper, would just be a nice little add on. However, if nobody else would benefit from this, there's no use.


Thanks

[hermit.crab]

Thank you for the provided information.
My colleagues and I had a discussion regarding your suggestion, however, we are still unconvinced as to why the VRayMultiTex approach is more convenient than the MultiMatte.

We understand that it can hold more than three colors, but since you would need to make selections from the channels (since you said that you are after RGB channels), colors different than RGB would be present in multiple channels, hence making them a less accurate for selections. One can argue that MultiMattes are even easier to use since all the parameters are present in the render element itself, rather than in a texture that you need to access through the material editor.

Also, could you clarify this sentence: "With a VrayMutliTex, this allows to have the required data in the material directly, works better with stickers/decals (doing automotive)"?
Are you using the VrayMultiTex for multiple purposes? What do you mean by 'works better'?

If it's possible could you please prepare and send us two sample scenes - one with a VrayMultiTex approach and one with a MultiMatte approach, so that we can compare them?

[thablanch]

Hi

For 'material directly' = saying that working by meterial ID versus object ID would lead us to more flexibility
For: one can argue that multimattes are easier = I do agree, but in the studio here people are more used and confortable with material than render elements.
I'll prepare the scenes shortly.

Thanks!

[dans]

I had a look at the files.

I see your are replicating the behaviour of MultiMatte elements via using VrayMultiSubTex inside a VRayExtraTex render element. The things I can think of that makes this approach more flexible than using simply a MultiMatte:
- combining multiple IDs into the same render element R/G/B channel (e.g. IDs 4,5,6 all go into Red)
- do complex masking/mixing if you nest the VrayMultiSubTex deeper inside other maps (to e.g. get ID 4 from object A into Red channel, but ID 4 of object B into Green)
Overall seems quite complex, highly specialized and the example render preset didn't show a use case benefiting from that so far.

A note about Material Effects IDs: The Effects-ID is decided upon at render/shading time and can be overwritten at any higher level in the shading tree. If it is set to 0 (the default) in a map/material then this map/material just passes through any ID assigned set at a deeper level. So an Effects-ID assigned at the material level will overwrite any ID set in a map assigned inside it for example.
For VRayMultiSubTex to support the Effects-ID, it would need to compute it first, since it is not directly related to the shaded geometry. So it is quite different form all the other modes VRayMultiSubTex provides so far (which are per object/geometry based). VRayMultiSubTex would need to provide and evaluate an additional map input for this feature (or maybe could abuse the default color map slot for this).

psd-manager can also extract masks based on Material-Effects-ID directly from the 3ds max G-Buffer (supported only by V-Ray CPU bucket rendering). You would just enter the Effects ID numbers you want (e.g. "1-100") and get all masks as PSD layers. To support your smart object linking workflow you would need to extract the created PSD layers into separate image files (since Photoshop can not link to a specific layer, like After Effects can). You would not to be limited by memory/number of render elements anymore. If your automotive stickers/decals are just mapped as textures and not modelled as geometry then render elements will provide better edge anti-aliasing.

Daniel