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

[Andreas Plesch]

Hi Michalis, Don,

On Sun, Aug 16, 2020 at 5:24 PM Michalis Kamburelis
<michalis.kambi at gmail.com> wrote:
>
> 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.""""

So support for BrowserOptions should not factor in for determining
compliance but one can think of another label such as a browser having
"a recommended level of support". Not sure why Don asked about
compliance though.

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

x3dom has an equivalent ("runtime") but does not have shading options
(always phong). x-ite probably has full support.

>>
>> 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. )

Good point. The expectation would be that a yellow quad lighted by a
spotlight which is so close that the corner are outside the cutOff
angle and therefore dark/black would render

with Gouraud shading: dark/black in the center
with Phong shading: bright yellow in the center

That would be a good test.

>
> 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".

Yes, of course. Let's see why.

>
> 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 is cleaner but at the cost of adding a complete node rather than
just a SFBool field, and deviating from gltf. So I am not sure if it
is a win overall.

> 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".

Overall, it may make code simpler in a theoretical sense but
unfortunately this change requires first a lot of restructuring for
any code base which will put it out of reach for some time. This is
why I had doubts about the practical value rather than the logical
value.

For x3dom, what may be feasible is to internally replace the
UnlitMaterial node with an unlit PhysicalMaterial node. But first the
changes to PhysicalMaterial will have to be implemented.

-Andreas