Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal : Improvements to double sided surface shading. #2086

Open
ld-kerley opened this issue Oct 25, 2024 · 3 comments
Open

Proposal : Improvements to double sided surface shading. #2086

ld-kerley opened this issue Oct 25, 2024 · 3 comments

Comments

@ld-kerley
Copy link
Contributor

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> 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.

<nodedef name=”ND_frontface_boolean” node=”frontface” type=”boolean”>
  <output name=”out” type=”boolean”
</nodedef>

Questions:

  • 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.

<nodedef name=”ND_twosides_float` node=”twosides” type=”color3”>
  <input name=”front” type=”float” value=”0”/>
  <input name=”back” type=”float” value=”0”/>
  <output name=”out” type=”float”/>
</nodedef>

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.

<UsdPreviewSurface name=”frontMtl” type=”surfaceshader”>
  <input name=”diffuseColor” type=”color3” value=”1, 0, 0”/>
  <input name=”metallic” type=”float” value=”1”/>
</UsdPreviewSurface>
<UsdPreviewSurface name=”backMtl” type=”surfaceshader”>
  <input name=”diffuseColor” type=”color3” value=”0, 0, 1”/>
  <input name=”metallic” type=”float” value=”0”/>
</UsdPreviewSurface>
<twosides name=”twosides” type=”surfaceshader”>
  <input name=”front” type=”surfaceshader” nodename=”frontMtl”/>
  <input name=”back” type=”surfaceshader” nodename=”backMtl”/>
</twosides>
<surfacematerial name=”MyMtl” >
  <input name=”surfaceshader” type=”surfaceshader” nodename=”twosides”/>
</surfacematerial>

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.

@flord
Copy link

flord commented Oct 25, 2024

In the name of all artist users, thank you Lee!

@fpliu
Copy link

fpliu commented Oct 25, 2024

q1. I'm fine with it only being boolean. Seems easy enough to covert to int if needed.

@crydalch
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants