Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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_specular #1719
KHR_materials_specular #1719
Changes from 5 commits
3847e6b
cbd0d0e
3c3e048
0cf4352
e9fc32b
2102679
cdad1e2
75083f1
758eef8
20aa586
975a226
63d8343
e73ff06
05e0f7b
a2b0c05
a62f4c9
3da2dfc
c4f87b2
1cd78c6
06f85d7
e41ed16
abf2200
e53e478
229d53a
7a3c821
2002ef9
8ae8ce6
2c45562
4251448
395c52e
fc08213
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know that the current materials use a factor to scale texture values - however I would just like to raise the question if this property is used, eg how many models have an occlusion texture AND and the strength factor?
For this extension the question is simply - does anyone forsee using a specularTexture with a specularFactor other than 1.0?
Or can the specularTexture * specularFactor multiplication be removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can avoid the specular factor texture read if we premultiply it with the specular color.
In order to do this we need to change the calculations a bit:
fresnel_mix
would be defined as:And the version using IOR becomes:
This changes the attenuation of the base layer to include the specular color as well, which is actually more physically plausible.
This way we decouple the specular color from the Fresnel calculation and we are free to change the Fresnel implementation if we want.
Additionally we avoid modifying
f90
, which should always be 1.This is actually what V-Ray does and alSurface does a monochrome version of it:
where
maxComponent
returns the maximum of the R,G and B components.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a couple of reasons why
specular_color
is not used as a directional-independent multiplier to the specular BSDF in this extension. We thought about it a lot when we designed the Enterprise PBR Material, which is the foundation for #1718, #1719, and a few other extensions proposed for glTF PBR Next (click here for an overview). I think our guidelines and trade-offs apply equally well to glTF, therefore I'd like to explain them now.Compatibility to other material models
As far as I know there are two competing camps wrt. specular color.
Moreover, there is the specular-glossiness workflow and the glTF extension KHR_materials_pbrSpecularGlossiness. In this case, the specular color is also used as F0 color. Therefore, although not directly comparable (the workflow is different) I would put them into the first camp, together with Disney BRDF.
Our proposal/Enterprise PBR now is a compromise that can represent all these material models to a certain extend.
specular
andspecularTint
can be mapped tospecularColor
.specular
alone can be mapped without preprocessing (mentioned in the "Conversion" section in the extension),specularTint
needs preprocessing at export time.specular
parameter, the color to thespecularColor
parameter. It's lossy, but I think it is acceptable. Given the fact that glTF PBR Next has a lot less parameters than Standard Surface/V-Ray to make it rasterizer-friendly (Mobile, WebGL, ...), there will be some loss anyway, from other areas as well.IOR and number of texture fetches
I guess in your proposal the IOR is texturable, right? If yes, then we need a 4-channel texture: IOR (float) + specular color (float3). This is the same amount as in #1718 (KHR_materials_ior) and #1719.
The IOR in #1718 is not texturable, because it conceptually describes the refractive index of interface and the volume beneath the surface, not only the refractive index of the interface. I think this distinction is important, because only a uniform volume IOR ensures reciprocity (think of light tracing and/or nested dielectrics). Of course, artists want to use a texture to modulate the specular contribution, and, therefore, we provide them the parameters
specular
andspecularColor
. These parameters don't mess with the volume IOR, so they are reciprocal. I think we should be very strict about reciprocity (and energy conservation). The normative part of glTF must not require something that violates these principles. This way we ensure consistency across a large variety of rendering algorithms, from rasterizers to bidirectional path tracing, and be somewhat future-proof.To conclude, with #1718 and #1719, we also need only a 4-channel texture: specular (float) + specular color (float3). The uniform IOR is not textured.
In addition, there was some concerns regarding an IOR texture (see this comment), because of the additional overhead it introduces to convert from 1/ior (stored in the texture) to F0 (used in Fresnel).
Decoupling Fresnel and specular color
This is a good point, because probably some renderers want to use the full Fresnel equations, not the Schlick approximation. The specular color as it is defined in the extension works best with the Schlick approximation. However, I would consider this an implementation detail, therefore it is part of the non-normative section in the extension (not yet marked as such). It is possible to deal with it in combination with the full Fresnel equation, and I am happy to include this solution in the extension.
For example, I think it is possible to implement
fresnel_mix
as follows (untested, should work):In case
fr(ior)
is implemented with Schlick, it simplifies to