[x3d-public] glTF Importing [was: X3D working group meeting minutes16 NOV 2018]
Nicholas Polys
npolys at vt.edu
Fri Nov 23 23:43:04 PST 2018
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20181124/86dd1626/attachment-0001.html>
More information about the x3d-public
mailing list