[x3d-public] Physically Based Materials (PBR) in X3D

[Michalis Kamburelis]

 2018-03-17 19:45 GMT+01:00 Andreas Plesch <andreasplesch at gmail.com>:
> There is semantic overlap between the physical material node by Sturm et al.
> which has all the fancy maps as fields and the proposed commonsurfaceshader
> node. Perhaps there is an opportunity to unify. I think that means adding
> the commonsurfaceshader node fields as fields to material, or reversely have
> a new PBR surfaceshader node with the textures and only the factors (colors)
> in the pbrmaterial node. Another option may be to add all these maps for
> both shading models as fields to Appearance, parallel to the existing
> texture field. New nodes for new functionality may provide overall a better
> extension mechanism.

(This is a long answer where I discuss some details. But, in summary:
yes, it looks like we both think in the same direction. :) )

1. Indeed, both CommonSurfaceShader and PhysicalMaterial propose a
nice convention: everything may have a factor (scalar,vector) and/or a
texture. E.g. diffuseFactor / diffuseTexture, specularFactor /
specularTexture in CommonSurfaceShader (
https://castle-engine.io/x3d_implementation_texturing_extensions.php#section_ext_common_surface_shader).
PhysicalMaterial follows this convention, but for different
parameters: e.g. albedoFactor / albedoMap, roughnessFactor /
roughnessMap ( https://instantuv.org/wp-content/uploads/2017/03/pbr2016.pdf
).

    Two warnings about small inconsistencies here (between
CommonSurfaceShader and PhysicalMaterial):

    1.1. CommonSurfaceShader dictates that that xxxFactor is always
multiplied by the value from xxxTexture. So if you provide
CommonSurfaceShader.diffuseFactor (which has the same meaning as
traditional Material.diffuseColor) then it is multiplied by
CommonSurfaceShader.diffuseTexture. This is very useful in my
experience, and standard for Phong lighting.

      In contrast, PhysicalMaterial says that if a texture is present,
like albedoMap, then it *replaces* the value of albedoFactor. I do not
have enough experience to judge is this decision good (and I did not
check what glTF says about this, and what standard Unity3d materials
do). Maybe PhysicalMaterial should also say that xxxFactor is
multiplied with xxxMap, and be consistent? But maybe it's undesired.

      This is something that should be researched, and either made
consistent in the final spec ("texture always multiplies the factor,
PBR or not PBR"), or clearly document ("in Phong, texture multiplies,
but in PBR, texture replaces, because...").

    1.2. Another, trivial inconsistency is that PhysicalMaterial calls
textures xxxMap, but CommonSurfaceShader calls textures xxxTexture.
This should of course be made consistent, e.g. always use xxxTexture,
so "albedoTexture" instead of "albedoMap".

2. There is a subset of CommonSurfaceShader that is independent from
the lighting model, and is useful in both Phong and PBR. This is

   - All the normalmap stuff in CommonSurfaceShader. All the fields
like normalTexture, normalTextureCoordinatesId . Normalmaps have the
same use for both Phong and PBR lighting models.

   - The displacement stuff in CommonSurfaceShader. Displacement
effect, at least in theory, is unrelated to the lighting model.
Although I'm not sure do we want to include displacement stuff in the
X3D spec -- it seems only X3DOM implements it. I'm leaning towards not
including it in the spec.

So I'm leaning toward a solutions like this (I think this is
consistent with what you're thinking about) :

1. Extract normalmaps information from CommonSurfaceShader to some new
field/node inside Appearance, that is independent from the lighting
model. Maybe a new node like NormalMap that is placed in a field
"Appearance.normalMap".

    (Note that CGE already has a deprecated "Appearance.normalMap"
field. But it is deprecated, as it is too simple --- you place there
directly an ImageTexture, and you cannot specify e.g.
normalTextureCoordinatesId. See
https://castle-engine.io/x3d_implementation_texturing_extensions.php#section_ext_bump_mapping
.).

2. The remaining CommonSurfaceShader can be summed up with current
Material. E.g. add diffuseTexture , specularTexture, emissiveTexture
to Material. And keep Material to mean "Phong lighting model".

3. And the PhysicalMaterial, with it's current parameters, is an
alternative material. So the Appearance.material either points to
Material or PhysicalMaterial.

4. What to do with the existing Appearance.texture field? For backward
compatibility we should probably keep it (it's widely used). And
specify that "Appearance.texture" is only an alternative way of
providing "Material.diffuseTexture" or
"PhysicalMaterial.albedoTexture" .

> So to me the main missing piece may be lighting: How to use existing X3D
> lights with PBR. How to use and spec. IBL for Blinn-Phong X3D materials, I
> think, is already covered by the cubemaps spec.

The X3D cubemap component (
http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/env_texture.html
, https://castle-engine.io/x3d_implementation_cubemaptexturing.php )
does *not* describe how to use cubemaps for lighting. It "only"
defines a new X3DTextureNode descendant, that can be used anywhere
where the spec mentions X3DTextureNode, like "Appearance.texture" or
"MultiTexture.texture".

X3D cubemap specification does not enhance X3D lights with
capabilities to use images as light parameters specification.

Regards,
Michalis