[x3d-public] glTF Importing [was: X3D working group meeting minutes16 NOV 2018]
Leonard Daly
Leonard.Daly at realism.com
Tue Nov 20 07:58:29 PST 2018
It seems to me that importing glTF defeats the entire purpose of glTF.
It is optimized to deliver data to the graphics card. An attempt to
import that data into X3D not only looses all of the optimization, it
adds overhead converting into the player's X3D data structure, then back
to the graphics card calls. Also, as others have pointed out, there is
no reason that glTF would be an archive format. It may change as
graphics cards change. That would require the specification and player
to track the changes and make the necessary adjustments.
glTF animations are potentially full skin animations (weighted and moved
according to bone). These are not necessary H-Anim type models (they may
be trees, mechanical parts, etc.). That would need to be implemented
highly efficiently in X3D before this would work. There are ways to
control animation. I'll get to that below.
It seems to me that it is much better to use glTF as it was designed --
import everything into the graphics card. It was the developer's choice
to use that glTF file. Trying to give an X3D player control over all
aspects of the file is the 3D equivalent of trying to give an X3D player
control of individual pixels in an imported image.
glTF animations are named; however, there is nothing that requires the
names to be anything useful. A named animation may not even be a
complete motion. For example. the glTF monster (it's in the repository)
has over 20 named animations. All contribute to the full motion cycle of
the monsters. Individual animations are things like the tail motion, or
the movement of the right front foot. It is possible to identify
animations (by name) that are needed for any particular effect and
control them on a frame-by-frame basis. I don't know all of the details,
but it is available in THREE.js so it can be implemented.
Leonard Daly
> Added note to glTF lights below:
>
> On Tue, Nov 20, 2018 at 1:23 AM Andreas Plesch
> <andreasplesch at gmail.com <mailto:andreasplesch at gmail.com>> wrote:
>
> 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.
>
>
> There is now another extension:
> https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Khronos/KHR_lights_punctual
> . It defines point, directional and spot lights, largely compatible
> with X3D lights but has a different recommended attenuation law, and
> required non-rendering/culling beyond the max. distance. The extension
> is supported by the glTF blender exporter. There is no ambient light.
>
>
> 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
> <mailto:brutzman at nps.edu>>
> To: X3D Graphics public mailing list <x3d-public at web3d.org
> <mailto: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
> <mailto: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
> *******************************************
>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
--
*Leonard Daly*
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Past Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20181120/97aa80c2/attachment.html>
More information about the x3d-public
mailing list