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

Nicholas Polys npolys at vt.edu
Fri Nov 23 23:46:07 PST 2018


sorry bad keys... :-\

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

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

br,
_n


On Sat, Nov 24, 2018 at 2:43 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
>  b) typed declaration of glTF exposed events (like import/export
> declaration in X3D)
>  c)
>
>
>
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20181124/b2131cb0/attachment-0001.html>


More information about the x3d-public mailing list