[x3d-public] 21 JAN 2020: X3Dv4 PBR review

[Don Brutzman]

Attendees: Michalis Kamburelis, Dick Puk, Don Brutzman

1. We reviewed super progress by Michalis, shown in

a. Github X3Dv4 Pull Request 8 (PR8)
* https://github.com/Web3DConsortium/X3D/pull/8

   In particular, work under consideration for the updated PR
   "12.2.4 Choosing texture channels in material nodes"
   much improved
   ..../X3D/ISO-IEC19775/ISO-IEC19775-1/ISO-IEC19775-1v4.0/ISO-IEC19775-1v4-WD1/Part01/components/shape.html

b.  Looking at glTF sample implementation, description on how it does lighting:

* https://github.com/michaliskambi/x3d-tests/wiki/Gamma-correction-in-X3D-and-glTF#gltf-sample-implementation-closer-look

* https://github.com/KhronosGroup/glTF-Sample-Viewer/blob/master/src/shaders/metallic-roughness.frag

   Search there for
   - applyDirectionalLight,
   - applyPointLight,
   - applySpotLight
   - getIBLContribution

This provides a precise implementation of how PhysicalMaterial will interact with X3D DirectionalLight, PointLight, SpotLight and (new, also in my PR) EnvironmentLight (aka ImageBasedLight)

c. Plans:
- Implement in Castle Game Engine (CGE) Material with texture slots,
- PhysicalMaterial,
- improve glTF -> X3D conversion to convert glTF material -> X3D PhysicalMaterial.

---

2. Note about Unity:

There are 2 popular ways to express PBR equations and parameters.
a. metallic-roughness
b. specular-glossiness

- The default PBR material in Unity follows the "specular-glossiness".

- glTF follows the "metallic-roughness".

- There's an extension to allow "specular-glossiness" in glTF: https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Khronos/KHR_materials_pbrSpecularGlossiness

- X3D PhysicalMaterial will match glTF, thus follow "metallic-roughness".

---

3. *Predictable display.* Of note is that glTF PBR continues to have a variety of recommendations and extensions, not strict conformance. It certainly appears that Khronos has "agreed to disagree" in a very professional way, allowing different engines to slightly vary.  In some cases, some companies have more than one lighting engine in this regard.  Experimentation is common.

X3Dv4 does not want to "choose sides" but rather wants to achieve:
a. Closest possible match to glTF equations holding common agreement,
b. Choice of specific parameter values in our spec,
c. Possibility of allowing Metadata nodes for authors to include alternate parameters,

So we are striving for a close match... indeed, given the evolution in glTF PBR that continues to unfold, the most important thing for X3Dv4 is to get the node structure correct.

We expect that several experts in the glTF community will be willing to review our forthcoming new lighting and rendering features in X3Dv4 to see how closely they align to their implementations.

---

4. *Conversions* from the published glTF example assets to X3Dv4 models will be the most effective way to demonstrate proper and complete correspondences.  Any differences will be noted so that we can either minimize or clarify them.

Michalis noted that his recently announced view3dscene conversion tool is already converting glTF assets into X3D models!  8)

	Convert to X3D (from glTF, OBJ, STL, Collada, …) and
	change X3D encodings using online Castle Game Engine converter
	https://twitter.com/castleengine/status/1215751985523232771

exposed online directly at
	
	https://castle-engine.io/wp/2020/01/10/convert-to-x3d-from-gltf-obj-stl-collada-and-change-x3d-encodings-using-online-castle-game-engine-converter/

	https://castle-engine.io/convert.php

We will soon create a set of conversion examples in X3D using his tool as baseline, checking these into the X3D Example Archives.

	glTF-Sample-Models
	https://github.com/KhronosGroup/glTF-Sample-Models
---

5. There are several interesting threads on mailing list (and lurking in Mantis issues) that will closely relate to this work.  It will be great to correlate them all as the draft specification comes out.

a. Gamma correction is interesting... but historically this has been problematic for us, since operating systems have their own (often diverse) implementations corresponding to different display hardware.

Primary discussion is on the x3d-public mail thread.  Michalis showed us the /pow(result, 1/2.2)/ sRGB computations.  Further commentary at
* https://github.com/michaliskambi/x3d-tests/wiki/Gamma-correction-in-X3D-and-glTF

We agreed to proceed as far as possible to align with glTF, consider whether operating-system and hardware variations remain, and then decide on default approach for X3D.

b. Other topics: points and lines, bounding box display, etc.

6. We agreed to meet again next week (and will look further at TwoSidedMaterial).  Thanks for all review comments.

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman