KHR_materials_pbrSpecularGlossiness extension #842
Conversation
|
|
||
| The specular property from specular-glossiness material model is the same as the base color value from the metallic-roughness material model for metals. The glossiness property from specular-glossiness material model is related with the roughness property from the metallic-roughness material model and is defined as `glossiness = 1 - roughness`. See [appendix](#appendix) for more details on how you can convert between these two material models. | ||
|
|
||
| The value for each property (`diffuse`, `specular`, `glossiness`) can be defined using factors or textures. The `specular` and `glossiness` properties are packed together in a single texture called `specularGlossinessTexture`. If a texture is not given, all respective texture components within this material model are assumed to have a value of `1.0`. The factors (`diffuseFactor`, `specularFactor`, `glossinessFactor`) scale, in linear space, the components given in the respective textures (`diffuseTexture`, `specularGlossinessTexture`). Texture content must be converted to linear space before it is used for any lighting computations. |
There was a problem hiding this comment.
Texture content must be converted to linear space
Does it imply that all textures should be stored in sRGB? If so, we must mention that.
Should it be possible to directly store linear data (e.g., via floats in future) in textures? Also, see #835.
There was a problem hiding this comment.
I don't think it's required that all textures are stored in sRGB. The two textures in this spec will be interpreted as sRGB (as indicated at the bottom), but other textures in extensions or future additions may or may not be depending on the situation. The point of this statement is to ensure that all the math must be done in linear space regardless of how it is stored.
| * **Required**: No | ||
|
|
||
|
|
||
| #### Additional maps |
There was a problem hiding this comment.
Can we be consistent on maps/textures term?
There was a problem hiding this comment.
My opinion is that texture is a type where map is a concept (i.e. maps are stored as textures). That said, maybe we can call this "common properties" to avoid the problem all together.
| If an asset includes the pbrSpecularGlossiness extension using the `extensionsRequired` property and does not specify any metallic-roughness properties then only a runtime that supports the pbrSpecularGlossines extension can render it. With this approach you trade off portability of the asset to ensure quality. | ||
|
|
||
| The following table describes the expected rendering behavior based on the material definitions included in the asset: | ||
|
|
There was a problem hiding this comment.
The last column implies that MR model isn't supported, right? Doesn't that contradict base 2.0 spec?
There was a problem hiding this comment.
To me, this is a general issue with extensionRequired. If we say an extension is required, then it basically means the asset isn't following the core spec anymore. This can happen with any extension, right? What happens if someone puts KHR_technique_webgl as required?
There was a problem hiding this comment.
the asset isn't following the core spec anymore
Right. But a runtime should support core spec anyway. So in what case does last column apply? Are we basically allowing to implement only SpecGloss and always convert MR?
|
Is it possible to provide a sound example (with screenshots) of SpecGloss superiority over MR? |
Updated PBR spec-gloss extension written against glTF 2.0
spec link - https://github.com/sbtron/glTF/tree/KHRpbrSpecGloss/extensions/Khronos/KHR_materials_pbrSpecularGlossiness