<div dir="ltr"><div dir="ltr"></div><div class="gmail_quote"><div class="gmail_attr">Hi,</div><div class="gmail_attr"><br></div><div class="gmail_attr">Answers inline :)<br></div><div class="gmail_attr"><br></div><div dir="ltr" class="gmail_attr">Andreas Plesch <<a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> For updating the X3D4 specification, some questions remain however:<br>
><br>
> a. Given your interpretation previously, does this break compliance of existing browsers?<br>
<br>
As far as I remember, Michalis touched on that. Most browsers should<br>
support "Phong". For those which support it, it should be<br>
straightforward to switch to "Phong" as default if they are<br>
maintained. Some may already have "Phong" as default and would then<br>
move automatically into closer compliance with X3DV4. Browsers which<br>
support "Phong" but cannot switch to it as a default due to resource<br>
constraints would fall out of X3DV4 compliance. Since X3DV4 also will<br>
require other, more expensive changes, to stay in compliance, resource<br>
constraints would have this consequence regardless. Browsers which do<br>
not support "Phong" would require action to stay in compliance: either<br>
start supporting it (a requirement anyways in 2020) or report<br>
"Gouraud" for the current BrowserProperties.Shading value which they<br>
probably do already.<br></blockquote><div><br></div><div>Note that X3D specification already explicitly says that supporting this is optional: <a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/networking.html#BrowserProperties">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD2/Part01/components/networking.html#BrowserProperties</a> : """"Support for browser options is not required but is strongly recommended. Some browsers may
not support all available options, due to limitations in the underlying rendering system.""""</div><div><br></div><div>CGE and view3dscene ignores BrowserProperties (as we're not HTML browser, and we have other ways to specify default shading).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
It would be probably helpful to have a simple test scene which renders<br>
obviously different with Gouraud and Phong shading but I cannot think<br>
of any. A cube with a close point light ?<br></blockquote><div><br></div><div>SpotLight shining on a quad would be one example.</div><div><br></div><div>( It should be an explicit quad done by QuadSet or IndexedFaceSet, not Box. Since X3D Box may be triangulated already. Castle Game Engine and view3dscene render each Box side, by default, as 3x3 quads, exactly to make it nicer under Gouraud shading. ) <br></div><div><br></div><div>Anything with normalTexture (using X3D 4) is another sample (with Gouraud shading, you will not see normalmap effect).<br></div><div><br></div><div>Another example is testing how texture is applied on a "Material with all parameters except emissive set to zero", from <a href="https://github.com/michaliskambi/x3d-tests/blob/master/pbr/unlit_material/unlit_tests.x3dv">https://github.com/michaliskambi/x3d-tests/blob/master/pbr/unlit_material/unlit_tests.x3dv</a> :<br></div><div><br></div><div>""""<br></div><div> appearance Appearance {<br> material Material {<br> emissiveColor 1 1 0<br> diffuseColor 0 0 0<br> specularColor 0 0 0<br> ambientIntensity 0<br> }<br> texture ImageTexture { url "../images/test_texture.png" }<br> }</div><div>"""</div><div><br></div><div>This should be pure yellow (in Phong shading), but will be a yellowish texture in Gouraud shading.</div><div><br></div><div>( It is also one reason why I invented separate UnlitMaterial, that can behave more naturally when switching between Phong/Gouraud shading. )<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> b. Do we add another value to the list of allowed enumerations, such as "PBR"? If so, what is accompanying prose.<br>
<br>
My understanding is that the answer is no. PBR is not an alternative<br>
to the existing Shading options. A PBR material can be Flat (face<br>
based), Gouraud (vertex based) or Phong (pixel based) shaded.<br></blockquote><div><br></div><div>Exactly. There is *no* such thing as "PBR shading". Or "unlit shading". These are lighting models, indicated by appropriate XxxMaterial nodes.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Looking at UnlitMaterial, there is a slight question with regards to<br>
the gltf KHR_Unlit_Material extension. UnlitMaterial uses the emissive<br>
color/texture while the gltf Unlit extension uses the base color of a<br>
PBR material. Base color is more similar to the diffuse color of<br>
Material. There would be better alignment with gltf if<br>
PhysicalMaterial had an "unlit" field. I feel there was probably a<br>
discussion why introducing an UnlitMaterial is preferable but at first<br>
glance it seems just adding the "unlit" field to PhysicalMaterial and<br>
in parallel relying on the current way to have unlit shading on<br>
regular Material would be less disruptive in a practical sense. What<br>
this means is also that supporting UnlitMaterial is probably not a<br>
priority for x3dom until there is demand. It is not that critical<br>
since it does not affect Inline support for gltf. Inline gltf already<br>
has unlit support in x3dom.<br></blockquote><div><br></div>I deliberately didn't want to make "unlit" a special case of "PhysicalMaterial" or Phong "Material".</div><div class="gmail_quote"><br></div><div class="gmail_quote">This would not allow natural specification -- unlit, by definition, doesn't need all the parameters that physical/Phong materials have. This allows to treat "unlit" as a natural 3rd lighting model in X3D, so you have:<br></div><div class="gmail_quote"><br></div><div class="gmail_quote"><div class="gmail_quote">1. Phong (Material)<br></div></div><div class="gmail_quote">2. PBR (PhysicalMaterial)</div><div class="gmail_quote">3. Unlit (UnlitMaterial)</div><div class="gmail_quote"><br></div><div class="gmail_quote">This scheme also allows to have a common ancestor X3DOneSidedMaterialNode , with emissiveColor/emissiveTexture. Since "emissive" makes sense for all lighting models.</div><div class="gmail_quote"><br></div><div class="gmail_quote">This means that</div><div class="gmail_quote"><br></div><div class="gmail_quote">- glTF PBR -> PhysicalMaterial (with glTF baseColor -> X3D PhysicalMaterial.baseColor).</div><div class="gmail_quote"><br></div><div class="gmail_quote">- glTF unlit -> UnlitMaterial (with glTF baseColor -> X3D UnlitMaterial.emissiveColor). This is known and deliberate, see my mention of UnlitMaterial on <a href="https://github.com/michaliskambi/x3d-tests/wiki/Converting-glTF-to-X3D">https://github.com/michaliskambi/x3d-tests/wiki/Converting-glTF-to-X3D</a> .</div><div class="gmail_quote"><br></div><div class="gmail_quote">General reasoning behind UnlitMaterial is on <a href="https://github.com/michaliskambi/x3d-tests/wiki/Why-is-UnlitMaterial-useful">https://github.com/michaliskambi/x3d-tests/wiki/Why-is-UnlitMaterial-useful</a> . I found it definitely a good addition when implementing, I would recommend X3DOM to support it too :) It even makes the code simpler, by <br></div><div class="gmail_quote"><br></div><div class="gmail_quote">- making "unlit" a clearly separate 3rd lighting model.</div><div class="gmail_quote"><br></div><div class="gmail_quote">- And you can internally handle cases with appearance = NULL or material = NULL through the same code path as "UnlitMaterial will all fields as default".<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Regards,</div><div class="gmail_quote">Michalis</div></div>