[x3d-public] X3D working group meeting minutes16 NOV 2018

[Andreas Plesch]

ad point clouds:

massive, lighted point clouds should be possible to implement in
x3dom/x_ITE as webgl shaders exist. But still significant investment in
resources/time.

ad glTF inline:

EXPORT/IMPORT: I would favor default exporting/importing of all glTF nodes
as equivalent X3D nodes using their glTF names or index as DEF names,
probably under an inline provided namespace name as prefix.

Scenes: a glTF without a scene but just a collection of nodes is valid.
Since the scene graph is then incomplete, it is required not to be
rendered. It can be used as a library of resources to be included somewhere
else in the X3D. This way a by default imported glTF which only contains a
material can be used in a Shape node's material field. Referencing a
geometry is trickier since in glTF geometries do not have a name or an
index. They are part of a mesh (Shape in X3D). So 'mesh_1' could refer to
the complete mesh as a Shape, and 'meshgeometry_1' or just 'geometry_1' to
just the geometry of mesh_1.
A single glTF can contain multiple scenes although I have not seen one. X3D
could just bail and say undefined, or always render the first one only.

Cameras: almost 1:1 mappable to Viewpoint, except for near/far which
correspond to NavigationInfo fields. As such added to Viewpoint list and
stack.

Animations: can be mapped to TimeSensor/Interpolator/Route combos. But glTF
does not define when an animation begins playing. It is expected that after
import the player/app decides that. Most glTF viewer just start playing all
animations after loading. Control in X3D would be via imported TimeSensor.

cubicspline: as mode of interpolator.

Lights: glTF itself does not define lights. A proposed material commons
extension defines lights but is in limbo.

PBR material: cannot be mimicked by Blinn-Phong shading and requires a
different set of parameters. In effect, a new PBRMaterial X3D node is
needed. Equations for an example shader are provided, but not normative.
While not included in glTF, image based lighting (IBL) is often used in
glTF viewers. An EnvironmentLight X3D node was proposed.

That became longer than expected. Thanks for reading,

Andreas
---

>
> Message: 2
> Date: Fri, 16 Nov 2018 18:06:11 +0000
> From: "Brutzman, Donald (Don) (CIV)" <brutzman at nps.edu>
> To: X3D Graphics public mailing list <x3d-public at web3d.org>
> Subject: [x3d-public] X3D working group meeting minutes16 NOV 2018:
>         X3D Semantic Web, X3Dv4
> Message-ID: <d5aaf236-0290-f122-cb15-1dbcc0954f69 at nps.edu>
> Content-Type: text/plain; charset="utf-8"
>
> 0. Attendees: Anita Havele, Michalis Kamburelis, Vince Marchetti,
> Christophe Mouton, Nicholas Polys, Dick Puk and Don Brutzman.
> ==============================
> 3. Primary working group goal is X3D version 4.0.
>
>         X3D Version 4.0 Development
>         http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development
>
> New.  Can we propose certain parts of X3Dv4 as recommended for
> implementation testing by the end of the year?  Our motivation is encourage
> accelerated development of the most important capabilities and get them
> widely available for testing and demonstration.  Intended target
> implementations are X3DOM, X_ITE, Castle Game Engine and perhaps others.
>
> Candidates:
>
> a. *3D Printing and Scanning Profile*.  Addition of Point size, Point
> normals, possibly point sprites.  Leonard correctly notes that we need to
> look ASTM E57 mappability/portability as well. Anything else?
>
>         Wikipedia E57: A file format developed by ASTM International for
> storing point clouds and images.
>
>         ASTM Committee E57 on 3D Imaging Systems
>         https://www.astm.org/COMMITTEE/E57.htm
>
>         Wikipedia: Point cloud
>         https://en.wikipedia.org/wiki/Point_cloud
>
> b. *Inline support for glTF and Physically Based Rendering*.
> -  Michalis notes that required, well-defined glTF lighting model implies
> experimental X3D lighting-model changes that correspond to).
> - Vince described how we need to scope this to Shape/mesh capabilities, or
> possibly other glTF capabilities also e.g. Camera etc.
>
> c. Others?  *RenderedTexture* might be easy.
>
>         http://www.xj3d.org/extensions/render_texture.html
>
>         TODO: Michalis will post further information
>
> For CAD Design Printing Scanning group's arena, there is a lot of work
> going on with STEP.  It would be good to consider our best strategies for
> STEP support in 2019: encourage translators/import/export?  Best
> practices?  Native support in X3D?
>
> This is a year-end opportunity to prioritize the most feasible and
> valuable next steps for progress.  We would publish and prioritize a "short
> list" of what nodes need to be implemented next.
>
> Great discussion today!  Nicholas and Michalis each have blogs in
> preparation for release Real Soon Now (RSN).
>
> We intend to proceed in this direction.  I will need help to get this
> properly proposed publicly by year's end.  Who is willing to lead each
> category?
>
>
> ------------------------------
>
> End of x3d-public Digest, Vol 116, Issue 20
> *******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20181120/e42287ea/attachment.html>