[x3d-public] glTF Importing [was: X3D working group meeting minutes16 NOV 2018]

Andreas Plesch andreasplesch at gmail.com
Sat Nov 24 15:04:09 PST 2018


Nice summary to keep us on track. Another dimension is the option to
translate glTF to X3D first. A translator will require new nodes,
which otherwise could remain internal/not standardized for Inline.
Also being able to Inline without additional work is friendly to
authors. See below for direct responses.

On Sat, Nov 24, 2018 at 2:46 AM Nicholas Polys <npolys at vt.edu> wrote:
>>
>> Great discussion and agreed!
>>  there are a few ways you could skin this cat:
>>  a) Inline functions as specified and no internal namespace content is addressible.

The black box model. I think this would mean not being able to play
animations but has the advantage of least specification work and clear
boundaries.

>>  b) typed declaration of glTF exposed events (like import/export declaration in X3D)

Not quite sure what events are referred to. Presumably parser events
when encountering a json key. Autoimporting of some nodes with good,
inherited or constructed names under a namespace name seems perhaps
most practical. Perhaps castle Collada import has a template to follow
?

> c) typed nodes such as SRC/ X3DOM proposal of ExternalGeometry, ExternalAppearance... allowing mix and match of valid scene grapht content models.

X3DOM's BufferGeometry plus Accessor/View nodes are effectively the
successor to ExternalGeometry and binary glTF the successor to SRC.
ExternalViewpoint, ExternalInterpolator and ExternalAnimation
(somehow) may then also need to be considered. This looks orthogonal
to Inline ?

An alternative is to allow autoimport from Inline, and allow
nonrendering Inlines if there is no scene defined, but only resources
for a scene. No new nodes would be required.

<Inline url='no_scene.glTF' autoImport='myglTF' />
<Shape><AnyGeometry USE='myglTF-Mesh1Geometry'/></Shape>

Meshes and Geometries are not named in glTF.

Hm, not sure.

> d) use the W3C Media Fragments API to address 'nodes ' in an ' unstructured' 3D media data set  ....   my.gltf#walkAnimation

https://www.w3.org/TR/media-frags/

The API seems to be designed for movies and consists of key value
pairs. So an URI fragment for an Inline url field value could look
like

..my.glTF#node=greenBox : only greenBox, no animations
..my.glTF#node=greenBox&animation=wiggle : only greenBox and named
wiggle animation for it (also become export names)

Fragments seems compatible with a, b, and c as they select subcontent.

-Andreas

>
> br,
> _n
>>
>> On Sat, Nov 24, 2018 at 1:52 AM John Carlson <yottzumm at gmail.com> wrote:
>>>
>>> I think the best approach would be to handle a bunch of vertices or faces together in parallel or pipelined.  Particularly to achieve video card speedups.
>>>
>>> John
>>>
>>> On Fri, Nov 23, 2018 at 10:07 PM Andreas Plesch <andreasplesch at gmail.com> wrote:
>>>>
>>>> Good points.It may be instructive to see an example of how currently
>>>> x3dom is adding glTF to the X3D scene graph. Here is how a glTF of a
>>>> single triangle becomes an X3D child of the inline node:
>>>>
>>>> <inline url="https://raw.githubusercontent.com/cx20/gltf-test/master/tutorialModels/SimpleMaterial/glTF/SimpleMaterial.gltf"
>>>> namespacename="gltf" mapdeftoid="true">
>>>>   <transform id="gltf__NODE0" def="NODE0">
>>>>     <shape>
>>>>       <appearance>
>>>>         <physicalmaterial basecolorfactor="1 0.766 0.336 1"
>>>> metallicfactor="0.5" roughnessfactor="0.1" emissivefactor="0 0 0"
>>>> alphamode="OPAQUE" alphacutoff="0.5" model="roughnessMetallic"
>>>> diffusefactor="1,1,1,1" specularfactor="1,1,1" glossinessfactor="1"
>>>> normalspace="TANGENT" normalbias="-1,-1,1"
>>>> normalscale="1"></physicalmaterial>
>>>>       </appearance>
>>>>       <buffergeometry buffer="simpleTriangle.bin" position="0.5 0.5 0"
>>>> size="1 1 0" vertexcount="3" primtype="TRIANGLES">
>>>>         <buffergeometryaccessor buffertype="INDEX" view="0"
>>>> byteoffset="0" bytestride="0" components="1" componenttype="5123"
>>>> count="3"></buffergeometryaccessor>
>>>>        <buffergeometryaccessor buffertype="POSITION" view="1"
>>>> byteoffset="0" bytestride="0" components="3" componenttype="5126"
>>>> count="3"></buffergeometryaccessor>
>>>>         <buffergeometryview target="34963" byteoffset="0"
>>>> bytelength="6" id="gltf__0"></buffergeometryview>
>>>>         <buffergeometryview target="34962" byteoffset="8"
>>>> bytelength="36" id="gltf__1"></buffergeometryview>
>>>>       </buffergeometry>
>>>>      </shape>
>>>>   </transform>
>>>> </inline>
>>>>
>>>> (buffergeometryaccessor/view became just bufferaccessor/view:
>>>> https://github.com/x3dom/x3dom/issues/898)
>>>>
>>>> and here is the glTF json :
>>>>
>>>> {  "scenes" : [
>>>>     {  "nodes" : [ 0 ] }
>>>>   ],
>>>>   "nodes" : [
>>>>     { "mesh" : 0 }
>>>>   ],
>>>>   "meshes" : [
>>>>     {
>>>>       "primitives" : [ {
>>>>         "attributes" : { "POSITION" : 1 },
>>>>         "indices" : 0,
>>>>         "material" : 0
>>>>       } ]
>>>>     }
>>>>   ],
>>>>   "buffers" : [
>>>>     {
>>>>       "uri" : "simpleTriangle.bin",
>>>>       "byteLength" : 44
>>>>     }
>>>>   ],
>>>>   "bufferViews" : [
>>>>     {
>>>>       "buffer" : 0,
>>>>       "byteOffset" : 0,
>>>>       "byteLength" : 6,
>>>>       "target" : 34963
>>>>     },
>>>>     {
>>>>       "buffer" : 0,
>>>>       "byteOffset" : 8,
>>>>       "byteLength" : 36,
>>>>       "target" : 34962
>>>>     }
>>>>   ],
>>>>   "accessors" : [
>>>>     {
>>>>       "bufferView" : 0,
>>>>       "byteOffset" : 0,
>>>>       "componentType" : 5123,
>>>>       "count" : 3,
>>>>       "type" : "SCALAR",
>>>>       "max" : [ 2 ],
>>>>       "min" : [ 0 ]
>>>>     },
>>>>     {
>>>>       "bufferView" : 1,
>>>>       "byteOffset" : 0,
>>>>       "componentType" : 5126,
>>>>       "count" : 3,
>>>>       "type" : "VEC3",
>>>>       "max" : [ 1.0, 1.0, 0.0 ],
>>>>       "min" : [ 0.0, 0.0, 0.0 ]
>>>>     } ],
>>>>   "materials" : [
>>>>     {
>>>>       "pbrMetallicRoughness": {
>>>>         "baseColorFactor": [ 1.000, 0.766, 0.336, 1.0 ],
>>>>         "metallicFactor": 0.5,
>>>>         "roughnessFactor": 0.1
>>>>       }
>>>>     } ],
>>>>   "asset" : { "version" : "2.0" }
>>>> }
>>>>
>>>> BufferGeometry references the binary data (file or dataurl or
>>>> objecturl). It was most natural to also introduce the accessor/view
>>>> nodes which define how the referenced data is interpreted. It is then
>>>> up to the implementation how the binary data is used for rendering
>>>> etc.
>>>>
>>>> https://raw.githubusercontent.com/KhronosGroup/glTF-Sample-Models/master/2.0/BoxAnimated/glTF/BoxAnimated.gltf
>>>>
>>>> has a simple animation of translation. It gets translated to this:
>>>>
>>>> <transform id="gltf__NODE3" def="NODE3">
>>>> ...
>>>> </transform>
>>>> <transform id="gltf__NODE0" def="NODE0" translation="0,0,0">
>>>>   <transform id="gltf__NODE1" def="NODE1">
>>>>     <transform rotation="0 0 0 6.283185307179586" id="gltf__NODE2" def="NODE2" >
>>>> ...
>>>>     </transform>
>>>>   </transform>
>>>> </transform>
>>>> <timesensor loop="true" cycleinterval="3.708329916000366"
>>>> def="clockANI0" enabled="true" first="true"
>>>> id="gltf__clockANI0"></timesensor>
>>>> <orientationinterpolator def="interANI0CH0" key="sampler.input.array"
>>>> keyvalue="sampler.output.array" buffer="BoxAnimated0.bin"
>>>> id="gltf__interANI0CH0">
>>>>   <buffergeometryaccessor buffertype="SAMPLER_INPUT" view="2"
>>>> byteoffset="0" bytestride="0" components="1" componenttype="5126"
>>>> count="2"></buffergeometryaccessor>
>>>>   <buffergeometryaccessor buffertype="SAMPLER_OUTPUT" view="3"
>>>> byteoffset="0" bytestride="0" components="4" componenttype="5126"
>>>> count="2"></buffergeometryaccessor>
>>>>   <buffergeometryview target="undefined" byteoffset="7760"
>>>> bytelength="24" id="gltf__2"></buffergeometryview>
>>>>   <buffergeometryview target="undefined" byteoffset="0"
>>>> bytelength="32" id="gltf__3"></buffergeometryview>
>>>> </orientationinterpolator>
>>>> <route fromfield="fraction_changed" fromnode="clockANI0"
>>>> tofield="set_fraction" tonode="interANI0CH0"></route>
>>>> <route fromfield="value_changed" fromnode="interANI0CH0"
>>>> tofield="set_rotation" tonode="NODE2"></route>
>>>> <positioninterpolator def="interANI0CH1" key="sampler.input.array"
>>>> keyvalue="sampler.output.array" buffer="BoxAnimated0.bin"
>>>> id="gltf__interANI0CH1">
>>>>   <buffergeometryaccessor buffertype="SAMPLER_INPUT" view="2"
>>>> byteoffset="8" bytestride="0" components="1" componenttype="5126"
>>>> count="4"></buffergeometryaccessor>
>>>>   <buffergeometryaccessor buffertype="SAMPLER_OUTPUT" view="4"
>>>> byteoffset="0" bytestride="0" components="3" componenttype="5126"
>>>> count="4"></buffergeometryaccessor>
>>>>   <buffergeometryview target="undefined" byteoffset="7760"
>>>> bytelength="24" id="gltf__2"></buffergeometryview>
>>>>   <buffergeometryview target="undefined" byteoffset="32"
>>>> bytelength="48" id="gltf__4"></buffergeometryview>
>>>> </positioninterpolator>
>>>> <route fromfield="fraction_changed" fromnode="clockANI0"
>>>> tofield="set_fraction" tonode="interANI0CH1"></route>
>>>> <route fromfield="value_changed" fromnode="interANI0CH1"
>>>> tofield="set_translation" tonode="NODE0"></route>
>>>>
>>>> Here, the glTF animation can be faithfully translated to
>>>> TimeSensor/Interpolator/ROUTE combos with the addition that the
>>>> interpolators take their key and keyValue field values from the binary
>>>> buffer accessor  nodes as well, if there is a buffer field value.
>>>>
>>>> For x3dom and perhaps other implementations it seemed most natural to
>>>> introduce these binary access nodes for glTF loading and perhaps other
>>>> use.
>>>>
>>>> From a specification perspective, however, introducing new nodes is
>>>> something which needs to be carefully considered and is hard to do
>>>> well. For example, it may be more appropriate to introduce new
>>>> interpolator nodes rather than extending the existing ones.
>>>>
>>>> So from a specification perspective it is attractive to not expose how
>>>> the glTF scene is actually represented in the X3D scene  graph and
>>>> essentially keep it a black box. The spec. language could then even
>>>> boil down to allowing glTF content and only referring to glTF to how
>>>> the content should be rendered and animated. Implementation are then
>>>> of course still free to use internal nodes and potentially expose them
>>>> but in a non-standardized way.
>>>>
>>>> But most glTF features do not require new X3D nodes to be represented
>>>> in the scene graph, and an ability to import those is very useful,
>>>> probably expected by authors and not too hard to implement since all
>>>> pieces are already in place. From a specification perspective this
>>>> ability then would need to be very well defined, again requiring
>>>> careful selection of what can be imported and how. Other formats such
>>>> jpeg or nrrd, though simpler, are already referenced in the spec., so
>>>> I think it may be possible for the spec. to be precise on how certain
>>>> glTF features get absorbed into a X3D scene.
>>>>
>>>> For example, glTF "nodes" can be directly represented by named X3D
>>>> Transform nodes, and glTF cameras by X3D Viewpoint nodes. The exported
>>>> DEF names could be the glTF names (perhaps with a prefix) where
>>>> provided or a unique constructed name using the index from the glTF
>>>> ('gltfTRANFORM_0') where not provided.
>>>>
>>>> Perhaps that is all which could be required in a spec. in terms of
>>>> interplay between glTF and X3D.
>>>>
>>>> It is less clear how glTF animations should be required to be absorbed
>>>> into X3D from a spec perspective. One approach is as shown which
>>>> requires a named TimeSensor for each animation (which can target
>>>> different channels in glTF). The DEF name would be after the index in
>>>> the glTF animations array ('gltfCLOCK_0'). But implementations may
>>>> choose to not use a TimeSensor/Interpolator/Route combo and use a more
>>>> direct approach. I suppose then still a virtual TimeSensor could be
>>>> required to be exported to provide an interface for the animation.
>>>>
>>>> If PhysicalMaterial gets picked up by X3D, it would become the node to
>>>> represent the glTF material, also named after the index
>>>> ('gltfMaterial_0').
>>>>
>>>> I hope to find the time and strength at some point to compare glTF
>>>> skinned skeleton animation with HAnim animation. I think they are
>>>> largely compatible.
>>>>
>>>> -Andreas
>>>>
>>>> On Thu, Nov 22, 2018 at 5:52 AM Michalis Kamburelis
>>>> <michalis.kambi at gmail.com> wrote:
>>>> >
>>>> > Hi,
>>>> >
>>>> > Good discussion :) Some notes from my point of view:
>>>> >
>>>> > 1. I agree with Leonard that "unpacking" all glTF meshes (expressed in
>>>> > glTF in a format very efficient to deliver to GPU) into X3D
>>>> > IndexedFaceSet is not the optimal way of using glTF. The optimal way
>>>> > of integrating glTF into anything (including X3D) is to use the glTF
>>>> > mesh data in the format it is provided, and pass it straight to GPU
>>>> > (without transforming it, e.g. changing interleaved into
>>>> > non-interleaved).
>>>> >
>>>> >     That said, I think we should enable this by introducing new X3D
>>>> > nodes able to express the same things that glTF allows (e.g. mesh data
>>>> > can be in a binary file, vertex and texture coords can be interleaved
>>>> > etc.). I guess that this is similar to "BufferGeometry" in X3DOM
>>>> > mentioned by Andreas.
>>>> >
>>>> >     My goal is to be able to have 100% of the scene graph expressed
>>>> > using X3D nodes. And I want to load this scene graph from X3D files,
>>>> > glTF files, or a variety of other formats (
>>>> > https://castle-engine.io/x3d_extensions.php#section_ext_inline_for_all
>>>> > - in CGE we load already Collada, 3DS, MD3, Wavefront, Spine JSON and
>>>> > some more into X3D scene graph ).
>>>> >
>>>> >     IOW, I would not like to see "glTF model" to be a "black box"
>>>> > inside X3D scene, where whole glTF content lives as something
>>>> > unrelated to the X3D scene graph. This would be bad for developers
>>>> > using my engine, and for implementation of my engine too: in both
>>>> > cases, we now enjoy the flexibility/power/simplicity coming from the
>>>> > fact that *everything* rendered in 3D world is a X3D scene graph.
>>>> >
>>>> > 2. I'm not sure whether glTF is an ""archive format"", but I know it
>>>> > is a good asset interchange format. It's a precise specification.
>>>> > Although the mesh data is provided in a GPU-friendly format (binary,
>>>> > with interleaving etc.), but it is clearly specified how does this
>>>> > format look like, and you can always unpack and transform this mesh
>>>> > data on CPU, convert it to other formats and so on.
>>>> >
>>>> >     And as a practical matter, Blender->glTF 2.0 exporter is simply
>>>> > better than Blender->X3D exporter, e.g. because it supports
>>>> > animations. For purely practical reasons, this makes glTF 2.0 a better
>>>> > interchange format right now. Blender->X3D exporter doesn't get as
>>>> > much development.
>>>> >
>>>> >     ( In Castle Game Engine, we have a slightly extended X3D exporter,
>>>> > and a way to export animations to castle-anim-frames which is really
>>>> > just a series of X3D files:
>>>> > https://castle-engine.io/creating_data_blender.php . However,
>>>> > integrating glTF animations (as X3D nodes!) would be much more
>>>> > efficient than our castle-anim-frames. )
>>>> >
>>>> > 3. As for skinned animations, I believe that H-Anim is not limited to
>>>> > humanoid animation. In my eyes, it would be better if it was called
>>>> > "skinned animation" than "humanoid animation", and the node
>>>> > "HAnimHumanoid" could be called "AnimatedModel" or something like
>>>> > that.
>>>> >
>>>> >     The specification doesn't limit H-Anim use to humanoids, and (from
>>>> > earlier threads on x3d-public) it was not intended to be limited to
>>>> > humanoids. I think that H-Anim capabilities are good, it's just an
>>>> > unfortunate naming, suggesting that it's tied to humanoids.
>>>> >
>>>> >     However, I do not have good knowledge of glTF animation
>>>> > capabilities. I cannot say whether H-Anim satisfies everything that
>>>> > glTF can express. But if it doesn't, my solution (and reason for it)
>>>> > would be the same as in AD 1: We should extend X3D (with new
>>>> > nodes/fields) to make it possible to express glTF functionality using
>>>> > X3D nodes.
>>>> >
>>>> > Best regards,
>>>> > Michalis
>>>> >
>>>> > Andreas Plesch <andreasplesch at gmail.com> wrote:
>>>> > >
>>>> > > 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
>>>> > >
>>>> > > _______________________________________________
>>>> > > x3d-public mailing list
>>>> > > x3d-public at web3d.org
>>>> > > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>>
>>>>
>>>>
>>>> --
>>>> Andreas Plesch
>>>> Waltham, MA 02453
>>>>
>>>> _______________________________________________
>>>> x3d-public mailing list
>>>> x3d-public at web3d.org
>>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>>
>>> _______________________________________________
>>> x3d-public mailing list
>>> x3d-public at web3d.org
>>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>
>>
>>
>> --
>> Nicholas F. Polys, Ph.D.
>>
>> Director of Visual Computing
>> Virginia Tech Research Computing
>>
>> Affiliate Professor
>> Virginia Tech Department of Computer Science
>
>
>
> --
> Nicholas F. Polys, Ph.D.
>
> Director of Visual Computing
> Virginia Tech Research Computing
>
> Affiliate Professor
> Virginia Tech Department of Computer Science



-- 
Andreas Plesch
Waltham, MA 02453



More information about the x3d-public mailing list