<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">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.<br>
<br>
There is also an interactive version at
<a class="moz-txt-link-freetext" href="http://xseen.org/XSeen/tests/pbr-envMap.html">http://xseen.org/XSeen/tests/pbr-envMap.html</a> 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
(<a class="moz-txt-link-freetext" href="http://XSeen.org/">http://XSeen.org/</a>).<br>
<br>
Leonard Daly<br>
<br>
<br>
<br>
</div>
<blockquote type="cite"
cite="mid:CAKdk67sk1EViraasxvMsab53JojuhGwJ2vBFXH1bcasWBYBE+Q@mail.gmail.com">
<pre wrap="">It is great to be able to share.
On Sat, Mar 17, 2018 at 10:32 PM, Michalis Kamburelis
<a class="moz-txt-link-rfc2396E" href="mailto:michalis.kambi@gmail.com"><michalis.kambi@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Thank you for all the insights!
2018-03-18 1:39 GMT+01:00 Andreas Plesch <a class="moz-txt-link-rfc2396E" href="mailto:andreasplesch@gmail.com"><andreasplesch@gmail.com></a>:
</pre>
<blockquote type="cite">
<pre wrap="">normalSpace
normalBias
</pre>
</blockquote>
<pre wrap="">
I am not 100% sure do we need normalSpace, normalBias (and some other
fields like normalFormat, normalScale from CommonSurfaceShader).
</pre>
</blockquote>
<pre wrap="">
I only mentioned it because there was just a proposal to add
normalSpace to glTF:
<a class="moz-txt-link-freetext" href="https://github.com/KhronosGroup/glTF/issues/1284">https://github.com/KhronosGroup/glTF/issues/1284</a>
</pre>
<blockquote type="cite">
<pre wrap="">
>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 .
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">3. And the PhysicalMaterial, with it's current parameters, is an
alternative material. So the Appearance.material either points to
Material or PhysicalMaterial.
</pre>
</blockquote>
<pre wrap="">
Agreed. It may even be worth thinking about being able to have both,
as a fallback which then may require a 'preferred' indicator field.
</pre>
</blockquote>
<pre wrap="">
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?
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">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").
</pre>
</blockquote>
<pre wrap="">
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
</pre>
</blockquote>
<p><br>
</p>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
3D Systems & Cloud Consultant<br>
LA ACM SIGGRAPH Past Chair<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>