[x3d-public] glTF Importing [was: X3D working group meeting minutes16 NOV 2018]
Andreas Plesch
andreasplesch at gmail.com
Tue Nov 20 13:47:20 PST 2018
It is true that glTF is designed to easily upload to the GPU. But the
fact of the matter is that it is used increasingly as an exchange and
asset format (there are many exporters and importers). It is also the
case that many/most importers translate glTF into their native data
structures first, due to convenience (three.js does that, for example)
before uploading to the GPU. x3dom added a BufferGeometry X3D node for
that purpose which is a thin wrapper around the glTF mesh geometry. It
is not too hard to import into X3D since there are X3D nodes
equivalent to most glTF features (perhaps except for
skinning/morphing). The ability of glTF to act as a library without
rendering is actually advertised by Khronos. I think many of the glTF
creators would now hesitate to call it the jpeg of 3d although they
still do since it is such a good line. It has become larger than that.
https://www.khronos.org/assets/uploads/developers/library/2018-webinar-gltf-2/Webinar-glTF-2-Status-and-Outlook_Jul18.pdf
is a good status report. It is interesting how the outlook makes it
more similar to X3D (lights, sound, events, arbitrary animations).
glTF 2.0 will not change. It is a standard (with rough edges). There
will be a glTF 3.0 at some point but nobody is interested in
disrupting the ecosystem hugely.
Many glTF examples have hard to understand animations due to
collada2gltf and other automated conversions:
https://github.com/KhronosGroup/glTF/issues/1052
Yes, three.js can control the named animations, but only after
importing them into its own animation system. It would be necessary to
have an equivalent mechanism for X3D which probably requires some
importing.
Here is an animated glTF loaded into x3dom which only uses trafo
animation (no sknning/morphing):
https://raw.githack.com/andreasplesch/x3dom/glTF2TSAP-test/test/functional/inline-gltf.html
If you look inside the Inline node in the devtools, you can see all
the TimeSensor/Route/Interpolator combos which could be then
controlled. It would be possible to add a control GUI, for example.
As a first support level, one could ignore animations, and only import
cameras. The glTF scene otherwise is just equivalent to an inert Shape
under the grouping Inline.
As a full support level, one could expose everything under a name space.
Intermediate levels could mean importing cameras and being able to
control (start/stop) animations tied to their targets but not the
targets/nodes themselves.
-Andreas
> Date: Tue, 20 Nov 2018 07:58:29 -0800
> From: Leonard Daly <Leonard.Daly at realism.com>
> To: x3d-public at web3d.org
> Subject: Re: [x3d-public] glTF Importing [was: X3D working group
> meeting minutes16 NOV 2018]
> Message-ID: <f345230f-01bc-9211-3bbb-b4e301ec41cc at realism.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> 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-0001.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
> ------------------------------
>
> End of x3d-public Digest, Vol 116, Issue 25
> *******************************************
--
Andreas Plesch
Waltham, MA 02453
More information about the x3d-public
mailing list