You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are looking for consistency in the way shader nodes are registered. This will allow a node editor to build a nicer node picker by grouping nodes according to hints provided in the registration. Having a consistent registration scheme will allow all renderer nodes to be sorted without needing custom per-renderer coding in the DCC.
To Reproduce
In a USD python session, with the arnold-usd binaries added to PXR_PLUGINPATH_NAME, run the following script:
Identifier arnold:standard_surface ND_standard_surface_surfaceshader UsdPreviewSurface
Name standard_surface ND_standard_surface_surfaceshader UsdPreviewSurface
Family shader standard_surface UsdPreviewSurface
Role standard_surface pbr UsdPreviewSurface
Context arnold surface usda
SourceType arnold mtlx glslfx
Identifier arnold:rgb_to_float ND_mix_color3 UsdPrimvarReader_float2
Name rgb_to_float ND_mix_color3 UsdPrimvarReader_float2
Family shader mix UsdPrimvarReader
Role rgb_to_float compositing primvar
Context arnold pattern usda
SourceType arnold mtlx glslfx
Expected behavior
We would expect the family to be the same as the name. The specifications are vague, but the USD and NdrFsHelpersSplitShaderIdentifier() implementations allow us to deduce that shaders that differ only by output type should be in the same family.
Role is less strictly defined, it groups nodes by "nodegroup" in MaterialX and seems to also get a generic category for USD native shaders. Maybe it could be something similar to the classification used to build the shader nodes documentation page in Arnoldopedia.
We might want to leave Context untouched. For MaterialX everything is a pattern, except surface/displacement/volume shaders where the context reflects the expected terminal node to connect on the material.
Screenshots
Used Software Versions
Arnold: 7.1.3.0
USD: 22.5
Additional context
The text was updated successfully, but these errors were encountered:
JGamache-autodesk
changed the title
Sdr parser registration should be consistent across renderers
Sdr node discovery results should be consistent across renderers
Jul 13, 2022
Describe the bug
We are looking for consistency in the way shader nodes are registered. This will allow a node editor to build a nicer node picker by grouping nodes according to hints provided in the registration. Having a consistent registration scheme will allow all renderer nodes to be sorted without needing custom per-renderer coding in the DCC.
To Reproduce
You will get the following output:
Expected behavior
We would expect the family to be the same as the name. The specifications are vague, but the USD and NdrFsHelpersSplitShaderIdentifier() implementations allow us to deduce that shaders that differ only by output type should be in the same family.
Role is less strictly defined, it groups nodes by "nodegroup" in MaterialX and seems to also get a generic category for USD native shaders. Maybe it could be something similar to the classification used to build the shader nodes documentation page in Arnoldopedia.
We might want to leave Context untouched. For MaterialX everything is a pattern, except surface/displacement/volume shaders where the context reflects the expected terminal node to connect on the material.
Screenshots
Used Software Versions
Additional context
The text was updated successfully, but these errors were encountered: