<div dir="ltr"><div dir="auto"><div>I agree with Michalis that 1:1 translation of the Blinn Phong shading model parameters we are used to PBR shading parameters is not possible. There are approximations which may be an option but would probably always be inferior to the original rendering, for carefully constructed materials. </div><div dir="auto"><br></div><div dir="auto">Furthermore, it is considered visually distracting to use both PBR and Phong shading in the same scene although certainly technically possible. I have not seen this and perhaps visual conventions would adjust readily. </div><div dir="auto"><br></div><div>glTF2 allows for point/directional lights, so there must be some consensus on how to apply these lights to PBR materials but this needs research into engines. Image Based Lighting (IBL) is the preferred method presumably because it provides a direct value for any incidence angle and can be importance sampled.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">glTF has an extension mechanism and a much discussed but never finalized extension are Phong materials, called materials common. </div><div dir="auto"><br></div><div dir="auto">I would consider webvr and custom shaders only loosely connected to PBR. It may be possible to develop a PBR component independently.</div><div dir="auto"><br></div><div>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.</div><div dir="auto"><br></div><div>-Andreas</div><div dir="auto"><div class="gmail_extra" dir="auto"><div class="gmail_quote"><blockquote class="m_5283884924297950811quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br>
Message: 2<br>
Date: Fri, 16 Mar 2018 17:37:37 +0100<br>
From: Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a>><br>
To: Don Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>><br>
Cc: X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>><br>
Subject: Re: [x3d-public] Physically Based Materials (PBR) in X3D<br>
Message-ID:<br>
        <CAKzBGZMuo_eh+aa_upF9M87RwuUF<wbr>TjLJbcpra=<a href="mailto:FHobzCOCHvMA@mail.gmail.com" target="_blank">FHobzCOCHvMA@mail.<wbr>gmail.com</a>><br>
Content-Type: text/plain; charset="UTF-8"<br>
<br>
  2018-03-16 17:01 GMT+01:00 Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a>>:<br>
> 2018-03-16 14:05 GMT+01:00 Don Brutzman <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>>:<br>
>> Regarding backwards compatibility.  It would be interesting to consider<br>
>> whether, instead of adding new nodes, we might go ahead and completely<br>
>> extend existing Material node and other lighting-related capabilities.  This<br>
>> has potential benefit of keeping the X3D v4 scene graph more closely<br>
>> consistent for X3D v3 and VRML97 content, allowing superior rendering of all<br>
>> content as the default rendering mode in X3D v4.  A backwards-compatibility<br>
>> rendering mode also might be possible for when authors explicitly want it...<br>
><br>
> To my knowledge, such upgrade path (to just take old X3D 3 content and<br>
> render it with PBR) is not possible, in the general case. Not without<br>
> significantly changing the look of X3D 3 content, in a way that is not<br>
> necessarily better (when the conversion from "Phong parameters->PBR<br>
> parameters" was done automatically).<br>
><br>
> The parameters for PBR (albedo, roughness) are really different than<br>
> non-PBR Phong (diffuse, specular). The material specification is<br>
> different, and the light specification is also different (lights in<br>
> PBR need an "environment map", like ImageCubeMapTexture, to make these<br>
> cool reflections you see on the screenshots from PBR renderers).<br>
><br>
> IOW, the materials require different preparations by the graphic<br>
> artist / content creator. The PBR workflow for graphic artists (and<br>
> how it differs from the workflow for Phong lighting model) is nicely<br>
> described on <a href="https://www.marmoset.co/posts/physically-based-rendering-and-you-can-too/" rel="noreferrer" target="_blank">https://www.marmoset.co/posts/<wbr>physically-based-rendering-and<wbr>-you-can-too/</a><br>
> . You cannot just toggle a boolean flag in the renderer to say "render<br>
> this with PBR".<br>
><br>
> Unity3d had the same choice, and they decided to *not* upgrade<br>
> materials in existing projects. They keep a large set of shaders doing<br>
> Phong lighting, and the existing materials use these Phong shaders.<br>
> The Phong shaders can be even still used in new projects. If someone<br>
> wants to convert his/her project to PBR, then (s)he must walk through<br>
> all the materials and lights, and upgrade them, setting suitable<br>
> parameter values, and creating new textures as necessary. The<br>
> resulting look with be unavoidably different anyway.<br>
><br>
> That's because, as far as the math is concerned, the PBR equations are<br>
> not a "more general form" of non-PBR equations. PBR equations impose<br>
> some limits that the non-PBR equations did not.<br>
><br>
<br>
Addendum to the above:<br>
<br>
There are actually two ways to express PBR parameters, the<br>
<br>
1. metallic-roughness<br>
2. specular-glossiness<br>
<br>
The 2nd version (specular-glossiness) has parameters that resemble the<br>
Phong model a bit more, and *may* be easier to automatically upgrade<br>
(so Phong lighting model -> PBR with specular-glossiness parameters).<br>
But it seems that it  only means "easier to upgrade for a graphic<br>
artist", and not "so easy to upgrade that it can be done<br>
automatically".<br>
<br>
See e.g.<br>
<br>
- <a href="https://jmonkeyengine.github.io/wiki/jme3/advanced/pbr_part1.html" rel="noreferrer" target="_blank">https://jmonkeyengine.github.i<wbr>o/wiki/jme3/advanced/pbr_part1<wbr>.html</a><br>
about the pros/cons of each model.<br>
- <a href="https://instantuv.org/wp-content/uploads/2017/03/pbr2016.pdf" rel="noreferrer" target="_blank">https://instantuv.org/wp-conte<wbr>nt/uploads/2017/03/pbr2016.pdf</a><br>
mentions both these approaches.<br>
- <a href="https://docs.unity3d.com/Manual/StandardShaderMaterialCharts.html" rel="noreferrer" target="_blank">https://docs.unity3d.com/Manua<wbr>l/StandardShaderMaterialCharts<wbr>.html</a><br>
shows both workflows in Unity PBR (standard) material.<br>
<br>
However, it seems to me that X3D should adopt the "metallic-roughness"<br>
model of PBR. Reasons:<br>
<br>
- This is what glTF did. That's the most important reason. glTF only<br>
uses the metallic-roughness version. So if we want easy and perfect<br>
interoperability with glTF 2.0 (and I think we should), then we need<br>
to also adopt the metallic-roughness version, or (like e.g. Unity3d)<br>
allow to choose between metallic-roughness and specular-glossiness .<br>
<br>
- Allowing both PBR models (metallic-roughness and<br>
specular-glossiness) means more complication in the spec. If the glTF<br>
decided that only metallic-roughness is enough, then it's likely also<br>
true for X3D.<br>
<br>
- Even though Unity allows to choose between these two approaches,<br>
they still do not convert non-PBR materials to PBR with<br>
specular-glossiness. This suggests that the automatic conversion is<br>
not possible, at least not in a way that would be acceptable to *all*<br>
the models in the wild.<br>
<br>
Regards,<br>
Michalis<br></blockquote></div></div></div></div>
</div>