KHR_materials_diffuse_transmission

[proog128]

An extension for the metallic-roughness material that adds a translucency effect, i.e., a diffuse lobe on the back-side of the surface. This is useful

• for thin materials like leaves or paper
• for volumetric materials like plastic or candle wax; in combination with KHR_materials_volume (KHR_materials_volume #1726) in case of SSS with short scattering distance

[emackey]

/ping @abwood New diagram added, looks nice!

[cx20]

BTW, This extension is not yet listed in the list of glTF extensions.
It's a good idea to list this extension as an extension to "In-progress".

[emackey]

@cx20 Fixed in f287c13, thanks.

[bsdorra]

Created (path-tracing) live demos for the example scenarios.
(Please note: half-way decent gpu required. Be patient, webgl shader linking is slooooow)

https://dassaultsystemes-technology.github.io/dspbr-pt/index.html?src=Potted+Plant&ibl=Studio_05&rotate=-45&unfold=transmission

https://dassaultsystemes-technology.github.io/dspbr-pt/index.html?src=Tea+Time&ibl=Studio_05&rotate=-45&unfold=transmission

[rsahlin]

Maybe I should open up a new PR with my proposed changes in order to get progress on this extension?

[rsahlin]

There are a couple of design issues with this extension, let me explain:

1: This extension models the scattering behavior of dense, non fully opaque, materials such as leaves or wax.
This phenomena is not the same as what is specified in KHR_materials_transmission and KHR_materials_volume
These two extensions both model the behavior of light passing through a transparent media such as glass or water.
They both use the Snell equations - attenuation color, viewpoint change due to IOR and total internal reflection are important.

2: This extension is more or less based on an adaptation of the Beer/Lambert law.
Instead of attenuation color, viewchanges due to IOR and total internal reflection, the total light extinction distance is important.
Ie, how far into the material does light travel before it is eliminated.

These two phenomena shall not be mixed into the same extensions - I know that it is super easy to get a shader to execute the code - it's just not a good parameterization of needed data.

Luckily there is a simple solution:

Make this extension into 'scattering transmission'

• Light entering into the surface of the material is scattered, this scattered light may be emitted on the opposite side, colored by the basecolor of the exit side. It is a model of the behavior as light travels through mostly organic materials such as leaves, wax or

• A factor controlls the amount of transmitted (not reflected) light that enters into the surface. The remaining part is re-emitted and colored by the basecolor of the incident side. Ie, business as usual.

• A total light extinction distance controlls the distance into the surface where light will not travel past.
  This is instead of the attenuation color - I know that the same visual effect can be achieved by setting the attenuation color to black - but that is wrong because it is not the same phenomena.

Now we have a self contained simplified extension, with less number of parameters, where the parameters are connected to what they actually control.
One extension that will satisfy the same usecases in less number of parameters and data.

Surely we must strive to have self contained, well parameterized extensions - we must not keep using the rationale 'we did it like this in extension XYZ'

[emackey]

This extension models the scattering behavior of dense, non fully opaque, materials such as leaves or wax.

No, that's not a complete understanding. This extension only models what happens at the outermost surface of a material, such as the outermost surface of a block of wax, or on a thin-wall material such as a leaf. It allows light to enter and exit a volume such as wax, but it cannot say anything about what happens to light whilst travelling inside the volume. The presence of the volume and the properties within are governed by a different extension.

This phenomena is not the same as what is specified in KHR_materials_transmission and KHR_materials_volume. These two extensions both model the behavior of light passing through a transparent media such as glass or water.

That's not quite correct. KHR_materials_transmission is a surface property, allowing light to enter and exit at the surface of a volume of material such as glass or water, possibly with a tint on the way in and out. The KHR_materials_volume extension intentionally doesn't explain how light got into or exits from the volume, it just explains the thickness of the volume and how light is attenuated along the way. The two are compatible, but KHR_materials_volume was always intended to be compatible with additional methods of entry and exit.

For some graphical depictions of what I've said here, take a look at the slides of my 2022 webinar on glTF PBR here:
https://www.khronos.org/assets/uploads/developers/presentations/Using_Advanced_PBR_Material_Parameters_in_glTF.pdf

Slide 14 covers this extension, and several slides before that explain the volumetric extension. Slide 16 has the chart that puts together compatibility and interactions between our various PBR extensions. I'd really encourage folks to read and deeply understand how this is intended to work before posting lengthy comments requesting foundational changes.

This extension is more or less based on an adaptation of the Beer/Lambert law

No, that's incorrect. This draft does not mention Beer's law, as this draft is only for the outermost surface of a material. Beer's law is covered by KHR_materials_volume with attenuation color and attenuation distance. See slide 16 of the above for an overview of how this all fits together.

The overall design here wasn't just invented by me, of course. Bastien and Tobias authored many of these drafts based closely on Dassault Systemes Enterprise PBR, which is a published standard with active users. They got feedback in PBR TSG from Adobe, Autodesk, Microsoft / BabylonJS, Google / Filament / ThreeJS, and other PBR experts along the way. A lot of care and respect was given to fundamental PBR concepts such as energy conservation during those many discussions. Please take time to understand what's here, as a lot of thought and care went into it, and similar properties are already in use by other published standards.

[emackey]

[UX3D-haertl]

Should this extension be targetable by animation pointer?
In this case the extension should be added to ObjectModel.adoc

[lexaknyazev]

@UX3D-haertl I'll update the object model after this is merged.

[rsahlin]

Confusion likely comes from specifying (physically plausible) behavior using (only) surface properties and the concept of 'thin walled' or infinetly thin materials, which I generally regard as unwise.

For this extension I think we must focus on usecases, leaf and wax candle, and figure out what we need to model this behavior.
Looking at how extensions are used in an environment with tens of thousands of models being converted, QA'ed handled and updated over time.
Also taking animation pointer into consideration, - we are just learning how this may affect specifications and maintenance.
Keep in mind that complexity will increase when multiple extensions are targetted.

I strongly believe in simplification - less is more - use of two extensions instead of one will increase complexity.
In this case I would rather not follow the trend of materials transmission/volume.
Instead, for the usecases we have I think a simpler, easier to manage over time, design that models behavior using one extension is to be preferred.

From what I can tell our usecases can be fulfilled by adding two optional parameters:
1: Total light extinction distance
2: Thickness texture

What, if any, is the benefit of splitting and declaring surface properties and interior/scattering behavior into separate extensions?

[emackey]

The Khronos PBR TSG voted today (2024-11-18) to move this extension to "Release Candidate" status. This means the parameters of the extension will not change prior to ratification unless major problems are found. All glTF implementers are encouraged to test this extension in their respective implementations and provide feedback on any roadblocks encountered.