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

Wed Aug 21 15:40:27 PDT 2019

Hi,

>From my use-case, I admit I see a lot of value in importing glTF files
as a whole. In particular, I see value in importing glTF animations
(as X3D animations). To list some practical gains:

- I want to take advantage of all the work Khronos is doing on their
Blender -> glTF exporter.

- I also want to eventually take advantage of the extra efficiency
offered by the glTF buffers system (for now, my implementation in
CGE/view3dscene just unpacks glTF buffers, but I want the possibility
to be maximally efficient in the future).

Currently view3dscene and Castle Game Engine can open glTF file with
an animation of the transformations (move, rotate, scale any number of
nodes), internally converting it into TimeSensor +
PositionInterpolator/OrientationInterpolator + Transform node. So in
the end, it is animated in exactly the same way that it would be
animated in X3D. And author can run it just by running one TimeSensor,
so it really behaves just as you expect in X3D.

It's not that complicated :) And once a browser does this conversion,
using such animation doesn't require any special knowledge from the
author. The animation is just controlled using X3D TimeSensor, it
works naturally in X3D.

Granted, other types of animations are not so easy:

- Animating morph targets can be converted into
CoordinateInterpolator. The description in X3D will be worse (longer)
because X3D doesn't have a concept of "named morph targets". In any
case, the animation can still be expressed in X3D, and is perfectly
usable.

- Animating using skin may require more changes. I remember Andreas
Plesch wad doing research about it, looking how/if it matches H-Anim
features. Here, if we have some obstacle in X3D (we cannot express in
X3D something that can be expressed in glTF) I would be very
interested in clearly identifying this obstacle, and possibly removing
it :)

Regards,
Michalis

śr., 21 sie 2019 o 22:48 Joseph D Williams <joedwil at earthlink.net> napisał(a):
>
>
>
> [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
>
>
>
> _______________________________________________
> x3d mailing list
> x3d at web3d.org
> http://web3d.org/mailman/listinfo/x3d_web3d.org