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://github.com/KhronosGroup/glTF-Sample-Assets/tree/main/Models/DiffuseTransmissionTeacup

https://github.com/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]

I think that a more suitable wording would be along the lines of:
"The percentage of light that is transmitted through the surface is calculated by multiplication of diffuseTransmissionFactor and diffuseTransmissionTexture to describe a single value"

Since there is not really any 'strength' :-)

[emackey]

Recently the OpenPBR effort appears to have adopted the term "weight" where glTF has traditionally used the word "strength." I guess I like "weight" better, but we should check our existing ratified extensions to see how hard it will be to make the change. Anisotropy, for example, uses "strength" normatively, and I'm sure others do as well. We should figure out how important it is to have consistency on this term among glTF extensions.

[bghgary]

I'm sure others do as well

Occlusion uses strength also in the core spec. Not that I'm advocating using this term here.

[rsahlin]

I really think we must approach this from a physical point of view:
The parameter governs the percentage (factor) of light that is transmitted into the surface - to be re-emitted at the other side.

From the side being illuminated - this could be seen as absorbed or internally transmitted factor.
From the side facing away from the light - this could be seen as the re-emitted factor.

I fully understand that editors/dcc tools call this something akin to 'weight' or 'strength' because that is understandable to content creators - in the glTF spec I think we need to be more accurate and use 'percentage' or 'amount' instead.

[emackey]

Changing from "strength" to some other terminology is a much larger discussion, one that retroactively touches the glTF core specification and many ratified PBR extensions. I don't think this PR is the correct venue to propose such a change.

[rsahlin]

Really?
I don't understand that reasoning.
Just because we use a technical wording in this extension does not mean that we have to make changes to existing spec.

[emackey]

Just from a consistency point of view, I wouldn't want to use the term "strength" in one extension and then "weight" in another extension, and then have to explain why we used two different terms to mean the same thing.

[rsahlin]

I would say that this is the color of the re-emitted light.
The color of the re-emitted light.

[emackey]

The color of the re-emitted light depends on the color of the received light. Here the extension describes the color of light allowed to pass, which is called "transmitted light" several places including in the name of the extension. So I believe this wording is correct.

[rsahlin]

Well, it's the same when its called color of the transmitted light - it still depends on the received light.....
I think that something along the lines of:
Internal coloring of the light that is transmitted through the surface

[bsdorra]

How about The color that modulates the transmitted light?

[rsahlin]

I really think we must re-work this extension and word it in a more physically based manner.
The phenomena that is modelled is attenuation of light - we have simplified it so that light is directly attenuated when entering the material.
On the opposite side there will be reflection and transmission as light hits the surface.
Of the transmitted light (from the opposite side) we have a factor controlling the amount that will enter into the surface - all of this light will be attenuated (regardless of distance) and re-emitted.

As a final parameter we can add the so-called thickness texture - in this case it is more of an absorption texture.
This texture controlls the amount of attenuated light that is re-emitted, regardless of thickness, we really do not know if light is absorbed due to distance travelled or density of material.
And so it ought to be called absorptionTexture and can work the same way that occlussion texture works (ie higher values let light trough, lower values reduce)

[bsdorra]

Not sure if I really understand your thickness texture proposal. Isn't it exactly what you control with the intensity of the diffuseTransmissionColorTexture?

[emackey]

Apologies if my own demos have led to some of the confusion here. Both transmission and diffuse transmission are surface-only properties. When used on a thin-walled surface, either of these properties allows light to transmit directly to the opposite side. But, if the volume extension is present, there may be a thick volume beyond the surface. In that case, transmission or diffuse transmission is just a gateway allowing light to enter and exit the volume. The properties of T or DT don't affect the volume itself, as the volumetric properties are covered by its own extension (as thickness, attenuation color, attenuation distance).

I gave a demo of candle wax recently. In the material for this, diffuse transmission is set to 0.5, untextured white. All of the wax coloring is established by volumetric properties (thickness and attenuation), and DT is just an enabler for the light to get in and out of that volume. You can imagine that DT offers a surface-level scattering event, white in this case, paired with a volumetric attenuation towards wax color.

    "materials":[
        {
            "doubleSided":false,
            "extensions":{
                "KHR_materials_diffuse_transmission":{
                    "diffuseTransmissionFactor":0.5
                },
                "KHR_materials_volume":{
                    "attenuationColor":[
                        0.8964201807975769,
                        0.8795840740203857,
                        0.6938217878341675
                    ],
                    "attenuationDistance":0.02,
                    "thicknessFactor":0.11999999731779099,
                    "thicknessTexture":{
                        "index":0
                    }
                },
                "KHR_materials_ior":{
                    "ior":1.4500000476837158
                }
            },
            "name":"Wax Material",
            "occlusionTexture":{
                "index":1
            },
            "pbrMetallicRoughness":{
                "baseColorFactor":[
                    0.8964201807975769,
                    0.8795840740203857,
                    0.6938217878341675,
                    1
                ],
                "metallicFactor":0,
                "roughnessFactor":0.30000001192092896
            }
        },

Something similar happens in my dragon diffuse transmission demo, as the dragon's coloring in that demo comes from the volumetric properties as well. I don't yet have a demo that pairs surface-level coloring with volumetric-imposed coloring, but the two are mathematically separate: The diffuse transmission coloring would be along the surface, and would not change with thickness. Volumetric attenuation is an un-texturable homogeneous color throughout the volume, that does potentially change with thickness. Light reaching the eye must survive both.

[rsahlin]

I don't think it makes sense to combine the two extensions KHR_materials_transmission and KHR_materials_diffuse_transmission.
They do both model the same physical phenomena - ie, the transmission of light through the material.
They both have a transmission factor - which is the amount of light that enters into the material.
Where the original transmission extension can adapt the roughness, this value will scatter the light being transmitted - the new extension are for materials where no light will pass through without being scattered/refracted.
Using the original extension with roughness = 1 should produce the same result as this extension.

I see this extension as a great way of simplifying/optimizing shader performance since it is known that the background will never be visible through the material.

Only difference that I can see is that this extension has a parameter to set the color of the light passing through the material.
However this should be possible by combining KHR_materials_transmission with the volume extension.

[emackey]

This draft was written by Tobias and Bastien some years ago, and they are describing how the effect works in Enterprise PBR which is being emulated here. That system is designed for path tracing, where it makes sense to offer both specular transmission (the original glTF transmission) and diffuse transmission (this PR).

I agree that we should strongly discourage realtime systems from applying both at once.

[rsahlin]

I agree that we should strongly discourage realtime systems from applying both at once.

I think it's more than that - they model different and non-compatible materials.

• This extension models the behavior under full/very high roughness - so high that you never see anything through the material.
• KHR_materials_transmission using varying values for roughness - where most values means that the material is (mostly) transparent.

Just because Enterprise PBR uses the effect together is not, in my mind, a reason for us to do exactly the same.

My view is that the materials that these extension model are not compatible and we should disalow the use of the extensions together.

[emackey]

This extension models the behavior under full/very high roughness

Actually no, this is a common misconception. The surface of KHR_materials_diffuse_transmission is allowed to be smooth, and will produce specular reflections according to surface roughness as usual, including very shiny ones. The transmitted light is diffuse, fully scattered, but not because of roughness at the surface.

Both this and the original KHR_materials_transmission extension are permitted to be present, and this section of the spec describes the interaction in mathematical detail. Admittedly such details are primarily of use to path-tracing systems for which this math was originally worked out, and is not much use in a real-time rasterizer.

Perhaps we could add a note discouraging realtime assets from using both together. But it's far too late to deeply alter such a fundamental aspect of this spec. This draft has been around for four years and has already shipped with stable versions of BabylonJS, for example. We're not making breaking changes to it at this point, the time for that is long gone. We're just looking to polish up the wording and get it ratified soon.

[rsahlin]

Actually no, this is a common misconception. The surface of KHR_materials_diffuse_transmission is allowed to be

My bad, I was hoping that you would understand what I meant - let me phrase it this way:
This extension models the behavior of full/high roughness of the inside (of the material)
All light that enters into the material is scattered - there can be no translucensy.
It is simply not compatible with KHR_materials_transmission from a physical point of view!

Perhaps we could add a note discouraging realtime assets from using both together. But it's far too late to deeply alter such a fundamental aspect of this spec. This draft has been around for four years and has already shipped with stable

I really do not understand this statement!
We must seek to release clearly defined extensions - as of now this extension is not very well defined from a physical point of view. Regardless of current implementations or time.

gone. We're just looking to polish up the wording and get it ratified soon.

Well, extensions shall be ratified when ready - this extension needs more work!

[bsdorra]

As the co-author, I may be biased, but I'd say that this extension is very well defined in the context of the current material model and other ratified material extensions. :) There's a clear definition of how it interacts with KHR_materials_transmission (that should also work for rasterizers). You find identical or very similar definitions in other PBR models, i.e. OpenPBR.

...as of now this extension is not very well defined from a physical point of view

What does that even mean? PBR appearance models do not necessarily replicate physics directly. Instead, they create abstract mathematical concepts that enable us to simulate the appearance of the real world in a computationally feasible manner, while adhering to important physical principles such as energy conservation. So, it is always a balancing act between physical correctness, performance, visual quality, artistic control and also inherently non-physical annoyances as infinitely thin surfaces.

[emackey]

@bsdorra I have a related question about how the light breaks down. Let's say at a particular point along the surface you have 10% Fresnel reflection, and you have transmission and diffuse transmission both set to 50% each on the same material. This is how I think it breaks down, is this correct?

1. Fresnel / specular reflection takes some light off the top. Of the original 100% received at the chosen point, 10% is reflected by this, and 90% is not yet accounted for.
2. Transmission (the specular kind) asks for 50%, but it gets 50% of what's left (90%), so for this point only 45% of the original received light shines through the surface along the specular transmission ray. The remaining 45% of the original is not yet accounted for.
3. Diffuse transmission also asks for 50% of the remaining 45%. As a result, 22.5% of the original light transmits through the surface and is released as a diffuse lobe on the opposite side. An additional 22.5% of the original light is all that remains not yet accounted for.
4. All remaining light (22.5% of the original) is modulated by the base color and released as a diffuse lobe on the same side of the surface where it was received.

Does that sound right?

[bsdorra]

@emackey that sounds correct to me 👍🏼

[rsahlin]

What does that even mean? PBR appearance models do not necessarily replicate physics directly. Instead, they create

It means that the goal of glTF must be to parameterize the physical properties of real world materials and the interaction with light.
Not mimic the behavior of one or more given editing formats.
One of the reasons why glTF is so succesful is that we are agnostic and that the parameters used are a good destillation of physical properties.

Also of great importance - glTF is a fileformat - not a PBR model - you cannot compare glTF to existing PBR models.
Our job is to package the physical material and light properties into a dataset that can be distributet as a transmission format.

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

I really think we must re-work this extension and word it in a more physically based manner.
The phenomena that is modelled is attenuation of light - we have simplified it so that light is directly attenuated when entering the material.
On the opposite side there will be reflection and transmission as light hits the surface.
Of the transmitted light (from the opposite side) we have a factor controlling the amount that will enter into the surface - all of this light will be attenuated (regardless of distance) and re-emitted.

As a final parameter we can add the so-called thickness texture - in this case it is more of an absorption texture.
This texture controlls the amount of attenuated light that is re-emitted, regardless of thickness, we really do not know if light is absorbed due to distance travelled or density of material.
And so it ought to be called absorptionTexture and can work the same way that occlussion texture works (ie higher values let light trough, lower values reduce)

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