Two-sided Surface extension

[progschj]

Inspired by this: NVIDIA/VisRTX#63

To accomodate face culling an extension could add additional material parameters materialFront, materialBack for surface objects. They would override the stock material parameter for that side of the surface.

Back/front face culling would then be achieved by setting a fully transparent material on that side. Additionally the extension could specify that setting no material is valid and define the behavior to transparency.

[jeffamstutz]

After today's WG discussion, this is what I would propose:

• material behaves normally as a 2-sided material like it does now
• If the front/back material extension is present, then sided materials kick in if either or both materialFront or materialBack are present and are used instead of material
• materialFront and materialBack behave where viewing the surface from the front or back uses the respective material, and remains true for any effect that may "see" the surface (e.g. shadow rays)
• If only one of materialFront or materialBack are present, then the side without a material behaves as-if the material is 100% transparent
• Non-normative: it is recommended for applications to always set material for compability with devices which do not implement the sided materials extension
• Non-normative: face culling (front or back) should be expressed by omitting one of the two material sides so implementations do not have to inspect or evaluate materials (i.e. samplers could be used here to achieve 100% transparency, but that is not the most efficient way to express/implement face culling)

[jeffamstutz]

@johguenther There was reasonable consensus on today's call with the formulation of the extension listed above. Unless you have any other dissenting opinions, we can change the status to ready for proposal. I'm planning to implement it anyway in VisRTX to get some initial experience.

[johguenther]

I would really like to not intertwine the extension "backface culling" with the feature to have two different (solid) materials front and back. Just focusing on the latter, that request can be solved by e.g. keeping the material mandatory and optionally add a materialBack (or materialInside) parameter plus stating that "handling of transparency is implementation defined" (or stronger defining that material are treated opaque). The "Physically Based" material already implicitly treats a surface as inside/outside via properties ior and attenuation. This has the benefit that more implementations can support this extension. For example, backface culling is hard to impossible to implement for photonmapping, or BiDir path tracing.

materialFront and materialBack behave where viewing the surface from the front or back uses the respective material, and remains true for any effect that may "see" the surface (e.g. shadow rays)

There is no defined direction for shadow rays (from light to surface or vice versa).