Material IDs for MultiMattes

[aweidenhammer]

I'm wondering why material IDs are placed on Shading Groups, and not the materials themselves. For that matter, why not have a matID rollout on all vray Shaders?

SG's get wiped, and reassigned all the time, so we commonly find our scenes that were carefully set up to spit out MultiMattes break, when someone reassigns materials. same material, but might be disconnected for one reason or another, then reconnected, making a new SG without the ID.

Another example: vray blend materials... we can't assign matID's to the shaders being blended, only the root itself. This forces us to create custom passes, or custom extraTex passes. Not a deal-killer, I'm just wondering what the logic of the id being assigned to the SG is... when it seems more useful to assign it to the shader itself.

Andrew

[caligra]

I second that We are using material IDs all the time, but suffer from the SG node problem .. An even better solution, for us, would be that the render element for material ID just automatically extracted the materials, without the need for us to input certain numbers and colors.. Its only in very rare cases where I have had the need to assign a certain color to an ID pass.

[waaazoo]

I second that We are using material IDs all the time, but suffer from the SG node problem .. An even better solution, for us, would be that the render element for material ID just automatically extracted the materials, without the need for us to input certain numbers and colors.. Its only in very rare cases where I have had the need to assign a certain color to an ID pass.

I totally agree with that ! would be much more handy with automatic assignement, and maybe the possibility to specify when needed.

regards

[vlado]

There is no particular reason for this; will make a note to allow adding the attributes to any material.

Best regards,
Vlado

[Metzger]

I also want to bring up that there are serious problems with Proxies loosing Material ID's because of Shading groups, and groupings of objects and how a proxy is created. Also referencing a proxy, then referencing that scene of a referenced proxy has a lot of issues. I think the problem might be with using a scene that has material ID's and shaders from older builds of vray for maya. Previous vray build content do not seem to play nice with newer vray builds.

[pechart]

+1 for bringing the IDs to the materials! And maybe it would be make the attribute "smart", so when added it takes the next free integer by default.

[vlado]

I also want to bring up that there are serious problems with Proxies loosing Material ID's because of Shading groups, and groupings of objects and how a proxy is created. Also referencing a proxy, then referencing that scene of a referenced proxy has a lot of issues. I think the problem might be with using a scene that has material ID's and shaders from older builds of vray for maya. Previous vray build content do not seem to play nice with newer vray builds.

You can actually connect shading groups to the VRayMeshMaterial for a proxy object - this will correctly preserve the material IDs. The incompatibility with older builds is unfortunate, but it was required in order to solve some of the issues you mention - e.g. you have to use the VRayMeshMaterial, rather than the dynamics attribute approach that we used before, if you want to use proxies from a referenced scene.

Best regards,
Vlado

[ultrasonic]

Just for the protocol: COUNT ME IN

It would be nice to have an multimatteId and materialId on the shader itself. These IDs could then be overriden by the SG if the attribute is present there as well (also for backward compatibility) But in general i would also think that it would make a lot of sense to have these attrs on the shader.

cheers
Oli

[aweidenhammer]

Just a note about automatic assignment. I would not necessarily want that, as our comp folks would like to keep the assignments the same across iterations of renders. Anything automatic might change the id assigned to a particular material. That would result in the color changing, and the comp script to go invalid, thus requiring constant updates on their part. Once an id is assigned, it should never change, unless the user changes it. There may be a way to automate this, but it's kind of trivial to write a script to assign id's. We actually have a crude script that does this, but I'll be happy to modify that script once id's can be assigned to mats

[pechart]

Okay, good point aweidenhammer. If it breaks something, then we'll just do it with scripts.

[jensl]

You can actually connect shading groups to the VRayMeshMaterial for a proxy object - this will correctly preserve the material IDs.

Wow, Vlado this is great! I got this working by connecting VRayMaterial1SG.message to proxy_vraymeshmtl.shaders[0]. It seems you have to use the connection editor to get it to work, but that can be scripted.

What about a separate autoMaterialID render element that is linked to when the shader is created / added to scene. So it just keeps counting up as shaders are added. The same issue happens with renderID, where the colors change as the scene does, I wish this was lockable. Importing shaders would disrupt autoMaterialID, but apart from that it'd be a separate tool with no setup time to use with the coverage pass, and it wouldn't mess with multimattes.

Nice points Andrew - we've also had issues with blendMtls and mattes. I like the idea of material IDs on the shader, with material IDs on the SG overriding that.

[vlado]

Wow, Vlado this is great! I got this working by connecting VRayMaterial1SG.message to proxy_vraymeshmtl.shaders[0]. It seems you have to use the connection editor to get it to work, but that can be scripted.

You can also connect the VRayMaterial1SG.surfaceShader attribute (it fact, V-Ray does not care what is actually connected, just that a connection exists).

We will enable the material ID attributes for all materials in any case.

As for the auto-assignment, the attributes can certainly be initialized with some random values (the material ID color at least) when they are created - I don't think this will break anything.

Best regards,
Vlado

[ultrasonic]

Seems that this request made it into the latest nightly....will test it asap!

cheerio