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

John Carlson yottzumm at gmail.com
Fri Nov 23 22:50:54 PST 2018


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20181124/51f234cd/attachment-0001.html>


More information about the x3d-public mailing list