Name collision from MaterialX generated shaders in Storm

Community Hydra
1

Hi
I’m running into an issue with uniform name collision from MaterialX generated shaders in Storm. In our library we have a node called normal_map and one of the inputs is (float) normal_scale. This node is namespaced as adsk:normal_map to prevent node collison.

  <nodedef name="ND_adsk_normal_map" node="normal_map" nodegroup="texture2d" version="1.0.1" isdefaultversion="true" namespace="adsk">
    <input name="file" type="filename" />
    <!-- normal scale -->
    <input name="normal_scale" type="float" value="1.0" />
    ...
    <output name="out" type="vector3" />
  </nodedef>

For the normal_scale input, MaterialX generates a uniform parameter float normal_map_normal_scale

Since normal_map is connected to Standard Surface normal input the the resolved parameter in Storm is normal_map_normal. Now, since Storm adds a scale and bias uniform for texture types this adds a vec4 normal_map_normal_scale to the parameter list. The final glsl fails to compile due to this duplicate
float normal_map_normal_scale and vec4 normal_map_normal_scale

The fix is to make them unique, for example Storm could add a hdst prefix to make it normal_map_normal_hdst_scale which is suitable workaround. It also is clearer wrt to storm added uniforms v/s materialx uniforms. We could also check for duplicates in storm which might be a performance overhead.

I think we be to use node namespaces in uniform names
i.e. adsk:normal_map/normal_scale becomes adsk_normal_map_normal_scale
I’m not sure if embedding the namespace in the uniform will cause any issues.

I’m wondering what folks think about this approach. This would be change to MaterialX shader generation and parameter reflection which is used in Storm.

Thanks
Ashwin Bhat

2

Hi Ashwin,

Could you provide how this looks with an example mtlx and code generated?

By Storm, I assume this means the custom code generator used there? If its injecting additional uniforms then should it not just check for existing ones to avoid a name clash regardless of whether a namespace is involved?

This is my supposition, but maybe need some more info.

Thanks,
Bernard

3

Hey Ashwin,

I like the idea of preserving the namespace in the name we give to the shader, and would be supportive of that change (even aside from the related bug). It sounds like that may fix the issue, but if you’d like us to do anything on the storm shader gen side as well let us know! We’re exploring adding the “hydra:” namespace for primvars we generate in usdImaging, and could do something similar for things we add in hdSt material generation as well.

Thanks,
Tom

4

Hey Tom,
That’s great to hear, getting namespace embedded via MaterialX will need some additional discussion with MaterialX folks.

For now, in hdSt, I’m adding a token: ((stormGenerated, "hdSt")) and using this to address conflicts.
I can prepare a PR with this change if required.
Thanks
Ashwin