[x3d-public] X3D4 PBR specification review: updates and demos

[Andreas Plesch]

I saw mostly the alpha fields missing for complete glTF material
capability but I am not sure how critical these are.

x3dom does support an occlusion texture. It is implemented as a
simple, additional factor after lighting:

https://github.com/x3dom/x3dom/blob/810d5cd36f766bd9161f79881cab24dc6771aba5/src/shader/ShaderDynamic.js#L1178

As such, it is also independent of the PBR lighting model but required
for glTF support.

I agree it is best at this point to focus just on MetallicRoughness.

An additional "mode" field tends to come up for a variety of nodes
whenever there is a need to preserve backward compatibility. It is
convenient but does not feel very clean. Perhaps it is time to just
switch to "multiply" in general, breaking backward compatibility but
enhancing interoperability with other systems. That was probably
discussed previously.

x3dom also uses "channel" as an index to texture coordinate sets. Not
sure how other communities use the phrase. Currently, x3dom allows
allows for providing a second uv set only in BufferGeometry. Not sure
how MutliTexture applies since it only was intended for diffuse
color/albedo.

Anyways, please let me know if there is anything in particular you
would like input on in the current draft.

Regards,

-Andreas

> Date: Wed, 4 Mar 2020 21:31:24 +0100
> From: Michalis Kamburelis <michalis.kambi at gmail.com>
> To: GPU Group <gpugroup at gmail.com>
> Cc: X3D Graphics public mailing list <x3d-public at web3d.org>

> As for the completeness of PhysicalMaterial:
>
> - As far I know, the only remaining functionality missing from
> PhysicalMaterial, that is present in glTF 2.0 spec (
> https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#materials
> ) is the "occlusion" texture. I have it in my TODO list, I'll probably
> add it -- first I have to understand it fully :)
>
> - Note that, at least in this PR, I deliberately decided to *not*
> account for the KHR_materials_pbrSpecularGlossiness (
> https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Khronos/KHR_materials_pbrSpecularGlossiness
> ), which allows to
> specify physical material using a bit different parameters. I see that
> X3DOM accounts for that.
>
> - Some other stuff I decided to *not* include in this PR (because it
> seems it can be added later, and it's somewhat independent):
>
>     - alphaCutoff from glTF (this is something independent of the
> lighting model, so would be an extension for all material types; as
> far as I recall, X3DOM has "Appearance.alphaClipThreshold" to address
> this, and it seems cool for me)
>
>     - alphaMode from glTF (although I do have a solution for this in
> CGE, called "Appearance.alphaChannel", see
> https://castle-engine.io/x3d_implementation_shape_extensions.php#section_ext_alpha_channel
> )
>
>     - the fact that per-vertex colors in glTF multiply, while in X3D
> they replace the color. I think we'll add some day a field like "mode"
> = REPLACE | MULTIPLY to Color/ColorRGBA, where "REPLACE" would be
> default (compatible with X3D 3) and "MULTIPLY" would allow to achieve
> exactly glTF behavior.
>
> The channels stuff indeed requires rethinking. I recorded our
> discussions and my reasons for various decisions on
> https://github.com/michaliskambi/x3d-tests/wiki/How-to-add-PBR-to-X3D%3F
> . But I think I'll revisit the issue "how does xxxTextureChannel field
> work" again, and make it better :) -- I need to experiment a bit and
> see what feels right. I keep recording there my reasoning for various
> decisions.
>
> Regards,
> Michalis
>