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

KHR_materials_transmission #1698

Merged
merged 26 commits into from
Aug 26, 2020
Merged
Show file tree
Hide file tree
Changes from 11 commits
Commits
Show all changes
26 commits
Select commit Hold shift + click to select a range
b6b5396
First draft of thin surface optical transparency extension
MiiBond Oct 22, 2019
a234697
Adding examples and more detail
MiiBond Oct 28, 2019
74ad767
Updating image
MiiBond Oct 28, 2019
f7af9c1
Add info about how roughness affects transmitted light
MiiBond Nov 5, 2019
a2cee58
Minor updates to wording
MiiBond Mar 13, 2020
45045c3
Remove IOR from example file
MiiBond Mar 13, 2020
8f10d45
Adjusting default value for transmissionFactor and updating readme
MiiBond Jun 17, 2020
fe76115
Specify that transmission is stored in the red channel of the texture
MiiBond Jun 18, 2020
af9ab1f
Fix reference to wrong default value
MiiBond Jun 23, 2020
56deeaa
Remove example for transmission
MiiBond Jun 24, 2020
f3256a7
Add comments about implementation expectations regarding layering
MiiBond Jul 3, 2020
35de2de
Merge branch 'master' of github.com:KhronosGroup/glTF into KHR_materi…
MiiBond Jul 8, 2020
fb83e3b
Add TOC, References and Khronos Copyright
MiiBond Jul 8, 2020
e429c4f
Update screenshot to remove refraction
MiiBond Jul 16, 2020
8df02df
Add suggested wordage to implementation notes
MiiBond Jul 16, 2020
3fe463e
Add note about baseColor needing to be converted to linear
MiiBond Jul 20, 2020
1410f7f
Update tint description
MiiBond Jul 21, 2020
c676ac9
Quick list of contributors
MiiBond Jul 27, 2020
a1af8f0
Quick list of contributors
MiiBond Jul 27, 2020
ae7ce0f
Couple of fixes
MiiBond Aug 6, 2020
d4875a8
Clarify tinting section
MiiBond Aug 6, 2020
885fa99
Add "This section is non-normative" clarification.
Aug 17, 2020
3776f24
Merge remote-tracking branch 'origin/master' into KHR_materials_trans…
emackey Aug 17, 2020
24c7755
Update copyright & schema description
emackey Aug 17, 2020
f9e8ce1
Markdown whitespace
emackey Aug 17, 2020
b936cf2
Address some comments
MiiBond Aug 17, 2020
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
129 changes: 129 additions & 0 deletions extensions/2.0/Khronos/KHR_materials_transmission/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,129 @@
# KHR\_materials\_transmission

## Contributors

* Mike Bond, Adobe, [@miibond](https://github.com/MiiBond)

## Status

Work in Progress

## Dependencies

Written against the glTF 2.0 spec.

## Overview

Many optically transparent materials are impossible to represent in a physically plausible manner with the core glTF 2.0 PBR material. This is because the core specification only includes the concept of "alpha as coverage" (exposed via the alpha channel of `baseColorFactor` and `baseColorTexture`). Many common materials like glass and plastic require significantly different rendering techniques.

## Limitations of Alpha as Coverage
Alpha-as-coverage can basically be thought of as describing whether the surface exists or not. When alpha is 0, nothing is rendered while alpha=1 means that the material is solid. It's most useful for materials such as gauze or burlap that only partially cover the area in which the material is rendered. These materials contain lots of small holes where the light can pass through so, strictly speaking, the light isn't actually entering the material itself (i.e. the surface isn't there). For other materials, like clear glass, a photon of light might actually enter the surface and be transmitted through. In this case, the light can be reflected, refracted, absorbed or scattered. Simple alpha-as-coverage cannot represent any of these effects and so we need very different logic to render them correctly.

The most important of these features is surely reflection. Even a completely transparent, infinitely thin, glass material is still visible due to its reflection of light. However, a material using purely alpha as coverage is not visible at all when alpha = 0 (because the surface effectively doesn't exist).

<figure>
<img src="./figures/OpacityComparison.png"/>
MiiBond marked this conversation as resolved.
Show resolved Hide resolved
<figcaption><em>White sphere with alpha coverage of 25% (left) vs the same sphere with 100% optical transparency (right). Note that alpha coverage of 25% is shown because 0% would be completely invisible. Also note that alpha-as-coverage reflects light in proportion to its opacity. i.e. the more transparent it is, the weaker the reflections will appear.</em></figcaption>
</figure>

The `KHR_materials_transmission` extension provides a way to define glTF 2.0 materials that are transparent to light in a physically plausible way. That is, it enables the creation of transparent materials that absorb, reflect and transmit light depending on the incident angle and the wavelength of light. Common uses cases for thin-surface transmissive materials include plastics and glass.

This extension aims to address the simplest and most common use cases for optical transparency: infinitely-thin materials with no refraction, scattering, or dispersion. Dealing exclusively with “thin” materials (i.e. materials where only the surface is considered and not the volume) allows many simplifications to be made when calculating things like refraction and absorption.

## Extending Materials

A transparent material is defined by adding the `KHR_materials_transmission` extension to any glTF material. When present, the extension indicates that a material should be rendered as a transparent surface and be blended as defined in the following spec. Note that, as rendering transparent objects presents many difficult-to-solve issues with primitive ordering, this extension does not dictate rendering algorithms.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that we should make a painters (depth sorting) algorithm normative - otherwise we risk objects 'popping' in and out.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mike is correct that specific rendering techniques are out of scope for normative glTF spec.. This particular suggestion would prohibit many real-time implementations, which is not what we want.

Separately, 3D Commerce may require something along these lines for certification, but beware that you may be excluding more clients than you bargained for here.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it could pose a performance problem for a particular type of real-time implementations - mostly webGL / script based ones.
The cost would be performance - however the gain would be predictable results.
Depending on implementation (language and platform) you would get varying degrees of performance penalty, for instance a C based engine could do it on the CPU without too much overhead.
A Vulkan based engine could do it on the GPU.

I would not want us to limit this due to current viewer implementation bottlenecks - it could be a good motivator to push development forward.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The rendering should not be normative.
Depending on the rendering method (forward vs. deferred plus it's variations), different and better algorithms do exist.
E.g. pixel sorting (aka order independent transparency) should not be excluded.
From my point of view, we should point to non-normative approaches.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rsahlin Also consider that many glTF implementations exist within rendering libraries that are used by 3rd-party applications. The library cannot dictate how the application structures its render passes or loops. That's part of what makes this extension particularly challenging, as it imposes some nontrivial best practices there. These should be as clearly spelled out as we can manage, but not marked normative. Little more than the glTF file structure and its meaningful interpretation is normative to glTF.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is a simplification calling this the 'rendering ' - to me it boils down to what is visible through the primitives using transmission.

If it's the sorting algorithm you object to then I would suggest a wording similar to:
'The background and other objects, including primitives using transmission, should be visible through the material (that is using transmission)'

Copy link
Contributor

@abwood abwood Jul 7, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed on today's call, Sketchfab's refraction material has a similar baseline as what is proposed here as an implementation note: we only require the opaque scene to be sampled by the transmission material. Some highlights from their documentation :

  • A refractive object can not refract itself.
  • A refractive object can not refract other refractive objects.
  • There can be sorting issues when mixing refractive and transparent objects.
  • There can be artifacts when the camera moves.
  • Objects outside of the field of view are not refracted.

And for convenience, here are some sample models that demonstrate their refraction material.

Sketchfab has established this as an acceptable baseline for their community and I would hope that our spec would be structured in such a way that their implementation is conformant. It seems like a reasonable baseline.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems to be a similar situation for Blender's realtime renderer (Eevee). It cannot show refractive objects behind other refractive objects, but can display transparent and opaque objects behind refractive objects. https://blenderartists.org/t/realistic-glass-in-eevee/1149937/29


```json
materials: [
{
"extensions": {
"KHR_materials_transmission": {
"transmissionFactor": 0.8,
"transmissionTexture": 0
}
}
}
]
```

## Properties
Only two properties are introduced with this extension and combine to describe a single value; the percentage of light that is transmitted through the surface of the material. These properties work together with the existing properties of the material to define the way light is modified as it passes through the substance.

| |Type|Description|Required|
|---|----|-----------|--------|
|**transmissionFactor** | `number` | The base percentage of light that is transmitted through the surface.| No, Default: `0.0 ` |
|**transmissionTexture** | [`textureInfo`](/specification/2.0/README.md#reference-textureInfo) | A texture that defines the transmission percentage of the surface, stored in the `R` channel. This will be multiplied by `transmissionFactor`. | No |

### transmissionFactor
The amount of light that is transmitted by the surface rather than diffusely re-emitted. This is a percentage of all the light that penetrates a surface (i.e. isn’t specularly reflected) rather than a percentage of the total light that hits a surface. A value of 1.0 means that 100% of the light that penetrates the surface is transmitted through.

<figure>
<img src="./figures/ConstantTransmission.png"/>
<figcaption><em>baseColor or yellow with transmissionFactor = 1.0.</em></figcaption>
MiiBond marked this conversation as resolved.
Show resolved Hide resolved
</figure>

### transmissionTexture
The `R` channel of this texture defines the amount of light that is transmitted by the surface rather than diffusely re-emitted. A value of 1.0 in the red channel means that 100% of the light that penetrates the surface (i.e. isn’t specularly reflected) is transmitted through. The value is linear and is multiplied by the transmissionFactor to determine the total transmission value.

<figure>
<img src="./figures/TransmissionTexture.png"/>
<figcaption><em>Controlling transmission amount with transmissionTexture.</em></figcaption>
</figure>

## Tint
You may notice that the transparent materials show above are tinted. i.e. they aren't actually transmitting 100% of the non-reflected light. This is because `KHR_materials_transmission` specifies that the `baseColor` of the material be used to model the absorption of light by the surface. This allows materials like stained glass to be easily represented with this extension.
Absorption is usually defined as an amount of light at each frequency that is absorbed over a given distance through a medium (usually described by Beer’s Law). However, since this extension deals exclusively with infinitely thin surfaces, we can treat absorption as a constant. In fact, rather than absorbed light, we can talk about its inverse: transmitted light. The `baseColor` of the material serves this purpose as it already defines how the light that penetrates the surface is colored by the material. In this model, the transmitted light will be modulated by this color as it passes through.
emackey marked this conversation as resolved.
Show resolved Hide resolved
<figure>
<img src="./figures/ConstantTransmission.png"/>
<figcaption><em>The baseColor of the material (yellow, in this example) is used to tint the light being transmitted.</em></figcaption>
</figure>

## Refractive Blurring
Since the surface is considered to be infinitely thin, we will ignore macroscopic refraction caused by the orientation of the surface. However, microfacets on either side of the thin surface will cause light to be refracted in random directions, effectively blurring the transmitted light. That is, the roughness of the surface directly causes the transmitted light to become blurred. This microfacet lobe is exactly the same as the specular lobe except sampled along the line of sight through the surface.
<figure>
<img src="./figures/Roughness.png"/>
<figcaption><em>Refraction due to surface roughness.</em></figcaption>
</figure>

## Blending
The glTF `blendMode` is used for alpha-as-coverage, NOT for physically-based transparency (i.e. this extension). If alpha-as-coverage is not being used, the blend mode of the material should be set to "OPAQUE" even though it is transparent. Again, it's helpful to think of alpha-as-coverage as whether the physical surface is there or not. `transmission` applies to the surface material that exists.
Note that alpha-as-coverage can still be used along with transmission as shown in the example below.
<figure>
<img src="./figures/TransmissionWithMask.png"/>
<figcaption><em>Alpha coverage and optical transparency can be used at the same time so that some areas of a surface are transparent while others disappear entirely.</em></figcaption>
</figure>

## Transparent Metals
Metals effectively absorb all refracted light (light that isn't reflected), preventing transmission.
The metallic parameter of a glTF material effectively scales the `baseColor` of the material toward black while, at the same time scaling the F0 (reflectivity) value towards 1.0. This makes the material opaque for metallic values of 1.0 because transmitted light is attenuated out by absorption. Therefore, for a material with `metallicFactor=1.0`, the value of `transmissionFactor` doesn't matter.

## Implementing Transmission ##
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please make it clear that this is an implementation note:

Implementation Note:

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This section is normative. The non-normative "Implementation Notes" are below this section.

From the core [glTF BRDF](https://github.com/KhronosGroup/glTF/blob/master/specification/2.0/README.md#appendix-b-brdf-implementation), we have:

*f* = *f*<sub>*diffuse*</sub> + *f*<sub>*specular*</sub>

*f*<sub>*diffuse*</sub> = (1 - *F*) * *diffuse*
emackey marked this conversation as resolved.
Show resolved Hide resolved

*f*<sub>*specular*</sub> = *F* * *G* * *D* / (4 * dot(*N*, *L*) * dot(*N*, *V*)), where *F* is the Surface Reflection Ratio.

We will now add an additional term for the transmitted light:

*f* = *f*<sub>*diffuse*</sub> + *f*<sub>*specular*</sub> + *f*<sub>*transmission*</sub>

*f*<sub>*transmission*</sub> = (1 - *F*) * *T* * *D<sub>T</sub>* * *baseColor*
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't this missing the G term and the normalization, like in f_specular?

f_transmission = (1-F) * T * baseColor * D_T * G_T / (4 * abs(dot(N, L)) * abs(dot(N, V)))

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, quite right. Thank you.


where *T* is the transmission percentage defined by this extension's `transmission` and `transmissionTexture` properties and *D<sub>T</sub>* is the distribution function for the transmitted light. The distribution function is the same Trowbridge-Reitz model used by specular reflection except sampled along the view vector rather than the reflection. The *baseColor* factor causes the transmitted light to be tinted by the surface.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I personally would benefit from clarity here with regards to Dt. This states that Dt is the Towbridge-Reitz distribution function, but sampled along the view direction rather than the reflected direction. The microfacet distribution function, D, is calculated using dot(n, h). Is it correct that this should instead use dot(n, -v) in this calculation for when we deal with transmission? Is it that simple?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the dot(n, h) term shouldn't come into play at all since the transmitted light isn't being reflected, but I could be wrong. The incoming light direction should be sampled along the view direction because you're looking through the material and are seeing completely unrefracted light. The transmitted light is then scaled by the Fresnel to account for the portion of light reflected off the inside surface of the material (and, therefore, not reaching your eye).
Not sure at all if this is correct so it would be good to have others (like @proog128) look at this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To my understanding, the dot product is relevant as we still evaluate the microfacet distribution. There's a brief section on the topic in the DSPBR spec https://bit.ly/2NpmJVn (eq. 5 and fig. 4). We just use a modified half-vector, which uses the flipped light direction.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, you're right. You'd flip it across the plane defined by the surface normal and then it would be centered around the same direction as the view.

Copy link
Contributor

@abwood abwood Aug 14, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this sentence you mention Trowbridge-Reitz by name, but we only suggest that model in Appendix B as non-normative. Should it be mentioned here? I would consider rewriting this as:

Suggested change
where *T* is the transmission percentage defined by this extension's `transmission` and `transmissionTexture` properties and *D<sub>T</sub>* is the distribution function for the transmitted light. The distribution function is the same Trowbridge-Reitz model used by specular reflection except sampled along the view vector rather than the reflection. The *baseColor* factor causes the transmitted light to be tinted by the surface.
where *T* is the transmission percentage defined by this extension's `transmission` and `transmissionTexture` properties. *D<sub>T</sub>* and *G<sub>T</sub>* are the microfacet distribution and shadowing functions for the transmitted light, which are the same models used by specular reflection, except sampled along the view vector rather than the reflection. The *baseColor* factor causes the transmitted light to be tinted by the surface.


Light that penetrates a surface and is transmitted will not be diffusely reflected so we also need to modify the diffuse calculation to account for this.
*f*<sub>*diffuse*</sub> = (1 - *F*) * (1 - *T*) * *diffuse*

Optical transparency does not require any changes whatsoever to the specular term. So this can all be rearranged so that the transmitted light amounts to a modifaction of the diffuse lobe.
*f* = (1 - *F*) * (*T* * *D<sub>T</sub>* + (1 - *T*) * *diffuse*) + *f*<sub>*specular*</sub>
emackey marked this conversation as resolved.
Show resolved Hide resolved

## Implementation Notes
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm leaning towards that we should require a painter algorithm (depth sorting) of triangles - in my opinion this should be normative.
Making depth sorting of triangles normative will make a huge step towards consistent result across viewers (bar blurring and possibly other effects)
Without it whole objects may pop in and out of existence......

However, I'm not sure how to approach blurring since I think this will be the most 'heavy' effect to implement for multiple layers/objects.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Depth sorting of triangles is not going to be reasonable on all platforms due to the number of passes required (or having the ability to use linked-lists of fragments which isn't possible in WebGL). Besides, I think rendering techniques are out of scope of glTF. Yes, there will be differences between renderers but as long as they do the blending in the way described, I think that's enough.
Blurring of the transmission is pretty cheap if they just sample the mips of the background texture. The background render texture will probably be required anyway to do the appropriate blending.

Copy link
Contributor

@donmccurdy donmccurdy Jul 5, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that sorting triangles is prohibitively expensive. Maybe a dedicated model viewer (note: model viewers are a subset of all glTF clients) can do that when the camera and object are stationary, but it's not a requirement we should have in the extension spec.

But on a similar point — the core specification says this about alpha blending:

Whether depth value is written or whether to sort is up to the implementation.

In retrospect, I think we could have made a normative requirement that depth not be written for alpha blend materials. Should we specify this for transmission? Or is this not an issue, because transmissive objects are treated as opaque (or rendered in an entirely separate pass)?

Copy link

@rsahlin rsahlin Jul 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Depth sorting of triangles is not going to be reasonable on all platforms due to the number of passes required (or having the ability to use linked-lists of fragments which isn't possible in WebGL).

I agree that if all layers have to support blurring an engine could require multiple passes (render to texture, minify then sample) which could become a performance bottleneck.
However - 'just' sorting the triangles of transmission objects could be done in a single pass if effects needing to sample the objects behind are left out.
This would leave us with viewers that would at least display transparent objects in the correct order and visibility.

Yes, the blurring itself is quite cheap - it's having to render out to texture, forcing multiple passes, that will be mostly heavy, plus generating the mip-levels.

I also do not like us to be so tied to WebGL - just because something can not be done in WebGL should, in my opinion, not mean that we leave it out.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hope "blurring" is just in short we do it physically - as far as possible - correct.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hope "blurring" is just in short we do it physically - as far as possible - correct.

Sure, that's what I mean anyway. :-)

The point I'm trying to make is that we should require a minimum of visibility through triangles using transmission.
Meaning that not only the background should show through - any other primitives (that may also use transmission) should also be visible.
However, what effects to apply to each of these primitives is optional - for instance the roughness that will result in blurring (since will require multiple passes on todays hardware)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also do not like us to be so tied to WebGL - just because something can not be done in WebGL should, in my opinion, not mean that we leave it out.

I agree with this in principle but WebGL will have a huge influence since we want glTF to be viewable on the web.

Copy link
Contributor

@donmccurdy donmccurdy Jul 7, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is a WebGL problem. Requiring that implementations sort triangles, in realtime, is extremely burdensome on any platform. Yes, there are cases where it may be possible (i.e. few enough triangles), but we really cannot impose this at the data format level.

Is there a reason these requirements cannot be in the 3D Commerce Certification process, instead?

donmccurdy marked this conversation as resolved.
Show resolved Hide resolved
Rendering transparency in a real-time rasterizer in an efficient manner is a difficult problem, especially when an arbitrary number of transparent polygons may be overlapping in view. This is because rendering transparency is order-dependent (i.e. we see background objects through foreground objects) and also because the rendering of absorption and reflections involves two distinct blend modes. Consequently, it may not be possible on the target platform to render every transparent polygon in the correct order, in a reasonable time, and with the correct blending. Therefore, correct ordering is not an absolute requirement when implementing this extension in realtime renderers, nor is rendering all potentially overlapping layers. However, it is expected that, at a minimum, opaque objects will be visible through a transmitting surface and the blending of the surface will match the above spec.
<figure>
<img src="./figures/Multi-layer Transparency.png"/>
<figcaption><em>On the left, only opaque objects are visible through the sphere. Each subsequent image shows an additional layer of transparency visible through the front-most transparent surface. The minimum expectation for a compliant renderer is to render only opaque objects (i.e. like the first image). Additional transparent layers may be rendered but are not required.</em></figcaption>
</figure>
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
{
"$schema": "http://json-schema.org/draft-04/schema",
"title": "KHR_materials_transmission glTF extension",
"type": "object",
"description": "glTF extension that defines the optical transmission of a material.",
"allOf": [ { "$ref": "glTFProperty.schema.json" } ],
"properties": {
"transmissionFactor": {
"type": "number",
"description": "The base percentage of light transmitted through the surface.",
"default": 0.0,
"minimum": 0.0,
"maximum": 1.0,
"gltf_detailedDescription": "The base percentage of non-specularly reflected light that is transmitted through the surface. i.e. of the light that penetrates a surface (isn't specularly reflected), this is the percentage that is transmitted and not diffusely re-emitted."
},
"transmissionTexture": {
"allOf": [ { "$ref": "textureInfo.schema.json" } ],
"description": "A greyscale texture that defines the transmission percentage of the surface. This will be multiplied by transmissionFactor.",
"gltf_detailedDescription": "The percentage of non-specularly reflected light that is transmitted through the surface. i.e. of the light that penetrates a surface (isn't specularly reflected), this is the percentage is transmitted and not diffusely re-emitted. This will be multiplied by the transmissionFactor."
lexaknyazev marked this conversation as resolved.
Show resolved Hide resolved
},
"extensions": { },
"extras": { }
}
}