[x3d-public] X_ITE implementation of glTF material extensions

Holger Seelig holger.seelig at yahoo.de
Sun Jun 30 01:16:02 PDT 2024 

I finally implemented the new browser option ‚ColorSpace‘ with the three values SRGB, LINEAR_WHEN_PHYSICAL_MATERIAL (default), and LINEAR. It behaves exactly like Castle’s ColorSpace global variable (https://castle-engine.io/color_space), including affecting backgrounds, and image based lighting textures. I think this is a big step forward towards a linear color workflow.

Although the LINEAR_WHEN_PHYSICAL_MATERIAL option is perhaps born out of necessity, it is probably justified as it is good as a transition from sRGB to linear color space workflow.

Additionally, I created a test case, testing UnlitMaterial , Material, PhysicalMaterial. All material with and without textures. There are three buttons below the spheres, where you can switch between the three ColorSpace modes in X_ITE. In Castle you can change ColorSpace in the ‚View‘ menu.

Test case:
https://create3000.github.io/Library/Tests/Components/Shape/ColorSpace.x3d

Test case in X_ITE Playground:
https://create3000.github.io/x_ite/playground/?url=https://create3000.github.io/Library/Tests/Components/Shape/ColorSpace.x3d

Michalis, you will be probably happy to hear that I have also removed UnlitMaterialExtension in favor of UnlitMaterial and a linear color space setting, which is now active in the glTF Sample Viewer on the X_ITE website, what puts everything, including UnlitMaterial, now into the linear color space.

## EXT_sRGB

I also stumble more or less often over the fact that it would be necessary to know whether a texture is sRGB (e.g. baseColorTexture) or linear (e.g. normalTexture), because then you could 'upload' these textures, as it would be better, as sRGB (or not) to the graphics card, to get rid of the color space conversions. The same problem that you (Michalis) have already mentioned also exists with the possible sRGB framebuffer, which cannot yet be used. If the color space is completely linear, then an sRGB framebuffer would be an option.

The corresponding test case from glTF is this one:
https://raw.githubusercontent.com/KhronosGroup/glTF-Sample-Models/master/2.0/TextureLinearInterpolationTest/glTF/TextureLinearInterpolationTest.gltf

And in glTF Sample Viewer:
https://create3000.github.io/x_ite/laboratory/gltf-sample-viewer/?url=TextureLinearInterpolationTest

The test still fails because texture interpolation is still done in sRGB color space. This only gets solved if WebGL EXT_sRGB is used.
https://developer.mozilla.org/en-US/docs/Web/API/EXT_sRGB

Best regards,
Holger

--
Holger Seelig
Leipzig, Germany

holger.seelig at yahoo.de
https://create3000.github.io/x_ite/

> Am 27.06.2024 um 17:12 schrieb Holger Seelig via x3d-public <x3d-public at web3d.org>:
> 
> I believe it is possible to add a browser option 'ColourSpace' to X_ITE, as Castle does. (https://castle-engine.io/color_space) With the three options SRGB, LINEAR_WHEN_PHYSICAL_MATERIAL and LINEAR. UnlitMaterial would then behave in the same way as UnlitMaterialExtension does now if LINEAR is selected. However, this would then require switching when glTF is converted to UnlitMaterial with KHR_materials_unlit, because, as in Castle, the default is LINEAR_WHEN_PHYSICAL_MATERIAL, isn't it? And then there is no way back, because ‚ColorSpace' is a global option and all materials are affected.
> 
> With an UnlitMaterialExtension, the LINEAR calculation would be limited to PhysicalMaterial. UnlitMaterial and Material could remain in the sRGB colour space, as it has been for historical reasons. If these materials are in the sRGB colour space, it makes colour mixing with a ColorChooser much easier, as these usually display and output sRGB colours. It also makes it easier to set the same colour in HTML/CSS and X3D, otherwise it gets a bit tricky.
> 
> It is a difficult decision.
> 
> Regards,
> Holger
> 
> --
> Holger Seelig
> Leipzig, Germany
> 
> holger.seelig at yahoo.de
> https://create3000.github.io/x_ite/
> 
>> Am 27.06.2024 um 14:55 schrieb Michalis Kamburelis <michalis.kambi at gmail.com>:
>> 
>> Thank you for the answers!
>> 
>> As for KHR_materials_pbrSpecularGlossiness:
>> 
>> Indeed some Sketchfab models use KHR_materials_pbrSpecularGlossiness ,
>> as internal Sketchfab exporter uses it in some cases. It seems
>> Sketchfab didn't update their tools to follow Khronos recommendations
>> (to use KHR_materials_specular instead of
>> KHR_materials_pbrSpecularGlossiness). Which is also understandable --
>> I don't think there's a straightforward conversion that exactly
>> preserves look from KHR_materials_pbrSpecularGlossiness to
>> KHR_materials_specular, even though they fulfill the same use-case. So
>> Sketchfab doesn't want to break compatibility (look of models).
>> 
>> That is why I wondered to implement
>> KHR_materials_pbrSpecularGlossiness in some way, though for now just
>> recommend users to ask model authors to not use this material type --
>> https://castle-engine.io/sketchfab . It's on our page about Sketchfab
>> integration, because that's where users in practice encounter this
>> issue :)
>> 
>> All good, I mean it is of course a practical and valid decision to
>> support KHR_materials_pbrSpecularGlossiness (by equivalent in X3D
>> SpecularGlossinessMaterial) for the time being, since real models use
>> it, despite what Khronos recommends. Thanks for the explanation!
>> 
>> As for unlit:
>> 
>> The "unlit" field in X3DOM PhysicalMaterial (
>> https://doc.x3dom.org/developer/x3dom/nodeTypes/PhysicalMaterial.html
>> ) -- I'm not sure, but I think it predates the X3D 4.0 and
>> UnlitMaterial node. X3DOM doesn't implement UnlitMaterial for now at
>> all, looking at docs ( https://doc.x3dom.org/developer/classes.html )
>> .
>> 
>> So here I would vote for sticking to the standard, in both X3DOM and
>> X_ITE :) That is, UnlitMaterial should fulfill the need to translate
>> glTF unlit materials to X3D, and is simpler. X3DOM's
>> PhysicalMaterial.unlit, and X_ITE UnlitMaterialExtension, can
>> hopefully always be replaced by using UnlitMaterial.
>> 
>> As for sRGB workflow:
>> 
>> It is indeed not specified in X3D. X3DOM has their extension to
>> specify it ( https://doc.x3dom.org/tutorials/lighting/gamma/ ). Castle
>> Game Engine uses linear workflow it too ( though by default only for
>> PhysicalMaterial, see https://castle-engine.io/color_space , but you
>> can make it used always, it should actually affect Material and
>> UnlitMaterial too ). See
>> https://github.com/michaliskambi/x3d-tests/wiki/Gamma-correction-in-X3D-and-glTF
>> , https://github.com/michaliskambi/x3d-tests/wiki/Gamma-Correction-in-Future-X3D
>> for my knowledge.
>> 
>> I was recommending a "cautious" approach in X3D 4.0 here, because just
>> saying "use linear workflow for everything, like glTF" *will* change
>> the look of the existing models. But I think in the end we are in
>> situation when this is not specified, and everyone does something a
>> bit different. All in all, we should just all switch to "use linear
>> workflow for everything, like glTF" .
>> 
>> So, I'm older and wiser now :), and today I'm all after changing X3D
>> spec to just say it. That is, simply "use linear workflow for
>> everything, like glTF". The more exact wording what it should mean are
>> on https://github.com/michaliskambi/x3d-tests/wiki/Gamma-correction-in-X3D-and-glTF
>> , https://github.com/michaliskambi/x3d-tests/wiki/Gamma-Correction-in-Future-X3D
>> , these were made looking at glTF and they just seem to make sense.
>> 
>> Regards,
>> Michalis
>> 
>> śr., 26 cze 2024 o 17:48 Holger Seelig <holger.seelig at yahoo.de> napisał(a):
>>> 
>>> I have added SpecularGlossinessMaterial, as there are models on the internet that use it (sketchfab), so that these models can also be displayed. X3DOM also has a way to display this material. Furthermore, it is apparently not possible to convert this material with the associated textures by using PhysicalMaterial.
>>> 
>>> I added UnlitMaterialExtension for now, because X3DOM also has an *unlit* field in PhysicalMaterial.
>>> 
>>> https://doc.x3dom.org/developer/x3dom/nodeTypes/PhysicalMaterial.html
>>> 
>>> An important aspect is also the sRGB workflow, which is specified in PhysicalMaterial, but is not mentioned in X3D (or are there texts about it).
>>> 
>>> Best regards,
>>> Holger
>>> 
>>> --
>>> Holger Seelig
>>> Leipzig, Germany
>>> 
>>> holger.seelig at yahoo.de
>>> https://create3000.github.io/x_ite/
>>> 
>>> Am 26.06.2024 um 14:54 schrieb Michalis Kamburelis <michalis.kambi at gmail.com>:
>>> 
>>> Great news! I'm reading your node docs, excellent work in getting this
>>> specified and implemented!
>>> 
>>> I have a plan to implement these material extensions in Castle Game
>>> Engine / Castle Model Viewer as well (
>>> https://castle-engine.io/roadmap#gltf_material_features ). Looks like
>>> you beat me to it with X_ITE, and it makes me very happy :)  (Also
>>> because it means I can look at your nodes and code and my task is much
>>> easier :) ).
>>> 
>>> Some initial thoughts about the spec of new functionality:
>>> 
>>> 1. Expressing functionality as "extensions" of PhysicalMaterial (I see
>>> you have "PhysicalMaterial.extensions", MFNode with
>>> X3DMaterialExtensionNode,
>>> https://create3000.github.io/x_ite/components/shape/physicalmaterial/
>>> ):
>>> 
>>>   This is great solution, this expressed the intention nicely (this
>>> information is extra data, "extension", and without it things look
>>> worse but make sense).
>>> 
>>>   I'm looking at this both from Castle Game Engine / Castle Model
>>> Viewer author perspective, also from the perspective of future X3D
>>> versions. A lot of your extensions, including the
>>> "PhysicalMaterial.extensions" field and nodes like
>>> SheenMaterialExtension, ClearcoatMaterialExtension could definitely be
>>> part of future X3D (4.1?) version.
>>> 
>>> 2. Comments specifically about SpecularGlossinessMaterial (
>>> https://create3000.github.io/x_ite/components/x-ite/specularglossinessmaterial/
>>> ):
>>> 
>>>   Note that KHR_materials_pbrSpecularGlossiness is deprecated, and
>>> the recommendation is to follow instead KHR_materials_specular which
>>> addresses a similar use-case. In Castle Game Engine / Castle Model
>>> Viewer we deliberately decided, for this reason, to not support
>>> KHR_materials_pbrSpecularGlossiness and just explain it to users (
>>> https://castle-engine.io/sketchfab ).
>>> 
>>>   I of course understand it is a practical decision, if your users
>>> demand KHR_materials_pbrSpecularGlossiness then
>>> SpecularGlossinessMaterial makes sense. I'm just saying that this
>>> should probably not go to future X3D spec.
>>> 
>>>   Just like Khronos recommends KHR_materials_specular over
>>> KHR_materials_pbrSpecularGlossiness, we should in X3D recommend
>>> SpecularMaterialExtension over SpecularGlossinessMaterial.
>>> 
>>> 3. I see you added also UnlitMaterialExtension, can you expand why do
>>> you need it?
>>> 
>>>   I know your approach is a bit more consistent with glTF, that has
>>> "physical material with KHR_materials_unlit".
>>> 
>>>   That said, I deliberately deviated here for X3D 4.0, adding
>>> instead a separate node "UnlitMaterial". "UnlitMaterial" does feel
>>> more natural -- being unlit is, conceptually, not an extension of PBR
>>> lighting equations (or PBR specular, or Phong lighting equations...).
>>> Being unlit means you throw away the usual lighting equations, and
>>> just have very simple situation where resulting color is emissiveColor
>>> * optional emissiveTexture. This makes "UnlitMaterial" spec simple,
>>> this also sidesteps glTF question (that used to be ambiguous in older
>>> glTF spec version) of how to combine glTF base and emissive color in
>>> case of KHR_materials_unlit (because in X3D, we just have
>>> "UnlitMaterial" with "UnlitMaterial,emissiveColor" -- it's simpler),
>>> this also allows natural optimizations on the renderer side (unlit can
>>> use completely different set of simple shaders).
>>> 
>>>   So ideally, I see "UnlitMaterial" as X3D-equivalent of
>>> "KHR_materials_unlit". If there is a need for UnlitMaterialExtension,
>>> I'm curious to know why, and can we avoid it, to keep X3D spec simple
>>> :)
>>> 
>>> Many thanks for your work. This is great advancement for X3D! I
>>> absolutely recommend everyone on this list to click on Holger's links
>>> to demos and extensions, we absolutely should look at this
>>> functionality as potentially becoming available in other X3D browsers
>>> (I will definitely want to implement (subset of it) in Castle Game
>>> Engine / Castle Model Viewer) and in future X3D spec versions.
>>> 
>>> Best regards,
>>> Michalis
>>> 
>>> 
>>> wt., 25 cze 2024 o 11:52 Holger Seelig via x3d-public
>>> <x3d-public at web3d.org> napisał(a):
>>> 
>>> 
>>> With the current release v10.0.1, all glTF material extensions are now available, i.e. when a glTF file is parsed, these extensions are automatically converted to X3D. There is now an X3D node for each glTF extension. These nodes can also be referenced directly in X3D files. Extensions for glTF materials are converted to the new X3DMaterialExtensionNode nodes, which can be used as a child of PhysicalMaterial node and the new SpecularGlossinessMaterial node. These material nodes now have a new field »extensions« for this purpose. The introduction of the »extensions« field has only a minimal impact and leads to the greatest possible compatibility.
>>> 
>>> To get an idea of what a great difference these new material extensions make, check out our glTF Sample Viewer. Take some time and look through all the examples. I am sure you will be amazed.
>>> 
>>> https://create3000.github.io/x_ite/laboratory/gltf-sample-viewer/
>>> 
>>> Here are three selected examples, but there are many more:
>>> 
>>> https://create3000.github.io/x_ite/laboratory/gltf-sample-viewer/?url=AnisotropyBarnLamp
>>> https://create3000.github.io/x_ite/laboratory/gltf-sample-viewer/?url=DragonAttenuation
>>> https://create3000.github.io/x_ite/laboratory/gltf-sample-viewer/?url=MosquitoInAmber
>>> https://create3000.github.io/x_ite/laboratory/gltf-sample-viewer/?url=ToyCar
>>> 
>>> Implemented glTF Extensions:
>>> 
>>> All glTF extensions implemented with this version are listed below:
>>> 
>>> X3DOneSidedMaterialNode
>>> 
>>> * KHR_materials_pbrSpecularGlossiness implemented as SpecularGlossinessMaterial node.
>>> 
>>> X3DMaterialExtensionNode
>>> 
>>> * KHR_materials_anisotropy implemented as AnisotropyMaterialExtension node.
>>> * KHR_materials_clearcoat implemented as ClearcoatMaterialExtension node.
>>> * KHR_materials_dispersion implemented as DispersionMaterialExtension node.
>>> * KHR_materials_emissive_strength implemented as EmissiveStrengthMaterialExtension node.
>>> * KHR_materials_ior implemented as IORMaterialExtension node.
>>> * KHR_materials_iridescence implemented as IridescenceMaterialExtension node.
>>> * KHR_materials_sheen implemented as SheenMaterialExtension node.
>>> * KHR_materials_specular implemented as SpecularMaterialExtension node.
>>> * KHR_materials_transmission implemented as TransmissionMaterialExtension node.
>>> * KHR_materials_unlit implemented as UnlitMaterialExtension node.
>>> * KHR_materials_volume implemented as VolumeMaterialExtension node.
>>> 
>>> Switch
>>> 
>>> * KHR_materials_variants implemented as Switch node.
>>> 
>>> These new nodes are initially available in the X_ITE component and documented here:
>>> https://create3000.github.io/x_ite/components/#x_ite
>>> 
>>> Make X3D even better!
>>> Best regards,
>>> Holger
>>> 
>>> --
>>> Holger Seelig
>>> Leipzig, Germany
>>> 
>>> holger.seelig at yahoo.de
>>> https://create3000.github.io/x_ite/
>>> 
>>> _______________________________________________
>>> x3d-public mailing list
>>> x3d-public at web3d.org
>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>> 
>>> 
> 
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20240630/c75fa00f/attachment-0001.html>

More information about the x3d-public mailing list