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

[coreh]

Hey 👋 Currently implementing this for Bevy Engine, and wondering: Why was the A channel chosen for the diffuse transmission texture?

The specular transmission texture from KHR_materials_transmission uses the R channel, and the thickness texture from KHR_materials_volume uses the G channel. So perhaps the B channel would be a good fit for packing these three into single RGB texture that's easier to author and visualize, as these values are all somewhat related. Is it currently reserved for something else?

I could not find anything using the B channel, apart from ADOBE_materials_clearcoat_specular

[bsdorra]

Hi @coreh, the idea is to have all diffuse transmission values in a single texture, color in the RGB channels and the factor stored in A.
The glTF group is discussing texture packing on a more general level. With all these new PBR parameters, hard-coding the packing structure doesn't seem to be optimal anymore.

[coreh]

Oh, that makes a lot of sense. I was thinking in terms of the existing packed texture, and didn't even think that one would frequently want to use factor and color together. Thanks! I'll update the docs on my implementation to reflect this.

[echadwick-artist]

I noticed a typo in the example codeblock in the README.md (see below) and was about to clone the PR locally to fix it, but GithubDesktop reported this error:

The typo I mentioned above is a misplaced comma, currently as:

                    "diffuseTransmissionTexture": {
                      "index": 0,
                    }
                    "diffuseTransmissionColorFactor": [

But should instead be:

                    "diffuseTransmissionTexture": {
                      "index": 0
                    },
                    "diffuseTransmissionColorFactor": [

[bsdorra]

@echadwick-wayfair fixed it, thanks!
The error message is weird, the branch exists and is valid. Is your remote url pointing the correct repo?

[zeux]

Any updates on the progress on this extension? I'm looking at releasing a new version of gltfpack in the next month or so and unsure if it should include support for this extension even though it's still not merged to avoid a situation where it gets released shortly afterwards and isn't supported for some period of time, or if this extension is still in a significant state of flux and won't get merged any time soon.

[emackey]

@zeux That's a great question. I would like to see this extension ratified mostly as-is, but it may not happen soon. I've re-started the discussions on the Khronos PBR TSG calls, but I can't guarantee it will suddenly move forward. There are an assortment of concerns ranging from performance to interoperability to consistency between engines. If you know of some solid use cases or sample models that we could use as fuel for the burning desire for this, please let me know.

[Reon90]

there is a sample model?

[echadwick-artist]

I have added three sample assets so far (thanks to @bsdorra for pathtraced versions of the plant and teacup)

https:/KhronosGroup/glTF-Sample-Assets/tree/main/Models/DiffuseTransmissionTeacup

https:/KhronosGroup/glTF-Sample-Assets/tree/main/Models/MandarinOrange (this should be done with SSS instead, not a thin-walled surface shape, but it does demonstrate some odd backscatter behavior)

KhronosGroup/glTF-Sample-Assets#79

[echadwick-artist]

We probably need a sample asset grid of flat shapes to stress test combinations of values. Which of these should be represented?

• diffuseTransmissionFactor
• diffuseTransmissionTexture
• diffuseTransmissionColorFactor
• baseColorFactor
• image based lighting with sunlight
• punctual lighting
• is the extension affected by normal mapping, and thus we should include this in tests?
• what additional factors directly influence diffuse transmission?

I can manufacture a test asset, if I have a set of parameters we’d like to include.

[rsahlin]

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

[rsahlin]

A more physically based wording would be along the lines of:

This extension models the physical phenomenon of light being transmitted into a material, this light is attenuated and re-emitted on the opposite side. This is called attenuated light. Attenuation occurs immediately as light enters into the surface, there is no attenuation distance (Beer-Lambert Law). The amount of attenuated light is controlled by the transmissionFactor, this specifies the percentage of non-reflected light that is transmitted into the material. A higher value means that more of the non-reflected (diffuse) light from the opposite side will be re-emitted, a lower value means less light will be re-emitted. Color of the attenuated light is specified by attenuationColor.

[bsdorra]

Other extensions suggest that the overview part focuses more on the practical application of the extension than the underlying physical concepts. Property descriptions seem to be a more appropriate location. Let me try to reword and add sections based on your suggestion (and also following the example of KHR_materials_transmission).

Overview

This extension models the physical phenomenon of light being diffusely transmitted through an infinitely thin material. Thin dielectric objects like leaves or paper diffusely transmit light due to dense volumetric scattering within the objects surface boundaries. In 3D graphics, it is common to approximate thin volumetric objects as non-volumetric surfaces.

KHR_materials_diffuse_transmission models the diffuse transmission of light through such infinitely thin surfaces. For optically thick media (volumes) with short scattering distances and dense scattering behavior, KHR_materials_diffuse_transmission provides a phenomenologically plausible and cost-effective approximation.

.
.
.

Properties

diffuseTransmissionFactor

The proportion of light that is diffusely transmitted through a surface, rather than being diffusely re-emitted. This is expressed as a percentage of the light that penetrates the surface (i.e., not specularly reflected), rather than a percentage of the total light incident on the surface. A value of 1.0 indicates that 100% of the light that penetrates the surface is transmitted through it.

diffuseTransmissionColorFactor

The proportion of light at each color channel that is not attenuated by the surface transmission. Attenuation is usually defined as an amount of light at each frequency that is reduced over a given distance through a medium by absorption and scattering interactions. However, since this extension deals exclusively with infinitely thin surfaces, attenuation is constant and equal to 1.0 - diffuseTransmissionColorFactor.

diffuseTransmissionTexture

The A channel of this texture defines proportion of light that is diffusely transmitted through a surface, rather than being diffusely re-emitted. This is expressed as a percentage of the light that penetrates the surface (i.e., not specularly reflected), rather than a percentage of the total light incident on the surface. A value of 1.0 indicates that 100% of the light that penetrates the surface is transmitted through it.

The value is linear and is multiplied by the diffuseTransmissionFactor to determine the total diffuse transmission value.

diffuseTransmission = diffuseTransmissionFactor * diffuseTransmissionTexture.a

diffuseTransmissionColorTexture

The RGB channels of this texture define the proportion of light at each color channel that is not attenuated by the surface transmission.
The values are multiplied by the diffuseTransmissionColorFactor to determine the total diffuse transmission color.

diffuseTransmissionColor = diffuseTransmissionColorFactor * diffuseTransmissionColorTexture.rgb

[rsahlin]

In my opinion the overview must clearly outline the goal of the extension.
In the case of a material property extension like this, it makes perfect sense to describe the physical behavior or phenomena that is modelled.
The property description then specifies each parameter.

[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?