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

[Andreas Plesch]

It is great to be able to share.

On Sat, Mar 17, 2018 at 10:32 PM, Michalis Kamburelis
<michalis.kambi at gmail.com> wrote:
> Thank you for all the insights!
>
> 2018-03-18 1:39 GMT+01:00 Andreas Plesch <andreasplesch at gmail.com>:
>> normalSpace
>> normalBias
>
> I am not 100% sure do we need normalSpace, normalBias (and some other
> fields like normalFormat, normalScale from CommonSurfaceShader).

I only mentioned it because there was just a proposal to add
normalSpace to glTF:
https://github.com/KhronosGroup/glTF/issues/1284

>
> From what I saw, it's standard to specify normalmaps in tangent space.
> And encode them with scale=(2,2,2) and bias=(-1,-1,-1), that is to
> trivially pack a 3D direction (3 floats in [-1..1]) into RGB color (3
> floats in [0..1]).
>
> I would probably make the above settings just "forced" in X3D
> standard, just like glTF does.
>
> (Note: glTF has "normalTextureInfo.scale", but that's only in XY, it
> is something different than CommonSurfaceShader.normalScale.)
>
> The important fields we need are normalTexture and normalTextureCoordinatesId .
>
> BTW: Actually, all xxxTexture fields require also
> xxxTextureCoordinatesId in X3D, to be able to associate them with
> texture coordinates in geometry "texCoord" field. That's also what
> CommonSurfaceShader is doing. In glTF, the texture coordinates are
> specified in normalTextureInfo, but it seems we don't need it. I
> prefer CommonSurfaceShader approach -- xxxFactor, xxxTexture,
> xxxTextureCoordinatesId .
>
>>> 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.
>>
>
> I'm not sure do we need a mechanism to specify both PBR and non-PBR on
> a single shape. Would graphic artists be interested in providing
> parameters (including textures) for both versions?

Not sure, it seems like it could be a useful but rarely used option.
There was a discussion on glTF to have a mobile optimized material
which could be even unlit, and a full material.

> In any case, instead of "preferred" field, we could change
> "Apperance.material" to be MFNode and just indicate that the first one
> is preferred. Just like "Apperance.shaders" works. This "preference"
> mechanism was also one reason why "CommonSurfaceShader" was created as
> a shader (and is placed on "Apperance.shaders").

Agreed although I am never quite sure if it is ok rely on the order of
MFNode fields, in all encodings. I guess it is.

Best, Andreas


-- 
Andreas Plesch
Waltham, MA 02453