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

Andreas Plesch andreasplesch at gmail.com
Sun Nov 25 21:16:09 PST 2018


On Sun, Nov 25, 2018, 11:54 AM John Carlson <yottzumm at gmail.com wrote:

>
> I believe the glTF is only being translated to XML because JSON goes
> through the X3D JSON parser.  We should probably look at for the “X3D” key
> in the X3D JSON and distinguish it from the glTF JSON.
>
Sofar glTF inline support is only available on the webvr x3dom branch.
There is a special glTF json parser which does the translat. The file
extension (gltf,glb) may be another option to distinguish.

>
> Will DEF and USE apply to glTF?
>
Potentially, since resources such as a set of coordinates can be reused in
glTF. However, I think the scene graph in glTF is a strict tree, and
multiple parents are not a allowed. So, I think meshes (Shapes) may only be
referenced once.

>
>
> Now you see how “clever” I was in plugging X3D JSON into X_ITE and
> X3DOM…basically brings everyone back to DOM. 😊😊😊 One DOM to rule them
> all.
>
>
>
> Frodo, Sam and Gollum at the cracks of Mt Doom (DOM): Would anyone like to
> work on ROUTEs for glTF? I’ve got some ideas about providing both a set and
> get proxy which may overcome previous difficulties in persisting changes.
> This is the code how it stands:
>
>
>
>
> https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/route.js
>
>
>
> Send the eagles to save Frodo from DOM!
>
>
>
> Or alternatively, introspect the JSON before converting to DOM.
>
>
>
> Does anyone know any good jokes about JSON and the Argonauts?
>
>
>
> Sincerely,
>
>
>
> Frodo
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *Andreas Plesch <andreasplesch at gmail.com>
> *Sent: *Friday, November 23, 2018 10:07 PM
> *To: *Michalis Kamburelis <michalis.kambi at gmail.com>
> *Cc: *X3D Graphics public mailing list <x3d-public at web3d.org>
> *Subject: *Re: [x3d-public] glTF Importing [was: X3D working group
> meetingminutes16 NOV 2018]
>
>
>
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20181126/4c382a48/attachment-0001.html>


More information about the x3d-public mailing list