Is it possible to set the material binding via wrangle node? I found the usd_boundmaterialpath command, but there seems no way of setting it. I also checked usd_relationshipnames and usd_attribnames but I don't see any material in either.

Cheers
M

You can, but only with a vexpression within the assign material lop.

Notes:

https://www.tokeru.com/cgwiki/index.php?title=HoudiniLops#Assign_material_lop_vex_basics [www.tokeru.com]

The usd_setrelationshiptargets() [www.sidefx.com] function can be used to override the material binding, which is just a relationship:


This method does not add the MaterialBindingAPI schema, when used to create a new material binding. It renders with Karma at least, and should be safe for overriding an existing binding. But using the vexpression mode on Material Assign as @mestela suggested, is probably safer.

Hope that helps!

Oooh good to know! Adding that to the wiki...

Ah, thanks guys. When I tried it this morning also usd_relationshipnames() showed the material:binding - so I guess I did something wrong yesterday. Works now!

Guess the difference is that Matt's way doesn't work if the material library is still coming in the node tree, while setrelationshiptargets works also the library hasn't been introduced to the prims yet.

goldleaf
This method does not add the MaterialBindingAPI schema

goldleaf
But using the vexpression mode on Material Assign as @mestela suggested, is probably safer.

What are the risks/consequences of assigning the material and missing the MaterialBindingAPI schema like it happens when using usd_setrelationshiptargets() in a wrangle?

I am guessing there is no VEX way of adding schemas; only python or inline.

Thanks!

H20 now has usd_applyapi()
https://www.sidefx.com/docs/houdini/vex/functions/usd_applyapi.html [www.sidefx.com]

Hello again!

I have been going through the documentation and I am not being able to find a clear explanation for what the MaterialBindingAPI is doing, and why would a material:binding relationship alone work by itself, or the potential issues derived from not having the schema.

Is there a specific place in the documentation that goes through this that I might be missing?

Thanks!

MaterialBindingAPI is an ApiSchema. ApiSchemas can provide just an API (i.e. set of functions) to author certain data on a prim. Or they additionally might "decorate" a prim, and recorded as having been applied.

In previous versions of USD and Solaris, USD was less strict about having the ApiSchema recorded on the prim. But in the last year (or two?) that has changed, and USD/Hydra require the ApiSchema to be applied. LOPs is generally good about doing this, so that change in strictness didn't generally affect Houdini users. It's also true that, although strict in authoring, Houdini and Karma can still pretty forgiving. When someone used a Wrangle or Python LOP to author a relationship or attribute directly, rather than the API of the ApiSchema, that's where they'd get bit by this change.

https://openusd.org/release/glossary.html#api-schema [openusd.org] has more info about ApiSchema's generally. And you can get more info about MaterialBindingAPI here: https://openusd.org/dev/api/class_usd_shade_material_binding_a_p_i.html#details [openusd.org]

Hope that helps!

Thanks so much for the answer!

Then I imagine a good practice that you would recommend is using the new usd_applyapi() whenever we create something by vex code in a wrangle to add the corresponding schema. For example, whenever we create a material:binding rel (MaterialBindingAPI), but also in other cases such as creating a collection:include rel (CollectionAPI) right?

It'd be great to have some info/warning popping whenever a schema is missing, or some documentation with the types of relationships that need a schema to be added by de user... it feels like it can lead to some errors pretty hard to debug, and makes working with wrangles lops a bit scary when they are often a very handy way of doing some more complex USD operations.

Cicuta
Then I imagine a good practice that you would recommend is using the new usd_applyapi() whenever we create something by vex code in a wrangle to add the corresponding schema. For example, whenever we create a material:binding rel (MaterialBindingAPI), but also in other cases such as creating a collection:include rel (CollectionAPI) right?

to me it sounds like it should be the opposite and we should add the schema first and rather than doing some custom code to try to handle the binding or whatever we should use the API for that

which would meant that VEX should gain the ability to call functions from attached API as well, since I imagine that's the whole purpose of API that then we should call its Bind() function rather than set up relationship the naive way, or am I misunderstanding?

tamte
to me it sounds like it should be the opposite and we should add the schema first and rather than doing some custom code to try to handle the binding or whatever we should use the API for that

which would meant that VEX should gain the ability to call functions from attached API as well, since I imagine that's the whole purpose of API that then we should call its Bind() function rather than set up relationship the naive way

Exactly. If that is the case I don't see the logic behind using functions such as usd_setrelationshiptargets() if its a "dangerous" non-standard way of doing things USD. Following this it seems like I have been using functions in VEX that do things the naive way (even though, they seemed to work just fine).

It's not necessarily dangerous, it's just the generic function for relationship attributes is all we have; I think we just need a VEX function to create material bindings. While warnings/detection could be good (could be done with the Scene Doctor LOP), I think the "correct" way is just make functions that do the action and apply the schema. VEX already does this in some cases (i.e. collections); we just need one to make material assignments in a general VEX script.