[x3d-public] [x3d] X3D Working Group minutes 16 AUG 2019: PointProperties/PointSet, IIIF 3D, glTF, ISO preps

Fri Aug 16 11:08:07 PDT 2019

Some time ago I also wrote personal "comparison X3D vs glTF". It
contains some biased (from my point of view, i.e. developer of game
engine) notes. Attaching it as txt file, in case you find it useful.

My personal conclusion from the thoughts in this document was

"""I want to support glTF format in Castle Game Engine as first-class
citizen (all features, full support), because it's a great 3D model
format with bright future. But I also want to keep using X3D nodes to
express 100% of  the scene graph in CGE, because X3D defines really
good (well-thought and documented, in most cases) and rich (in
features) scene graph. And where X3D scene graph is lacking some
feature, I can easily fix it.
"""

I am working towards this goal since ~year within CGE :) Some results
include glTF support in CGE and view3dscene (not full yet, but
in-progress). And all my thoughts about PBR :)

Regards,
Michalis

Brutzman, Donald (Don) (CIV) <brutzman at nps.edu> wrote:

>
> Attendees: Anita Havele, Vince Marchetti, Nicholas Polys, Dick Puk, Don Brutzman.
> Last-minute regrets/reschedule: Michalis Kamburelis.
>
> Last week's minutes:
>
>         [x3d-public] X3D meeting minutes 9 AUG 2019
>         http://web3d.org/pipermail/x3d-public_web3d.org/2019-August/011188.html
>
> ====================================================
>
> 1. *Topics*
>
> We are looking to discuss the following items today:
>
> - PointProperties signature, Mantis 1252
>    http://www.web3d.org/member-only/mantis/view.php?id=1252
>
> - PointSet containing Normal node
>
> - Upcoming ISO Standards Committee (SC) 24 meeting in Takamatsu Japan
> -- specification update strategies
> -- HAnim 2 additional parts for human organs
>
> Deferred to next Wednesday 21 AUG, 08-1000 pacific:
>
>         Michalis Kamburelis, glTF, Physically Based Rendering (PBR) and Advanced Lighting Model.
>
>         [x3d-public] My proposal of changes to X3D to enable PBR and other material improvements
>         http://web3d.org/pipermail/x3d-public_web3d.org/2019-May/010864.html
>
> ----
>
> 2.  *IIIF 3D Community Group*
>
> Vince Marchetti attended a meeting of IIIF 3D Community Group
>         https://iiif.io/community/groups/3d
>
> "A IIIF 3D community group provides an opportunity for institutions interested in interoperability to coordinate strategies and facilitate conversations about open standards that support 3D use cases. Many of the desired operations and interactions with 3D data are similar to the 2D and A/V use cases of IIIF for sharing images and annotation, and organizations are increasingly looking to integrate exhibits, displays, and comparisons of 3D data with other file types.
> We welcome participation in the IIIF 3D community group by anyone interested in exploring the prospects and promise of 3D data interoperability on the web."
>
> Vince's reactions and take-aways can be found at
>
>         [heritage] Teleconference with IIIF 3D Community Group
>         http://web3d.org/mailman/private/heritage_web3d.org/2019-August/000098.html
>
> As practitioners with a special focus on heritage issues, he thinks they might be natural partners and a community who can use X3D model publishing capabilities.  He is on the agenda for their next meeting 12 SEP to describe our many related activities.
>
> ----
>
> 3. *PointProperties signature: attenuation*
>
>         Mantis 1252
>         http://www.web3d.org/member-only/mantis/view.php?id=1252
>
> We had an interesting discussion about tradeoffs between backwards compatibility and consistency.
>
> We decided to change the signature of PointProperties attenuation to SFVec3f, matching X3DLightingNode.
>
> Details at comment 2460
>         https://www.web3d.org/member-only/mantis/view.php?id=1252#c2460
>
> As a result the prose needs to be adjusted a bit.  At that point Dick and I will enter in draft X3Dv4 spec, hopefully next Wednesday on our weekly specification editors call.
>
> ----
>
> 4. *PointSet signature: Normal*
>
> Useful discussion of issues.  Have added to Mantis.  Nicholas has offered to lead on this one, VT has relevant work in progress.
>
>         0001261: PointSet field for Normal node
>         https://www.web3d.org/member-only/mantis/view.php?id=1261
>
> Description
> Document use cases and then decide whether to include Normal node as a contained node of PointSet (similar to FaceSet and related nodes).
> Additional Information
> - Many scanners provide normal information when scanning points.
> - Mesh construction algorithms sometimes utilize normal information.
> - Normal information can be useful as part of X3D data structure.
> - Meshlab can include normal information in outputs (perhaps inputs)
> - A point set might be used to derive a mesh, or come from a mesh, so a scene should be able to include this information in a model if it is appropriate.
>
> Need to get clear on terminology, don't want to confound "angle of incidence" or related terms that are from the perspective of sensor. Normals (perpendicular vectors) are from the perspective of the geometric shape.
>
> Simply applying existing design patterns for X3DNormalNode to PointSet will be most implementable, if possible. The application context may vary somewhat from model to model - we can describe some of that - but hopefully the X3D scene graph representations.
>
> Further information on Normal
> * https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/rendering.html#Normals
> * https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/rendering.html#Normal
> * https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/rendering.html#X3DNormalNode
> * https://www.web3d.org/x3d/tooltips/X3dTooltips.html#Normal
>
> Lots of related information can be found via search, e.g.
> https://www.google.com/search?q=meshlab+normals+on+point+clouds
>
> Also needed: test content and 1-2 test scenes for conformance.
>
> ----
>
> 5. Future issues for scanning:
>
> - whether a Scanning Profile (or 3D Printing and Scanning Profile) is needed, likely oriented towards hardware and use cases.  Don will take this for action.
>
> - whether anything needs to be said about input/output operations.
>
> ----
>
> 6. *glTF X3D Features Comparison*
>
> * Attachment [3]: glTF X3D Features Comparison (3 NOV 2017)
>    https://www.web3d.org/sites/default/files/page/X3D%20Version%204%20Strategy/glTfX3dFeaturesComparison.pdf
>
> source at
>    https://docs.google.com/spreadsheets/d/12ebxqfQoFPuNhaz8wZkNE6G-w_bqt98iy6p5F9IazVM/edit#gid=0
>
> * IEEE 3D Body Processing Group comparison chart has additional formats.  Vince is tracking that activity.
>
> - Are these entries still up to date?  glTF has continued to evolve since November 2017.
>
> - We need to add a column for X3Dv4.
>
> We agreed to work towards an update to our table for expected X3Dv4 support over the next month.  This is also timely as we review our glTF and Physically Based Rendering (PBR) plans with Dr. Kamburelis.
>
> ----
>
> 7. *ISO SC24 meeting*
>
> Dick and Don are carrying forward much progress to report to the upcoming ISO Standards Committee (SC) 24 meeting in Takamatsu Japan.
> -- specification update strategies
> -- HAnim 2 additional parts for human organs
>
> Several items are not being shared satisfactorily to enable Web3D Consortium activity:
> - Mixed Augmented Reality (MAR) progress is not yet workable.
> - Software for C, C++, C# bindings shared as open source or other work can't continue.
>
> There is a LOT of development work going by the Web3D Korea Chapter - happily - but we want to ensure that requirements are well stated too.
>
> We will express our deep appreciation, with correspondingly deep motivation to do better.  The deadlines for X3Dv4 are especially relevant as both opportunity and forcing function.
>
> ----
>
> 8. *Real Soon Now*
>
> Release announcement imminent: coordinated refinements to X3D Unified Object Model (X3DUOM) with corresponding updates to
> - X3D XML Schema
> - X3D Python Language Binding
> - X3D Ontology
> - X3DJSAIL: X3D Java Scene Access Interface Library and Java 8/Java 12 testing
> - X3D Tooltips
>
> ----
>
> 9. *Upcoming Topics for X3D Group*
>
> Lots of interesting work planned for this month.  Participation welcome.
>
> In addition to these frequent minutes, you can track "big picture" and "details" for X3Dv4 at
>
>         X3Dv4 Implementations
>         https://www.web3d.org/x3dv4-implementations
>
>         Web3D.org > MEMBERS > CONTENT > MANTIS ISSUE TRACKER
>         https://www.web3d.org/member-only/mantis/view_all_bug_page.php
>
> Unless otherwise stated, teleconferences are 1-2 hours duration starting at 0800 pacific.
>
> a. 19 AUG Monday:  X3D Semantic Web Working Group
>
> b. 21 AUG Wednesday: Michalis Kamburelis, glTF, Physically Based Rendering (PBR) and Advanced Lighting Model.
>
> c. 21 AUG Wednesday 16-1700: X3Dv4 specification editor review for github spec and mantis resolution.
>
> d. 22 AUG Thursday: Design Printing Scanning Working Group, PointProperties and PointSet/Normal refinements.
>
> Unless otherwise announced, we will skip X3D Working Group meetings for the next two Fridays.
>
> e. Next X3D meeting in 3 weeks, 6 SEP 2019.
>
> September  plans:
> - ISO update report.
> - Nicholas Polys and Ander Arbelaiz, spec prose for volume component extensions (ImageAtlas and MPR).
> - Andreas Plesch, Custom elements in HTML5 and X3D prefixes.
> - Annotations Component next steps.  Suggest consider a possible reset: hold on current spec draft, confirm requirements/goals, see what is possible with HTML5+X3D.
> - newly proposed User Experience (UX) Working Group: formative discussions on goals have begun, when those individuals are ready with a draft UX Working Group Charter please present summary to X3D Working Group for cooperative development.
>
> Expect plenty of email traffic and progress in the coming weeks.
>
> Review confirmation by group: all information here is reviewed as satisfactory for public release.
>
> ----
>
> I never cease to be impressed at the depth of knowledge and breadth of activity that is ongoing.  What a learning opportunity we all share.
>
> 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
-------------- next part --------------
There are strong cases for both formats:

- Both open standards, lots of software to view/convert etc.

- glTF is more efficient to deliver to GPU.

  X3D (non-binary encodings) have to be parsed, which means your bottleneck is StrToFloat().

  X3D binary isn't very popular (not so many software to view/convert) and it's not perfect to deliver to GPU anyway. X3D binary removes the parsing problems (all those StrToFloat), but it doesn't add many ways to express a mesh data (per-vertex values, with interleaving etc.). (? Probably? Not knowing X3D binary, but probably no interleaving?)

- glTF is more modern (PBR).

- glTF seems to have more exporter support.

  Blender:
  - glTF 2.0 exporter is developed by Khronos,
  - there is a version for <= 2.79 and for >= 2.80,
  - it's even included in Blender by default,
  - it supports animations, normalmaps.

  In contrast:
  - X3D exporter is only for <= 2.79, until someone fixes it,
  - it was included in Blender by default, but not in 2.80,
  - it doesn't support animations or normalmaps (CGE exporter adds normalmaps, and can export to own animation format).

- glTF doesn't offer any interaction.

  No sensors (touch sensor, proximity sensor),
  no scripting.

- glTF doesn't offer some graphic features.

  No cubemap textures,
  no 3d textures,
  no texture coordinate generation modes,
  less ways to mix textures (although MultiTexturing in X3D comes with a large bad of problems, but they can be overcome by fixing various spec points, see CGE docs).

  No lights (image-based on not),
  at least in standard.
  There is extension for "punctual" (i.e. not image-based) lights:
  https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Khronos/KHR_lights_punctual
  and (less stable, cause only EXT) image-based lights:
  https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Vendor/EXT_lights_image_based

  No fog.
  No background.

- glTF doesn't offer some other features, I mention below some important ones:

  No easy Text writing
  (leaving conversion Text->mesh to 3D exporters is *not* enough, it doesn't allow to dynamically modify the text during game.)

  No sound.

  No NURBS.

  No shaders. (although X3D shaders need extending, to be composable -- see CGE extension.)
  Later note: Actually it has extension addressing this:
  https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Khronos/KHR_techniques_webgl

  No composition of many models using Inline?

  Although (in defense of glTF) most X3D exporters don't use these features either.
  E.g. Blender text is exported as a mesh to X3D,
  Blender sound objects are not exported to X3D,
  Blender NURBS are exported as a mesh to X3D.
  Merely having these concepts in X3D standard is not a magic wand to make them used.

  But at least APIs exist to use NURBS, sound etc.
  E.g. CGE Spine conversion converts Spine paths -> X3D NURBS.

- glTF doesn't offer scene graph?
  This is important as an engine API to build and modify what is rendered
  using X3D nodes.
  Although one can argue that applying glTF concepts in a straightforward way
  also allows you to define a reasonable API to operate on a scene.