[x3d-public] X3D Working Group minutes 21 AUG 2019: glTF X3D specification Plan Of Action Milestones (POAM)

Brutzman, Donald (Don) (CIV) brutzman at nps.edu
Wed Aug 21 10:29:37 PDT 2019


Attendees: Michalis Kamburelis, Nicholas Polys, Dick Puk, Don Brutzman.

Thanks Michalis for follow-up meeting.

====================================================

References:

[1] Khronos glTF Overview
     https://www.khronos.org/gltf

[2] glTF - Wikipedia
     https://en.wikipedia.org/wiki/GlTF

[3] glTF Sample Models - GitHub
     https://github.com/KhronosGroup/glTF-Sample-Models

[4] glTF 3D (@glTF3D) | Twitter
     https://twitter.com/gltf3d

----- Michalis Kamburelis references: -----

[5] Initial (very draft) proposal of my changes to X3D spec, to add PBR and related features, including "waves":
     https://github.com/michaliskambi/x3d-tests/wiki/Specification-changes,-to-include-PBR-and-related-features

[6] More broad overview of PBR:
     https://github.com/michaliskambi/x3d-tests/wiki/Include-PBR-%28PhysicalMaterial-and-related-concepts%29-in-the-official-X3D-specification

[7] Making RGB and grayscale treatment consistent in X3D, I think this has high priority for X3D 4.0 too:
     https://github.com/michaliskambi/x3d-tests/wiki/Make-RGB-and-grayscale-textures-treatment-consistent

[8] Thoughts about retaining "Programmable Shaders" component in X3D - in short: let's not deprecate this :)
     https://github.com/michaliskambi/x3d-tests/wiki/Do-not-deprecate-%22Programmable-Shaders%22-component

[9] Additional comments "why gltf and x3d" attached

----------------------------------------

[10] Draft X3D Specification, 23 JUL 2019
      http://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD1/Part01/Architecture.html

  a.  9 Networking component
      http://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD1/Part01/components/networking.html

  b.  12  Shape component
      http://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD1/Part01/components/shape.html

  c.  17  Lighting component
      http://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD1/Part01/components/lighting.html

  d.  18  Texturing component
      http://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD1/Part01/components/texturing.html

  e.  31  Programmable shaders component
      http://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD1/Part01/components/shaders.html

  f.  34  Cube map environmental texturing component
      http://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD1/Part01/components/env_texture.html

  g.  43 Projective texture mapping (PTM) component
      http://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-WD1/Part01/components/ProjectiveTextureMapping.html

----------------------------------------

[11] Mantis issues

TODO these are needed!

[12] X3D Working Group: glTF X3D Features Comparison (3 NOV 2017)
      https://www.web3d.org/sites/default/files/page/X3D%20Version%204%20Strategy/glTfX3dFeaturesComparison.pdf

[13] TODO list additional papers (e.g. Timo Sturm in Web3D Conferences)

====================================================

2. *Motivation*

There are numerous reasons why inclusion of glTF capabilities in X3D is desirable.  Ref [9] is a good summary, more information can be found in prior X3D minutes.

[12] was the product of 3-6 weeks review last fall comparing glTF 2.0 and X3D features back in 2017.

Action items: the spreadsheet is pretty thorough but should be reviewed and refreshed.
a. glTF 2.0 remains current approved version.  This is what we are aligning with.
b. Khronos/Web3D colleagues have said they will flag any items that might be subject to change.
c. "glTF Custom Shader" now has an extension available.
d. Need to update rows for bump, occlusion, emission normal maps.
e. We should add a separate column for X3Dv4.

Volunteer to work on next draft: *TBD* expert on glTF provide changes, Don can update spreadsheet.

====================================================

3. *Approach Summary*

a. We want new glTF capabilities (especially Physically Based Rendering PBR) available to authors through loading,
b. We thus need an updated lighting model,
c. We do not want to change default lighting in X3Dv3 scenes, maintaining backwards compatibility,
d. We want shapes rendered by old and new lighting models to be available for simultaneous display.
e. We need to be careful and clear about specifying light applicability so that model authors are in full control.

Thus a separate/augmented lighting model is needed.  It must accompany the glTF model, or can be specified as approach for new content.

Loading of glTF model within a parent X3D model affects
[10] a. 9 Networking

TBD: whether this occurs via Inline, ExternalShape, and/or ExternalGeometry (using only mesh geometry of a model).

Lighting model affects
[10] b. 12  Shape component,
[10] c. 17 Lighting component,
[10] d. 18 Texturing component

At this stage we do not expect major changes in
[10] e. 31 Programmable shaders component
[10] f. 34 Cube map environmental texturing component

We expect some changes in
[10] g. 43 Projective texture mapping (PTM) component

Some clarifications might well be necessary, particularly PTM.  Where possible, try to refine these advanced texturing components so that they might depend on Texturing component where possible, striving to ensure that no duplication or conceptual contradictions/collisions occur. If they can't be decoupled, then the specific differences certainly need to be addressed.

We do not need a "Physically Based Rendering (PBR) component" per se, the specification changes occur in the other components.

Once all components are ready, we need to perform an extra pass to ensure that Support Levels are correct and consistently defined.

====================================================

4. *Issues of special interest*

a.  We learned at SIGGRAPH 2019 that glTF has three different modes for rendering, each using a variety of parameters, and that various glTF applications often use different choices for defaults.  This was offered as reason why some models (e.g. pod-racer helmet) can look very different.  Thus we must carefully preserve ability for X3D to match glTF parameters.

TODO identify glTF section(s) of interest.

b.  Also learned that current glTF PBR is good at things like wood and metals, but not translucent skin, because there are no subsurface scattering parameters.  Something that may be addressed in future glTF.

c. Timo Sturm Fraunhofer has done a lot of implementation in this area.

d. Expect X3Dv4 implementations from X3DOM, X_ITE and Castle Game Engine.  Others?

e. Issues will get tracked via mail list, meeting minutes and Mantis (i.e. in the usual manner).

Currently there are no major blocking issues identified.  Michalis thinks we are ready to proceed fully on next steps.

Similarly there are no ISO or specification-alignment issues that we need to bring to bring to annual ISO SC 24 meeting.

Onward we go...

====================================================

5. *Specification work*

What spec sections should we work on next?

[5] proposed set of changes, in "waves" for progressive refinement, is relevant both for specification editing and for implementers.

"Divide and conquer" in this manner might also help us with specification, following that approximate order.

Editing alternatives:

a. We create specification sections and placeholders so that the specification edits can accumulate without problem (i.e. single branch).
b. Michalis will create a separate git branch on the github specification that collects all of these interrelated changes.

We will follow path "b" above.  Michalis is in charge of work in this branch.

Don't want to guess or insert prematurely.  If possible when ready to advise on likely sections, we could put placeholders in primary branch might be helpful in primary spec.  Or not!  No "decision" needed at this point, avoiding is OK - only Don thinks it might help.  8)

Our goal is to have complete draft ready for scrutiny before DEC 2019.  Sounds doable.

====================================================

Thank you Michalis for continuing major efforts that benefit everyone.  Also thanks to Timo, Johannes, Andreas, Holger and others who have been crucial for reaching this stage of progress.

Have fun with X3D!  8)

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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: why-gltf-and-x3d.txt
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190821/d0f9cf12/attachment-0001.txt>


More information about the x3d-public mailing list