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
This document summarizes a couple of recent conversations surrounding how shading the front and surface of an object might be improved in MaterialX. It’s broken down into a number of separate proposals. One of the benefits of this proposal is that it would allow artists to construct materials with different values or surface shaders on each side of a surface, and use that MaterialX material in USD without requiring changes to USD. To be clear, this proposal does not preclude USD adding support for the backsurfaceshader terminal in the <surfacematerial>, but it would eliminate a potential complication regarding USD supporting MaterialX 1.39 early next year.
Proposal : <frontface> Node
This node accepts no input, returns true if the front surface is being shaded, and false for the back surface. This node will allow the MaterialX graph to make decisions based on which side of the surface is being shaded.
Is it also useful to have an integer version of this node that returns 0 and 1? This would make it easier to use as an input to <switch>.
Proposal : <twosides>
This node allows two different input values to be switched between, based on which side of the surface is being shaded. For instance, this node could be used to swap the color of a surface between the front and back sides of a surface.
Its noted that this node could be implemented as a nodegraph implementation if the proposal for adding the <frontface> node above is accepted.
It is proposed that this node would have node definitions for the following types.
float
integer
color3
color4
vector2
vector3
vector4
matrix33
matrix44
surfaceshader
This last type is an important one. It would allow us to address the current conversation surrounding having different shaders on each side of a surface. Allowing two surfaces to be combined into a single port, and then connected to a downstream <surfacematerial> node, this is the critical component to gain the advantage of easier MaterialX 1.39 adoption in USD early next year.
This proposal is intentionally not taking any stance around considerations for uniform data, to keep the focus on double sided aspect of this proposal. We would expect this twosides node to follow any future introduced conventions to accommodate uniform data.
The text was updated successfully, but these errors were encountered:
I agree it's not hard to convert' I think more places use integer than boolean (i.e. switch)? That might make it slightly more convenient to output integer; but not hard either way to deal with.
Introduction
This document summarizes a couple of recent conversations surrounding how shading the front and surface of an object might be improved in MaterialX. It’s broken down into a number of separate proposals. One of the benefits of this proposal is that it would allow artists to construct materials with different values or surface shaders on each side of a surface, and use that MaterialX material in USD without requiring changes to USD. To be clear, this proposal does not preclude USD adding support for the
backsurfaceshader
terminal in the<surfacematerial>
, but it would eliminate a potential complication regarding USD supporting MaterialX 1.39 early next year.Proposal :
<frontface>
NodeThis node accepts no input, returns
true
if the front surface is being shaded, andfalse
for the back surface. This node will allow the MaterialX graph to make decisions based on which side of the surface is being shaded.Questions:
integer
version of this node that returns0
and1
? This would make it easier to use as an input to<switch>
.Proposal :
<twosides>
This node allows two different input values to be switched between, based on which side of the surface is being shaded. For instance, this node could be used to swap the color of a surface between the front and back sides of a surface.
Its noted that this node could be implemented as a nodegraph implementation if the proposal for adding the
<frontface>
node above is accepted.It is proposed that this node would have node definitions for the following types.
float
integer
color3
color4
vector2
vector3
vector4
matrix33
matrix44
surfaceshader
This last type is an important one. It would allow us to address the current conversation surrounding having different shaders on each side of a surface. Allowing two surfaces to be combined into a single port, and then connected to a downstream
<surfacematerial>
node, this is the critical component to gain the advantage of easier MaterialX 1.39 adoption in USD early next year.This proposal is intentionally not taking any stance around considerations for
uniform
data, to keep the focus on double sided aspect of this proposal. We would expect thistwosides
node to follow any future introduced conventions to accommodateuniform
data.The text was updated successfully, but these errors were encountered: