KHR_materials_ior

[proog128]

An extension for the metallic-roughness material that makes the index of refraction configurable. At the moment, there is a fixed value of 1.5, corresponding to F0 = 0.04.

This extension is similar to KHR_materials_specular proposed in #1677, but should work better in combination with KHR_materials_transmission (#1698). It allows to set IOR>2, which is not uncommon for transparent materials.

The extension uses some notation introduced in #1717.

[bhouston]

This is an amazing extension. We should adopt it. It is relatively simple. I highly support IOR rather than specifying F0 directly as it is much more flexible and reusable in other BRDFs.

[UX3D-nopper]

Please remove the KHR_materials_volume entry, otherwise we do have a cyclic dependency.
KHR_materials_volume could reference this extension.

[proog128]

I refactored large parts of the extension. No change in behavior, but I hope it is now easier to understand and it better aligns with the notation in the core spec.

I also rephrased the interaction with KHR_materials_volume to make it clear that there is no dependency, just informal information ("README"). Do you like it better now? Or would you prefer to not mention other extensions at all if there is no explicit dependency? I liked the idea of providing additional information for implementors on how the extensions interact with each other.

[UX3D-nopper]

If we want to ratify IOR quite soon, we need to kick out the references to the not yet ratified ones.
Also, KHR_materials_volume and KHR_materials_specualr can later reference KHR_materials_ior.
Please no cyclic dependencies.

[proog128]

@UX3D-nopper Thanks for clarifying, now I understand your concerns: mentioning other (non-ratified) extensions prevents fast ratification. I am still a bit hesitant to remove the references, because it makes it harder to understand the big picture... Or we track them in a separate document? I once created an overview in #1738, maybe this could be a starting point?

Meanwhile, I will remove the duplication as suggested by @rsahlin.

In general, I think we have to define what "dependency" means in terms of extensions.

• Does it mean that A requries B?
• Or that A is related to B? (ie. ior and specular are related, because they are multiplied)
• Or that A is compatible to B? (ie. clearcoat is compatible to glTF base, but not to pbrSpecGloss)
• Or that A mentions B? (ie. sheen extension describes how it interacts with clearcoat; order of layers)

What I am trying to do (also in #1738) is to create a unified material model that integrates all effects (sheen, clearcoat, ior, refraction, specular, specular color, ...). Each parameter has an appropriate default value, so that leaving out a parameter just removes one degree of freedom, but does not change the interaction between the effects. That means that glTF 2.0 base is just a special case of the more general unified material model. The nice consequence of this is that if parameters are put into several extensions, all of them are compatible and there are no dependencies in the sense of "A requires B".

[UX3D-haertl]

Shouldn't it be written down in the README.md that this extension can not be used together with KHR_materials_pbrSpecularGlossiness?

One could add it in a similar way how it is done in the KHR_materials_sheen PR:

Exclusions

• This extension must not be used on a material that also uses KHR_materials_pbrSpecularGlossiness.

[UX3D-haertl]

How should ior be used if a metallic factor between 0 and 1 is used?

[proog128]

@UX3D-haertl The ior has no effect on the metal BRDF:

dielectricSpecular = ((ior - 1)/(ior + 1))^2
cdiff = lerp(baseColor.rgb * (1 - dielectricSpecular.r), black, metallic) 
F0 = lerp(dieletricSpecular, baseColor.rgb, metallic) 

[emackey]

In some software, including Blender, the IOR has an effect on how "blurry" the transmission is, when roughness is nonzero. This can happen even for thin-walled transmission.

Borrowing a line of thought from Emmet, one can imagine that on a thin-walled piece of geometry, the microfacets on the front and back are not correlated, and so on a rough surface the front and back are not parallel, forming a series of little prisms that can scatter the light. The base roughness essentially controls the width of these prisms (or how "non-parallel" the front vs. back has become). But if the IOR is exactly 1.0, the prisms do nothing to refract the light, so no blurring of the transmission. Conversely, for high values of IOR, even small amounts of roughness cause a lot of blurring, due to steep refraction angles.

Can/should we define this effect in the IOR extension here?

[proog128]

Good point. Yes, the microfacet distributions on front and back surface in the thin-walled model are assumed to be uncorrelated. We can create a simple scene to verify that the blurring effect is correct: render a thin box (closed mesh, not thin-walled) with a path tracer; the objects behind the box/the background become blurry. What we can also observe in this simple scene is that the IOR affects the blurriness: when it approaches zero, the blurriness gets smaller and smaller, and for an IOR of 1 the box appears to be clear.

There is a section in the slides from Imageworks (slides 34-41) that deals with this issue. It derives an IOR dependent factor that needs to be multiplied to the transmission roughness of the thin transmission BSDF. It should be easy to adopt this for PBR Next.

If we decide to include this correction factor, I would prefer to have this in KHR_materials_transmission rather than KHR_materials_ior.
As far as I understand it only affects transmission only, not reflection, so I think it belongs into the transmission extension.

[emackey]

I think it belongs into the transmission extension

Yes, but that extension is under review already, so modifications there could reset the clock. Would it be OK to put it in IOR instead? Later these will all fold up into a unified future version of glTF anyway.

[proog128]

I am afraid that if we take the mapping from Imageworks, we have to put it into KHR_materials_transmission. The reason is that the default IOR of 1.5 causes a remapping of the roughness. So if KHR_materials_ior is not present, we still would have to remap the thin roughness.

This is the mapping:

I thought a bit more about it, and what consequences it would have if we add it. We have to decide whether we apply it to the full thin dielectric BSDF (i.e., reflection and transmission lobes of the transmissive portion of the material) or to the dielectric BTDF only. I cannot find a clear statement about that in the slides. You could probably come up with good reasons for either. If it's applied to the full BSDF (BRDF and BTDF), we need to separate the thin glass BSDF from the remaining components. If it's applied to the BTDF only, we suddenly have different roughnesses for reflection and transmission lobes, which may require some special handling (albedo scaling) for energy conservation.

I was also trying to find out whether there is (dedicated) support for this in other renderers/material models. Most don't seem to have a special treatment for thin materials, like for example Blender Cycles. So the IOR-dependent blurriness of glass in Cycles comes only due to the fact that the material is assumed to be volumetric, and you cannot change that (or I missed the setting?). Standard Surface probably behaves similar, I also couldn't find a mentioning of a special thin BTDF in the documentation. Enterprise PBR has a special thin case (Boolean switch), but there is no roughness mapping yet (we are considering it for a future version). Regarding node-based materials: MDL and MaterialX ShaderGen both have a thin flag. But as far as I can tell both do not have a roughness remapping in any of their BSDFs.

The reason for not having a roughness remapping might be simple: it's easy to bake (in almost all cases). And if thin roughness is set by an artist based on intuition, to make it look realistic, the mapping is not needed. It's only needed if it's required to switch between thin and non-thin cases and if then expect a match between the two. (And, of course, to make the model more physically-plausible).

All that makes me a bit hesitant to rush this into the extension now...

[emackey]

The special IOR value of zero is explained in the Specular specification, but not mentioned here in the IOR spec. Can it be mentioned here too, at least briefly?

[proog128]

It's mentioned in the "Extending Materials" section:

Valid values for ior are numbers greater than or equal to 1. In addition, a value of 0 is allowed. This value gives full weight to layer, i.e., the Fresnel term evaluates to 1 independent of the view or light direction. It is useful in combination with KHR_materials_specular to seamlessly support the specular-glossiness workflow.

[emackey]

Merging this. Status will remain "Draft" for at least a few more weeks, but it will be hosted in the main glTF repository.