[x3d-public] Spec 9.2.4 Browser options: add PBR shading? X3D3 Inline use cases for X3D4

[Michalis Kamburelis]

Hi,

Answers inline :)

Andreas Plesch <andreasplesch at gmail.com> wrote:

> > For updating the X3D4 specification, some questions remain however:
> >
> > a. Given your interpretation previously, does this break compliance of
> existing browsers?
>
> As far as I remember, Michalis touched on that. Most browsers should
> support "Phong". For those which support it, it should be
> straightforward to switch to "Phong" as default if they are
> maintained. Some may already have "Phong" as default and would then
> move automatically into closer compliance with X3DV4. Browsers which
> support "Phong" but cannot switch to it as a default due to resource
> constraints would fall out of X3DV4 compliance. Since X3DV4 also will
> require other, more expensive changes, to stay in compliance, resource
> constraints would have this consequence regardless. Browsers which do
> not support "Phong" would require action to stay in compliance: either
> start supporting it (a requirement anyways in 2020) or report
> "Gouraud" for the current BrowserProperties.Shading value which they
> probably do already.
>

Note that X3D specification already explicitly says that supporting this is
optional:
https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/networking.html#BrowserProperties
: """"Support for browser options is not required but is strongly
recommended. Some browsers may not support all available options, due to
limitations in the underlying rendering system.""""

CGE and view3dscene ignores BrowserProperties (as we're not HTML browser,
and we have other ways to specify default shading).


> It would be probably helpful to have a simple test scene which renders
> obviously different with Gouraud and Phong shading but I cannot think
> of any. A cube with a close point light ?
>

SpotLight shining on a quad would be one example.

( It should be an explicit quad done by QuadSet or IndexedFaceSet, not Box.
Since X3D Box may be triangulated already. Castle Game Engine and
view3dscene render each Box side, by default, as 3x3 quads, exactly to make
it nicer under Gouraud shading. )

Anything with normalTexture (using X3D 4) is another sample (with Gouraud
shading, you will not see normalmap effect).

Another example is testing how texture is applied on a "Material with all
parameters except emissive set to zero", from
https://github.com/michaliskambi/x3d-tests/blob/master/pbr/unlit_material/unlit_tests.x3dv
:

""""
    appearance Appearance {
      material Material {
        emissiveColor 1 1 0
        diffuseColor 0 0 0
        specularColor 0 0 0
        ambientIntensity 0
      }
      texture ImageTexture { url "../images/test_texture.png" }
    }
"""

This should be pure yellow (in Phong shading), but will be a yellowish
texture in Gouraud shading.

( It is also one reason why I invented separate UnlitMaterial, that can
behave more naturally when switching between Phong/Gouraud shading. )


>
> > b. Do we add another value to the list of allowed enumerations, such as
> "PBR"?  If so, what is accompanying prose.
>
> My understanding is that the answer is no. PBR is not an alternative
> to the existing Shading options. A PBR material can be Flat (face
> based), Gouraud (vertex based) or Phong (pixel based) shaded.
>

Exactly. There is *no* such thing as "PBR shading". Or "unlit shading".
These are lighting models, indicated by appropriate XxxMaterial nodes.


> Looking at UnlitMaterial, there is a slight question with regards to
> the gltf KHR_Unlit_Material extension. UnlitMaterial uses the emissive
> color/texture while the gltf Unlit extension uses the base color of a
> PBR material. Base color is more similar to the diffuse color of
> Material. There would be better alignment with gltf if
> PhysicalMaterial had an "unlit" field. I feel there was probably a
> discussion why introducing an UnlitMaterial is preferable but at first
> glance it seems just adding the "unlit" field to PhysicalMaterial and
> in parallel relying on the current way to have unlit shading on
> regular Material would be less disruptive in a practical sense. What
> this means is also that supporting UnlitMaterial is probably not a
> priority for x3dom until there is demand. It is not that critical
> since it does not affect Inline support for gltf. Inline gltf already
> has unlit support in x3dom.
>

I deliberately didn't want to make "unlit" a special case of
"PhysicalMaterial" or Phong "Material".

This would not allow natural specification -- unlit, by definition, doesn't
need all the parameters that physical/Phong materials have. This allows to
treat "unlit" as a natural 3rd lighting model in X3D, so you have:

1. Phong (Material)
2. PBR (PhysicalMaterial)
3. Unlit (UnlitMaterial)

This scheme also allows to have a common ancestor X3DOneSidedMaterialNode ,
with emissiveColor/emissiveTexture. Since "emissive" makes sense for all
lighting models.

This means that

- glTF PBR -> PhysicalMaterial (with glTF baseColor -> X3D
PhysicalMaterial.baseColor).

- glTF unlit -> UnlitMaterial (with glTF baseColor -> X3D
UnlitMaterial.emissiveColor). This is known and deliberate, see my mention
of UnlitMaterial on
https://github.com/michaliskambi/x3d-tests/wiki/Converting-glTF-to-X3D .

General reasoning behind UnlitMaterial is on
https://github.com/michaliskambi/x3d-tests/wiki/Why-is-UnlitMaterial-useful
. I found it definitely a good addition when implementing, I would
recommend X3DOM to support it too :) It even makes the code simpler, by

- making "unlit" a clearly separate 3rd lighting model.

- And you can internally handle cases with appearance = NULL or material =
NULL through the same code path as "UnlitMaterial will all fields as
default".

Regards,
Michalis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200816/237a8c5c/attachment.html>