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

Leonard Daly Leonard.Daly at realism.com
Thu Mar 22 10:36:40 PDT 2018


I have a simple example of roughness and metalness. In the attached 
image the shapes range from completely smooth (top) to completely rough 
(bottom) and non-metal (left) to complete metal (right). The white dots 
on the objects in top row is from the scene lights. This image was made 
with an environment of uniform medium gray. The calculation are done by 
THREE.js.

There is also an interactive version at 
http://xseen.org/XSeen/tests/pbr-envMap.html where you can change the 
environment map. There is also a map for metal/roughness that has not 
yet been implemented. This display was built using XSeen 
(http://XSeen.org/).

Leonard Daly



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

-- 
*Leonard Daly*
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Past Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20180322/488f44a9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PBR-test.jpg
Type: image/jpeg
Size: 62782 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20180322/488f44a9/attachment-0001.jpg>


More information about the x3d-public mailing list