Unlit surface shader node implemenation #858
Conversation
|
|
Signed-off-by: Niklas Harrysson <[email protected]>
|
/easycla |
| mx::GenContext materialContext = context; | ||
| materialContext.getOptions().hwTransparency = hasTransparency; | ||
|
|
||
| mx::ShaderPtr shader = createShader(elem->getNamePath(), materialContext, elem); |
There was a problem hiding this comment.
This code path was missing the check for transparency, so saved GLSL shaders would never include transparency handling.
|
@jstone-lucasfilm I'm not sure why my EasyCLA is not picked up here, as it's signed and approved in the materialx-test repo. |
It seems I had my old Autodesk email address set locally on my laptop that I made commits from. Will try to rebase or create a new PR to make sure all commits are made from my current user / email. |
| const ShaderInput* emissionColor = node.getInput("emission_color"); | ||
| shadergen.emitLine(outColor + " = " + shadergen.getUpstreamResult(emission, context) + " * " + shadergen.getUpstreamResult(emissionColor, context), stage); | ||
|
|
||
| if (context.getOptions().hwTransparency) |
There was a problem hiding this comment.
Hi @niklasharrysson, I don't think you want to emit this based on the option as this makes it inconsistent between language implementations (this and mdl). Also, it would make it so you can't change the values which affect "outTransparency" without recompiling the shader.
There was a problem hiding this comment.
Hey @kwokcb! Those are good points, but this convention has been used for a long time for our surface shading in GLSL., where transparency handling is not generated if the option is not set.
For example, see the PBR version of the surface constructor node here:
https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/source/MaterialXGenGlsl/Nodes/SurfaceNodeGlsl.cpp#L201
And also when emitting the final alpha blending of the fragment result here:
https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/source/MaterialXGenGlsl/GlslShaderGenerator.cpp#L643
So shader regeneration has always been required to introduce transparency to a surface shader in GLSL. While I agree it would be nice to improve on this, I think that should be done as part of a more holistic look at our transparency rendering for GLSL. Maybe it's worth adding a separate issue to track this.
There was a problem hiding this comment.
Hey @niklasharrysson ,
Yes, this makes sense to separate out.
I didn't know that we already required regeneration for other cases.
I can have added an issue ( #859) with the current logic as a "baseline" to consider.
…ation#853) Signed-off-by: Niklas Harrysson <[email protected]>
- Disable shadow maps in virtual framebuffer renders. - Remove duplication of render tests between GCC and Clang. Supporting changes: - Add a 'shadowMap' command-line option to MaterialXView. - Align render settings conventions between MaterialXRender and MaterialXView. Signed-off-by: Niklas Harrysson <[email protected]>
|
Closing this in favor of a new PR with proper EasyCLA setup: #860) |
Implementation of the "unlit" surface shader, as proposed in issue #839.
This change list adds the definitions and implementations for GLSL, OSL and MDL.
Some tests added to the test suite, testing visualization of a simple procedural with/without cutout opacity and with/without colored transmission:
Note that MDL rendering is not part of the testsuite yet and are here renderer separately with the MDL DXR sdk sample. Hence the difference in environment and geometry. Also note that for GLSL our renderer does not support colored transmission yet.