Add support for viewdirection space in hardware shading

[edobrowo]

This addresses issue #1656.

Previously, attribute space in node viewdirection_vector3 was unused by GLSL and MSL implementations. This change correctly transforms the view direction from world space to the specified space.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: edobrowo / name: Ethan Dobrowolski (9be69a2, 9ebc0fb, 594e012, 9d6b655)
• ✅ login: jstone-lucasfilm / name: Jonathan Stone (ce748ab)

[jstone-lucasfilm]

@edobrowo This looks really promising, and to resolve the EasyCLA issue, I'd recommend following up through the support link that the Linux Foundation provides:

https://jira.linuxfoundation.org/servicedesk/customer/portal/4

[edobrowo]

I've made the ticket, thank you!

I'm not entirely sure why the view direction is not properly transformed in the object /model case. Also, it seems to be unaffected by any transformation, not just the world inverse transpose.

[jstone-lucasfilm]

This looks like a good start, though I think it's a larger set of changes than you need, and I'd recommend the following simplifications:

• Instead of replacing the computation of world-space view direction with new vertex shader logic, I'd leave it as a pixel-shader subtraction of view position from vertex position, as this should provide the most accurate per-pixel values.
• Then, for your new object-space view direction, you can simply apply the T_WORLD_INVERSE_TRANSPOSE_MATRIX transform to the world-space view direction that you compute in the pixel shader, just before the vector has been normalized.
• Finally, you can normalize your world/object view direction, making it a unit-length vector that can be returned as a result.

[edobrowo]

Thank you for the feedback! I made the requested changes, though the issue still persists. It seems like the transformation isn't being applied; why could this be the case? Thank you!

[jstone-lucasfilm]

@edobrowo This looks like a good step forward, and here are three suggestions for debugging the math of the new logic:

• One useful debugging tool that you can use here is the G key in the MaterialX Viewer, which writes the generated GLSL code out to a file on disk, where you can read it directly and compare it against what you expected to see.
• For additional detail, I'll sometimes place breakpoints in the new code path that I've written, allowing me to validate that my new code is executed, and that the inputs to the function match my expectations.
• As an external reference point, you might compare your new logic against the equivalent code in https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/source/MaterialXGenShader/Nodes/HwNormalNode.cpp, just to make sure you're not missing any important steps in your object-space code path.

[edobrowo]

@jstone-lucasfilm Thanks for the tips. I've been mainly testing in the graph editor and the viewer. I realized that the world transform, inverse transpose, etc. are all the identity matrices, since presumably object space is equivalent to world space for viewing single objects. This also explains why the output to normal_vector3 doesn't vary with the input space either.

I tested by hardcoding arbitrary mat4 transformations into the object-space path, and confirmed that when the node input is set to object or model space, the transformation is in fact applied. What would be an effective way to create a test case where the object is offset from world space? Thank you again.

[jstone-lucasfilm]

@edobrowo Good catch, and that makes sense. We don't yet have an effective way to test non-identity world-space transforms in the viewer and graph editor, and this would likely be a good candidate for a future improvement to MaterialX!

Given that context, this proposed change looks good to me, and I'll go ahead and run a few validations before merging.

[jstone-lucasfilm]

Great work on this project, thanks @edobrowo!