[x3d-public] X_ITE implementation of glTF material extensions

Fri Jun 28 10:07:22 PDT 2024

As for Castle Game Engine "invention" of csLinearWhenPhysicalMaterial
mode (and making it default, https://castle-engine.io/color_space ):

I admit I both like and dislike my own invention of
csLinearWhenPhysicalMaterial :), after using it for some time. Below
are my thoughts. Overall, yeah, it's a difficult topic to satisfy all
possible needs and at the same time not over-complicate :)

Advantages of csLinearWhenPhysicalMaterial:

A. Having it as default makes "Material" behave as before (so
calculate in sRGB, no linear workflow, no gamma correction).

B. For "UnlitMaterial", is also seemed most natural to "do nothing",
just like 2D engines do without gamma correction. It was
backwards-compatible to how we did unlit display in CGE before, e.g.
for games using 2D Spine animations and sprite sheets. For 2D games,
most games use unlit for everything, so it was simplest to just "do
nothing" for unlit.

C. At the same time, "PhysicalMaterial" is calculated in linear space.
This makes it more correct, and also consistent with glTF. Nobody
expects "PhysicalMaterial" without gamma correction :)

Disadvantages of csLinearWhenPhysicalMaterial:

D. It creates this weird inconsistency for "what to do with unlit".
glTF says to apply gamma correction always, also for unlit. So to be
really compatible, in CGE one should set ColorSpace:=csLinear (not
csLinearWhenPhysicalMaterial) to calculate all materials (when reading
glTF, in CGE we convert them to either UnlitMaterial or
PhysicalMaterial) in linear space.

E. Having mixed workflows (some materials using sRGB, some using
linear) is harder to implement.

    One, because it's always more complicated to have a mixture of 2
approaches in code :)

    Second, because it's harder to use OpenGL features that accelerate
linear workflow. There are 2 things: sRGB texture formats (
https://www.khronos.org/opengl/wiki/Image_Format#sRGB_colorspace ),
and sRGB framebuffer (see
https://www.khronos.org/opengl/wiki/Framebuffer , GL_FRAMEBUFFER_SRGB
). Together, it means that all the "pow" calls I mentioned in
https://github.com/michaliskambi/x3d-tests/wiki/Gamma-correction-in-X3D-and-glTF
are actually not necessary, i.e. shaders don't call "pow" explicitly,
hardware does it in a way that is probably super-optimized, shader
never has to explicitly call "pow".

    For textures, having a mixture of sRGB / linear workflows means
you cannot just load all textures to the same format. It also means
sometimes one must have 2 versions of the same texture URL loaded to
GPU ( see example "Discussion" in
https://github.com/michaliskambi/x3d-tests/wiki/Gamma-Correction-in-Future-X3D
).

    For framebuffer, it means one cannot just use GL_FRAMEBUFFER_SRGB.
Since some things written to framebuffer come from sRGB workflow, some
from linear workflow.

That's why I'm more leaning now towards simplest solution, like glTF.
Just "let's apply linear workflow to everything, including
UnlitMaterial". Everything goes through linear workflow, everything is
correct, implementations are simple. I understand this is also what
X3DOM does by default (
https://github.com/michaliskambi/x3d-tests/wiki/Gamma-correction-in-X3D-and-glTF
).

For extra configurability, I guess I would go to just expose

- at each texture (ImageTexture) in what colorspace it is
- what is framebuffer colorspace

This would be super-configurable and also still allow to use OpenGL
features (AD E) mentioned above easily by implementations.

I don't think it would be good to have 2 nodes
(UnlitMaterialExtension, UnlitMaterial) to express something very
similar and only differ in whether they are in linear or sRGB -- this
seems like something that could easily confuse people. I recognize it
would solve by problem mention in "AD D" above -- but it's yet another
complication :) We would effectively have "unlit that is probably
converted from glTF" and "unlit that is probably not converted from
glTF" -- which means we complicate things, instead of having "just one
way to express unlit material". And note that CGE converts glTF to
UnlitMaterial (not UnlitMaterialExtension), though of course
implementation could change to whatever is more correct.

Moreover, I admit for me, Khronos/glTF idea of "squeezing" the "unlit"
material into physical material seems a bit weird -- it's not how
authors think about unlit, and not how we implement unlit, i.e. unlit
is not an "extension" of physical calculation, it completely sidesteps
any lighting calculation. That's why I would rather not introduce
UnlitMaterialExtension to spec -- UnlitMaterial should fulfill all
useful usage of "unlit", both when someone writes X3D from scratch,
and when someone converts glTF -> X3D.

I know it's a long email without a clear conclusion "what to do",
sorry :) Thank you for reading!

Regards,
Michalis

pt., 28 cze 2024 o 02:20 John Carlson via x3d-public
<x3d-public at web3d.org> napisał(a):
>
>
>
> On Thu, Jun 27, 2024 at 7:00 PM John Carlson <yottzumm at gmail.com> wrote:
>>
>> I’m looking forward to using the new material extensions on my “Rhodonea” surfaces.
>>
>> I see several outstanding points I have for X3D:
>>
>> 2.  X3DOM has subdivision.  Ideally, I wouldn’t have to create my own grid subdivisions.  Maybe NURBS might help.  I’m not really looking for splines, but “repeated geometry” similar to repeated texture would be useful, especially in spherical coordinates (greater than 2 pi radians).  For *one* Shape.  I have a “repeated” Sphere in mind.
>
>
> With the “repeated Sphere,” it would be interesting to specify the max and min of theta and phi in spherical coordinates.  Then perhaps a theta increment by phi increment “cell” size.  Then I morph the surface with shader parameters.  Providing different shader parameters to each GPU instance is key here.  Not just shader parameters for a single surface.
>
> So there’s a repeated instance shape and extending a mathematical domain of each instance.
>
> John
>>
>> On Thu, Jun 27, 2024 at 2:43 PM Brutzman, Donald (Don) (CIV) via x3d-public <x3d-public at web3d.org> wrote:
>>>
>>> Great dialog, insights, efforts, and results - thanks!
>>>
>>> We have a "short list" of key items for X3D4.1 now in Mantis.  This would be important to add, as well as review of Browser options.
>>>
>>> Mantis 1464: candidate features for X3D 4.1
>>> https://www.web3d.org/member-only/mantis/view.php?id=1464
>>>
>>>
>>> Mantis 1465: candidate features for HAnim 2.1
>>> https://www.web3d.org/member-only/mantis/view.php?id=1465
>>>
>>>
>>> As we pursue updating multiple file encodings and programming-language bindings, our review cycle will get shorter.  It took us ten years to do everything in X3D 4.0 and we have succeeded well.  I think that we can reduce that to under 2 years for all X3D specifications reaching 4.0 alignment, and am optimistic we might achieve a 1-year revision cycle after that.  We shall see...
>>>
>>> X3D Graphics Standards Relationships
>>> https://www.web3d.org/specifications/X3dGraphicsStandardsRelationships.png
>>>
>>>
>>> Have fun with X3D, glTF, HTML5, CSS, and the Web!  🙂
>>>
>>>
>>>
>>> all the best, Don
>>>
>>> --
>>>
>>> Don Brutzman  Naval Postgraduate School, Code USW/Br        brutzman at nps.edu
>>>
>>> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA    +1.831.656.2149
>>>
>>> X3D graphics, virtual worlds, navy robotics https://faculty.nps.edu/brutzman
>>>
>>>
>>>
>>> ________________________________
>>> From: x3d-public <x3d-public-bounces at web3d.org> on behalf of Michalis Kamburelis via x3d-public <x3d-public at web3d.org>
>>> Sent: Thursday, June 27, 2024 5:55 AM
>>> To: Holger Seelig <holger.seelig at yahoo.de>
>>> Cc: Michalis Kamburelis <michalis.kambi at gmail.com>; X3D <x3d-public at web3d.org>
>>> Subject: Re: [x3d-public] X_ITE implementation of glTF material extensions
>>>
>>> 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcastle-engine.io%2Fsketchfab&data=05%7C02%7Cbrutzman%40nps.edu%7C6164e4e4a06f4b25416c08dc96a8ad43%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638550898445416382%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2Ftg7ihNiwkB8TBYEPXtQ97%2BEoTyWLYeGJIF1YrVF0Q4%3D&reserved=0 . 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc.x3dom.org%2Fdeveloper%2Fx3dom%2FnodeTypes%2FPhysicalMaterial.html&data=05%7C02%7Cbrutzman%40nps.edu%7C6164e4e4a06f4b25416c08dc96a8ad43%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638550898445426280%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ycDjIj5AsbkDSrKxONqtRKY0cCeyidFmCaICDZzOHPo%3D&reserved=0
>>> ) -- 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc.x3dom.org%2Fdeveloper%2Fclasses.html&data=05%7C02%7Cbrutzman%40nps.edu%7C6164e4e4a06f4b25416c08dc96a8ad43%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638550898445432917%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=LEZ24s29Q5%2FSenOyOY09x8vrPWrzW3H4mvxVRVPafuo%3D&reserved=0 )
>>> .
>>>
>>> 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc.x3dom.org%2Ftutorials%2Flighting%2Fgamma%2F&data=05%7C02%7Cbrutzman%40nps.edu%7C6164e4e4a06f4b25416c08dc96a8ad43%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638550898445437999%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=wTGvUsCy%2FbdReBVxzXwo4wkgZDoF20C%2F44WMaZtBUj8%3D&reserved=0 ). Castle
>>> Game Engine uses linear workflow it too ( though by default only for
>>> PhysicalMaterial, see https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcastle-engine.io%2Fcolor_space&data=05%7C02%7Cbrutzman%40nps.edu%7C6164e4e4a06f4b25416c08dc96a8ad43%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638550898445442293%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=TAyv%2F63ibcFv1%2BF0ik6mqafjUHcsc9AltL7T2cRC7Kw%3D&reserved=0 , but you
>>> can make it used always, it should actually affect Material and
>>> UnlitMaterial too ). See
>>> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichaliskambi%2Fx3d-tests%2Fwiki%2FGamma-correction-in-X3D-and-glTF&data=05%7C02%7Cbrutzman%40nps.edu%7C6164e4e4a06f4b25416c08dc96a8ad43%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638550898445446407%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=vcx8ll0SNiG4PShgmttQk2EoUOh7R6jBAob6T3oFy60%3D&reserved=0
>>> , https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichaliskambi%2Fx3d-tests%2Fwiki%2FGamma-Correction-in-Future-X3D&data=05%7C02%7Cbrutzman%40nps.edu%7C6164e4e4a06f4b25416c08dc96a8ad43%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638550898445450465%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=C5zee29tpgqJnhW8Jx2FmI4yFIY%2Fvtmxybu8i%2B0kbVU%3D&reserved=0
>>> 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichaliskambi%2Fx3d-tests%2Fwiki%2FGamma-correction-in-X3D-and-glTF&data=05%7C02%7Cbrutzman%40nps.edu%7C6164e4e4a06f4b25416c08dc96a8ad43%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638550898445454486%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=rPvIE%2FTXkJVK9fKqPkX2AGHsyLEl85AQs3xLBENNcIY%3D&reserved=0
>>> , https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmichaliskambi%2Fx3d-tests%2Fwiki%2FGamma-Correction-in-Future-X3D&data=05%7C02%7Cbrutzman%40nps.edu%7C6164e4e4a06f4b25416c08dc96a8ad43%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638550898445458554%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=bDfwL2RaR9M2zMWa6yive5e5ODLSwGt0oTO9cL1EhOc%3D&reserved=0
>>> , 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc.x3dom.org%2Fdeveloper%2Fx3dom%2FnodeTypes%2FPhysicalMaterial.html&data=05%7C02%7Cbrutzman%40nps.edu%7C6164e4e4a06f4b25416c08dc96a8ad43%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638550898445462660%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Gx7yVm%2Bl29%2BSS9Uwc9E0QcqBRzjSzidyAWIO2T2bgm0%3D&reserved=0
>>> >
>>> > 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcreate3000.github.io%2Fx_ite%2F&data=05%7C02%7Cbrutzman%40nps.edu%7C6164e4e4a06f4b25416c08dc96a8ad43%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638550898445467284%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=SCudt9wpdP8CKxvd5ts03wyCQs3Oo6HsqiIX0u9Gmbw%3D&reserved=0
>>> >
>>> > 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcastle-engine.io%2Froadmap%23gltf_material_features&data=05%7C02%7Cbrutzman%40nps.edu%7C6164e4e4a06f4b25416c08dc96a8ad43%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638550898445471354%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=VSgDLY6hZyCcAM6K%2BcZ7lhUTB2UP7c68HWWHDTQB%2B1M%3D&reserved=0 ). 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcreate3000.github.io%2Fx_ite%2Fcomponents%2Fshape%2Fphysicalmaterial%2F&data=05%7C02%7Cbrutzman%40nps.edu%7C6164e4e4a06f4b25416c08dc96a8ad43%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638550898445475376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=ZU1EhPuk5jgEqGgVJQCoLCqgn2MZmBp2ulI1p%2B6g0M0%3D&reserved=0
>>> > ):
>>> >
>>> >    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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcreate3000.github.io%2Fx_ite%2Fcomponents%2Fx-ite%2Fspecularglossinessmaterial%2F&data=05%7C02%7Cbrutzman%40nps.edu%7C6164e4e4a06f4b25416c08dc96a8ad43%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638550898445479386%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=WQHxMbGDCZ%2FM7MiutqC%2B096YZxqBW2HY6tQC9bcFchQ%3D&reserved=0
>>> > ):
>>> >
>>> >    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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcastle-engine.io%2Fsketchfab&data=05%7C02%7Cbrutzman%40nps.edu%7C6164e4e4a06f4b25416c08dc96a8ad43%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638550898445483438%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=XMJOR%2BKshEnRkqeBquF0zMlGjoSYvzmpfrGncKM3InQ%3D&reserved=0 ).
>>>
>>> >
>>> >    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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcreate3000.github.io%2Fx_ite%2Flaboratory%2Fgltf-sample-viewer%2F&data=05%7C02%7Cbrutzman%40nps.edu%7C6164e4e4a06f4b25416c08dc96a8ad43%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638550898445487433%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=mA4Q2TCBwOiHdq7NqN6Hed94vavD6wWVHskOQjBsT7s%3D&reserved=0
>>> >
>>> > Here are three selected examples, but there are many more:
>>> >
>>> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcreate3000.github.io%2Fx_ite%2Flaboratory%2Fgltf-sample-viewer%2F%3Furl%3DAnisotropyBarnLamp&data=05%7C02%7Cbrutzman%40nps.edu%7C6164e4e4a06f4b25416c08dc96a8ad43%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638550898445491493%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=aUnIvjurvj5uz8jX5ObMWIWOvJYDJe5jqK7UkbEznio%3D&reserved=0
>>> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcreate3000.github.io%2Fx_ite%2Flaboratory%2Fgltf-sample-viewer%2F%3Furl%3DDragonAttenuation&data=05%7C02%7Cbrutzman%40nps.edu%7C6164e4e4a06f4b25416c08dc96a8ad43%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638550898445495570%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=KwcFkz0aXuZtx6gx8nSQViVDFCD67H4tE7yDAk8RbOU%3D&reserved=0
>>> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcreate3000.github.io%2Fx_ite%2Flaboratory%2Fgltf-sample-viewer%2F%3Furl%3DMosquitoInAmber&data=05%7C02%7Cbrutzman%40nps.edu%7C6164e4e4a06f4b25416c08dc96a8ad43%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638550898445499683%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=oo6h636Uc0gdEICk1uI0BaH0kaD5D7rbBo7oXnYY1C8%3D&reserved=0
>>> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcreate3000.github.io%2Fx_ite%2Flaboratory%2Fgltf-sample-viewer%2F%3Furl%3DToyCar&data=05%7C02%7Cbrutzman%40nps.edu%7C6164e4e4a06f4b25416c08dc96a8ad43%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638550898445503812%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2BxmVBXKgtrHD75UF45AyWrSrMFphocVdRCSi%2BwbXMqI%3D&reserved=0
>>> >
>>> > 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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcreate3000.github.io%2Fx_ite%2Fcomponents%2F%23x_ite&data=05%7C02%7Cbrutzman%40nps.edu%7C6164e4e4a06f4b25416c08dc96a8ad43%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638550898445507929%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=kxcbYApF%2FS3qw0jpFEHyutOyNyEgWmZ8w0ARtEj7mNg%3D&reserved=0
>>> >
>>> > Make X3D even better!
>>> > Best regards,
>>> > Holger
>>> >
>>> > --
>>> > Holger Seelig
>>> > Leipzig, Germany
>>> >
>>> > holger.seelig at yahoo.de
>>> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcreate3000.github.io%2Fx_ite%2F&data=05%7C02%7Cbrutzman%40nps.edu%7C6164e4e4a06f4b25416c08dc96a8ad43%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C638550898445512293%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=EG%2BgDIOo0g%2BxyZxAXRmOBBR3xxcJpHYuSywKV3RVbts%3D&reserved=0
>>>
>>> >
>>> > _______________________________________________
>>> > 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
>>> _______________________________________________
>>> 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