Binding attributes in shaders with input nodes at /mat level

   1652   1   3
User Avatar
Member
1 posts
Joined: Dec. 2013
Offline
Several times since H16 I've run into problems getting geo attributes into shaders and back out into mantra planes, so much so that I feel like there's either a bug or at least something deeply confusing about how the /mat context wraps the ad-hoc connected nodes into VEX. I wonder if anyone could help out figuring how it works… I've already watched Kai's masterclass several times

Here's an easy example:
https://www.youtube.com/watch?v=xIQUbnIxoXI [www.youtube.com]

As soon as a node is plugged into the input of the principled shader, the Bind inside which fetches the rest attrib from the geo stops working, so the noise displacement swims. A similar thing happens with material overrides created with the Material SOP: the override of basecolor stops working as soon as a node is connected to a shader input.

I can see from the generated VEX that UVs are special-cased and extra prologue code is added to pass them into the body even when it's wrapped up inside an auto_mat surface shader - but is it expected that other Binds will just not work?

Other confusions have arisen from the same root cause of being unsure what the actual generated shader contains when there's a network of /mat nodes involved:
1) Using $F in file paths for texture nodes at /mat level doesn't work because they're not top-level shaders - understandable if they're inside a material builder but a bit weird given that $F works in the principledshader file parms
2) Bind Exports inside material builders don't always work if nodes are plugged in at top level
3) Bind Exports floating free in /mat are included in every shader along with whatever nodes feed them - I love this because I can set up AOVs for the whole scene at once and not have to unlock every shader and paste them inside but it's a little unexpected. I've noticed this generating some weirdness if a Bind Export is fed by a material builder output parm - the entire VEX of that material builder then seems to be dragged into every other shader in the scene along with the Bind Export!?

My workaround has been to add a Parm for each attrib I want to bind inside the material builder, then plug a Bind node into that new input at top level. Or to keep everything inside material builder nodes with no connections at /mat level, but I might as well use /shops in that case Is the answer to always use Parm now instead of Bind? I'd only just gotten over the switch to Bind from H12.5 or whenever it was!

Any illumination is welcome…

Attachments:
mat_bind_confusion_v01.hiplc (409.2 KB)

User Avatar
Member
18 posts
Joined: April 2018
Offline
I think your observations are correct, and probably make sense considering the behaviour of certain nodes when they do live inside of a material builder.
The $F in file paths example demonstrates this. You cannot have anything be time dependent inside of material, so you have to promote that up so you can have a parameter with $F. But building at the /mat level…there's nowhere to promote to.
I think the system should explicitly warn us about this like this, or promote time variable parameters in it's auto generated shader.

I, too, have had the experience of binds not being picked up inside a principled shader, and having to crack it open and exposing a parameter so I can feed in a value.

This is not very illuminating I'm sure, but you're not alone.
  • Quick Links