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

Sat Mar 17 17:39:15 PDT 2018

I only read your nice GitHub wiki summary now, and saw that you had
similar ideas with regards to css.

Let me continue below but in summary I would only differ in keeping
the option to have PBR in X3D v4, especially if glTF inlining is being
considered as well.

On Sat, Mar 17, 2018 at 4:15 PM, Michalis Kamburelis
<michalis.kambi at gmail.com> wrote:
>  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
> ).

>From what I have seen is that PhysicalMaterial now would follow glTF
closely which leads to these fields:

baseColorFactor/Texture (was albedo)
metallicFactor
roughnessFactor
metallicRoughnessTexture (combined)
emissiveFactor
occlusionTexture
normalTexture
not in glTF:
normalSpace
normalBias

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

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#metallic-roughness-material

actually mentions that factor is a multiplier if texture is present.

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

Agreed and glTF uses Texture.

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

There may be also normalBias and normalSpace (tangent or object) to consider.

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

Agreed. It may even be worth thinking about being able to have both,
as a fallback which then may require a 'preferred' indicator field.

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

Yes, texture needs to stay but the material textures probably should
take precedence if available.

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

ok, then Image Based Lighting would need to be spec.ed as well, probably using

34.3.1 X3DEnvironmentTextureNode

as a field and a factor as well ? With scoping like the other x3d lights ?

The existing light equations may need to mention how light direction,
color and strength are derived from an env. light ?
Perhaps only allow IBL lights for PBRmaterials ?
Or make the lighting a pbrmaterial field ?

-Andreas

-- 
Andreas Plesch
Waltham, MA 02453