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

Thu Aug 22 09:37:51 PDT 2019

➢ not seeing great value in the import of these files 

Ok, in these cases, for things that are used like a protoinstance where the file is included and defined like an external or included prototype. Whatever the single gltf file (or collection of gltf files) that the author wishes to include in the x3d scene, it must be a child context, like proto and inlines with interfaces specified . 
Otherwise, to include just a part of gltf file as data, then the file contents may be referenced by the name of the content field in the gltf file included in the field  of the x3d node. 
Thanks, 
Joe

From: Joseph D Williams
Sent: Wednesday, August 21, 2019 1:48 PM
To: Brutzman, Donald (Don) (CIV); X3D Graphics public mailing list
Cc: X3D Graphics Working Group
Subject: Re: [x3d-public] X3D Working Group minutes 21 AUG 2019: glTFX3Dspecification Plan Of Action Milestones (POAM)

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

after looking at these I’m not seeing great value in the import of these files in their entirty.
Mainly I have seen opportunies to use part(s) of some gltf to carry some data into an x3e scene, but haven’t seen much of anything I liked about importing a ‘complete’ gltf. 
Even simple animations shown are not easily understandable in terms of x3d. The stuff just looks to be way too optimized for the gpu runtime form to be easily readable and immediately transportable to x3d. 

Of course the examples given are just simple ones but importing a complete file and dealing with the conversion in the browser is not going to help the author that much because the author needs to learn as much or more about the gltf contents as if just understanding x3d. And then still must select the gltf data that can be usefully extracted and put into the x3d form. 

So, the gltf examples I have seen now appear to me to have only slightly more utility for x3d than collada; which is a lot, but not really directly usable directly as an imported asset without lots of work and understanding up front. 

Thanks, 
Joe

From: Brutzman, Donald (Don) (CIV)
Sent: Wednesday, August 21, 2019 10:30 AM
To: X3D Graphics public mailing list
Cc: X3D Graphics Working Group
Subject: [x3d-public] X3D Working Group minutes 21 AUG 2019: glTF X3Dspecification Plan Of Action Milestones (POAM)

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 HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20190822/d830a228/attachment-0001.html>