Hi all,

Are material stylesheets supported in any way shape or form within Solaris? Can this be called
If not, is there a way to conceptually do the same thing (bindings, targets, overrides, etc)? Packed data that needs to have materials defined/overriden and have the workflow be geometry independend (via conditions, etc) would be great.

The simple workflow Im after would be (without unpacking):

- Packed alembic with primitive path attributes
- A way that can I define rendering properties, material assignments, and parameter overrides, automatically bind them on that packed data, with abstract conditions such as “assign a specific shader on any packed primitive whose path attribute contains the string ”_poly"

Moreover, is there support for storing this overrides as a usd layer on disk that can be loaded? Would I add a layer break before doing the process mentioned above and then saving it to disk separatedly?

If there are any examples on this would be great. A material stylesheet support for usd would be a great workflow, specially considering how precise materialStylesheet's implementation is.

Thanks!

Material style sheets need to be evaluated at render-time, and USD does not have facilities to convey them to render delegates. So, Solaris does not support them directly.

LOPs attempt to provide comparable functionality in the Assign Material LOP. Please, see the attached example. The LOP's Primitives parameter can be used to specify the “target” primitives. You can use VEX expressions to test for attribute values, etc. And the LOP's Parameter Overrides parameter can specify the script to calculate the new material parameters. There is no concept of bindings, but you can use `usd_parent()` function to get at primitive's ancestors and query their properties.

Also, while, USD does not provide dynamic expressions to override material parameters, you may be able to use geometry's primvars to drive the material's parameters. To calculate primvars dynamically, you can use Attribute VOP LOP.

The above methods operate on the “primitive” level, so I'm not sure if they will work for your needs with packed Alembics, though.

As for saving overrides to disk, then yes, you would put a layer break, and then author the material overrides in a new layer, which you can then save to a USD file disk.

Thanks rafal…posts like this are very helpfull as additional references to the existing tuts on solaris.

Thanks for the prompt reply! Helpful example too.

As Babaj mentioned it is most helpful to get insight on all this. Houdini’s documentation is very very nice but having dedicated sessions/videos on this whole usd workflow concepts would be amazing. The faster we can adopt the right way to approach work the faster our adoption will be

I’ll have a good look at the provided example. Thanks !

rafal
The above methods operate on the “primitive” level, so I'm not sure if they will work for your needs with packed Alembics, though.

When alembics are referenced/sublayered they appear in the graph as a hierarchy of prims as if there were native usd. As long as the root prim isn't marked ‘instanceable’, overrides should be able to be authored per prim (alembic shape).

Ok! Will have a plau with that too. Thanks!!

It would also be great if LOPs and Karma could have a cleaner way to feed prim string attributes directly to Cryptomatte properties instead of that weird user property / stylesheet override “hack” we have to use now.

blackpixel_mv
It would also be great if LOPs and Karma could have a cleaner way to feed prim string attributes directly to Cryptomatte properties instead of that weird user property / stylesheet override "hack" we have to use now.

Can you please elaborate on that "user property" 'hack' or send me a resource to read through. Maybe my case is a bit different in that, I'm trying to get cryptomatte data for each point in instancing scenario. I'm creating a render var with settings:
- format - color3f;
- source name - id(int attribute, unique for each point);
- source type - primvar
- enabled tick on 'cryptomatte'

The result is a cryptomatte pass that looks alright but doesn't work. I suspect that the reason is that my attribute is with 'varying' interpolation, but for the life of me I can't figure out how to convert it to 'uniform' or 'constant' or if it's even possible.