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 Stylesheets workflow in Solaris?
3340 6 3- Sixjames1000
- Member
- 52 posts
- Joined:
- Offline
- rafal
- Staff
- 1440 posts
- Joined: July 2005
- Offline
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.
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.
- BabaJ
- Member
- 2024 posts
- Joined: Sept. 2015
- Offline
- Sixjames1000
- Member
- 52 posts
- Joined:
- Offline
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 !
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 !
- jsmack
- Member
- 7659 posts
- Joined: Sept. 2011
- Offline
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).
- Sixjames1000
- Member
- 52 posts
- Joined:
- Offline
- blackpixel_mv
- Member
- 83 posts
- Joined: Aug. 2018
- Offline
-
- Quick Links