<div dir="ltr">sorry bad keys... :-\<div><br><div> c) typed nodes such as SRC/ X3DOM proposal of ExternalGeometry, ExternalAppearance... allowing mix and match of valid scene grapht content models.</div></div><div><br></div><div>d) use the W3C Media Fragments API to address 'nodes ' in an ' unstructured' 3D media data set .... my.gltf#walkAnimation</div><div><br></div><div>br,</div><div>_n</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Nov 24, 2018 at 2:43 AM Nicholas Polys <<a href="mailto:npolys@vt.edu">npolys@vt.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Great discussion and agreed!<div> there are a few ways you could skin this cat:</div><div> a) Inline functions as specified and no internal namespace content is addressible </div><div> b) typed declaration of glTF exposed events (like import/export declaration in X3D)</div><div> c)</div><div> </div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Nov 24, 2018 at 1:52 AM John Carlson <<a href="mailto:yottzumm@gmail.com">yottzumm@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="auto">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.</div></div></div><div><div dir="auto"><br></div><div dir="auto">John</div><div><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 23, 2018 at 10:07 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Good points.It may be instructive to see an example of how currently<br>
x3dom is adding glTF to the X3D scene graph. Here is how a glTF of a<br>
single triangle becomes an X3D child of the inline node:<br>
<br>
<inline url="<a href="https://raw.githubusercontent.com/cx20/gltf-test/master/tutorialModels/SimpleMaterial/glTF/SimpleMaterial.gltf" rel="noreferrer" target="_blank">https://raw.githubusercontent.com/cx20/gltf-test/master/tutorialModels/SimpleMaterial/glTF/SimpleMaterial.gltf</a>"<br>
namespacename="gltf" mapdeftoid="true"><br>
<transform id="gltf__NODE0" def="NODE0"><br>
<shape><br>
<appearance><br>
<physicalmaterial basecolorfactor="1 0.766 0.336 1"<br>
metallicfactor="0.5" roughnessfactor="0.1" emissivefactor="0 0 0"<br>
alphamode="OPAQUE" alphacutoff="0.5" model="roughnessMetallic"<br>
diffusefactor="1,1,1,1" specularfactor="1,1,1" glossinessfactor="1"<br>
normalspace="TANGENT" normalbias="-1,-1,1"<br>
normalscale="1"></physicalmaterial><br>
</appearance><br>
<buffergeometry buffer="simpleTriangle.bin" position="0.5 0.5 0"<br>
size="1 1 0" vertexcount="3" primtype="TRIANGLES"><br>
<buffergeometryaccessor buffertype="INDEX" view="0"<br>
byteoffset="0" bytestride="0" components="1" componenttype="5123"<br>
count="3"></buffergeometryaccessor><br>
<buffergeometryaccessor buffertype="POSITION" view="1"<br>
byteoffset="0" bytestride="0" components="3" componenttype="5126"<br>
count="3"></buffergeometryaccessor><br>
<buffergeometryview target="34963" byteoffset="0"<br>
bytelength="6" id="gltf__0"></buffergeometryview><br>
<buffergeometryview target="34962" byteoffset="8"<br>
bytelength="36" id="gltf__1"></buffergeometryview><br>
</buffergeometry><br>
</shape><br>
</transform><br>
</inline><br>
<br>
(buffergeometryaccessor/view became just bufferaccessor/view:<br>
<a href="https://github.com/x3dom/x3dom/issues/898" rel="noreferrer" target="_blank">https://github.com/x3dom/x3dom/issues/898</a>)<br>
<br>
and here is the glTF json :<br>
<br>
{ "scenes" : [<br>
{ "nodes" : [ 0 ] }<br>
],<br>
"nodes" : [<br>
{ "mesh" : 0 }<br>
],<br>
"meshes" : [<br>
{<br>
"primitives" : [ {<br>
"attributes" : { "POSITION" : 1 },<br>
"indices" : 0,<br>
"material" : 0<br>
} ]<br>
}<br>
],<br>
"buffers" : [<br>
{<br>
"uri" : "simpleTriangle.bin",<br>
"byteLength" : 44<br>
}<br>
],<br>
"bufferViews" : [<br>
{<br>
"buffer" : 0,<br>
"byteOffset" : 0,<br>
"byteLength" : 6,<br>
"target" : 34963<br>
},<br>
{<br>
"buffer" : 0,<br>
"byteOffset" : 8,<br>
"byteLength" : 36,<br>
"target" : 34962<br>
}<br>
],<br>
"accessors" : [<br>
{<br>
"bufferView" : 0,<br>
"byteOffset" : 0,<br>
"componentType" : 5123,<br>
"count" : 3,<br>
"type" : "SCALAR",<br>
"max" : [ 2 ],<br>
"min" : [ 0 ]<br>
},<br>
{<br>
"bufferView" : 1,<br>
"byteOffset" : 0,<br>
"componentType" : 5126,<br>
"count" : 3,<br>
"type" : "VEC3",<br>
"max" : [ 1.0, 1.0, 0.0 ],<br>
"min" : [ 0.0, 0.0, 0.0 ]<br>
} ],<br>
"materials" : [<br>
{<br>
"pbrMetallicRoughness": {<br>
"baseColorFactor": [ 1.000, 0.766, 0.336, 1.0 ],<br>
"metallicFactor": 0.5,<br>
"roughnessFactor": 0.1<br>
}<br>
} ],<br>
"asset" : { "version" : "2.0" }<br>
}<br>
<br>
BufferGeometry references the binary data (file or dataurl or<br>
objecturl). It was most natural to also introduce the accessor/view<br>
nodes which define how the referenced data is interpreted. It is then<br>
up to the implementation how the binary data is used for rendering<br>
etc.<br>
<br>
<a href="https://raw.githubusercontent.com/KhronosGroup/glTF-Sample-Models/master/2.0/BoxAnimated/glTF/BoxAnimated.gltf" rel="noreferrer" target="_blank">https://raw.githubusercontent.com/KhronosGroup/glTF-Sample-Models/master/2.0/BoxAnimated/glTF/BoxAnimated.gltf</a><br>
<br>
has a simple animation of translation. It gets translated to this:<br>
<br>
<transform id="gltf__NODE3" def="NODE3"><br>
...<br>
</transform><br>
<transform id="gltf__NODE0" def="NODE0" translation="0,0,0"><br>
<transform id="gltf__NODE1" def="NODE1"><br>
<transform rotation="0 0 0 6.283185307179586" id="gltf__NODE2" def="NODE2" ><br>
...<br>
</transform><br>
</transform><br>
</transform><br>
<timesensor loop="true" cycleinterval="3.708329916000366"<br>
def="clockANI0" enabled="true" first="true"<br>
id="gltf__clockANI0"></timesensor><br>
<orientationinterpolator def="interANI0CH0" key="sampler.input.array"<br>
keyvalue="sampler.output.array" buffer="BoxAnimated0.bin"<br>
id="gltf__interANI0CH0"><br>
<buffergeometryaccessor buffertype="SAMPLER_INPUT" view="2"<br>
byteoffset="0" bytestride="0" components="1" componenttype="5126"<br>
count="2"></buffergeometryaccessor><br>
<buffergeometryaccessor buffertype="SAMPLER_OUTPUT" view="3"<br>
byteoffset="0" bytestride="0" components="4" componenttype="5126"<br>
count="2"></buffergeometryaccessor><br>
<buffergeometryview target="undefined" byteoffset="7760"<br>
bytelength="24" id="gltf__2"></buffergeometryview><br>
<buffergeometryview target="undefined" byteoffset="0"<br>
bytelength="32" id="gltf__3"></buffergeometryview><br>
</orientationinterpolator><br>
<route fromfield="fraction_changed" fromnode="clockANI0"<br>
tofield="set_fraction" tonode="interANI0CH0"></route><br>
<route fromfield="value_changed" fromnode="interANI0CH0"<br>
tofield="set_rotation" tonode="NODE2"></route><br>
<positioninterpolator def="interANI0CH1" key="sampler.input.array"<br>
keyvalue="sampler.output.array" buffer="BoxAnimated0.bin"<br>
id="gltf__interANI0CH1"><br>
<buffergeometryaccessor buffertype="SAMPLER_INPUT" view="2"<br>
byteoffset="8" bytestride="0" components="1" componenttype="5126"<br>
count="4"></buffergeometryaccessor><br>
<buffergeometryaccessor buffertype="SAMPLER_OUTPUT" view="4"<br>
byteoffset="0" bytestride="0" components="3" componenttype="5126"<br>
count="4"></buffergeometryaccessor><br>
<buffergeometryview target="undefined" byteoffset="7760"<br>
bytelength="24" id="gltf__2"></buffergeometryview><br>
<buffergeometryview target="undefined" byteoffset="32"<br>
bytelength="48" id="gltf__4"></buffergeometryview><br>
</positioninterpolator><br>
<route fromfield="fraction_changed" fromnode="clockANI0"<br>
tofield="set_fraction" tonode="interANI0CH1"></route><br>
<route fromfield="value_changed" fromnode="interANI0CH1"<br>
tofield="set_translation" tonode="NODE0"></route><br>
<br>
Here, the glTF animation can be faithfully translated to<br>
TimeSensor/Interpolator/ROUTE combos with the addition that the<br>
interpolators take their key and keyValue field values from the binary<br>
buffer accessor nodes as well, if there is a buffer field value.<br>
<br>
For x3dom and perhaps other implementations it seemed most natural to<br>
introduce these binary access nodes for glTF loading and perhaps other<br>
use.<br>
<br>
>From a specification perspective, however, introducing new nodes is<br>
something which needs to be carefully considered and is hard to do<br>
well. For example, it may be more appropriate to introduce new<br>
interpolator nodes rather than extending the existing ones.<br>
<br>
So from a specification perspective it is attractive to not expose how<br>
the glTF scene is actually represented in the X3D scene graph and<br>
essentially keep it a black box. The spec. language could then even<br>
boil down to allowing glTF content and only referring to glTF to how<br>
the content should be rendered and animated. Implementation are then<br>
of course still free to use internal nodes and potentially expose them<br>
but in a non-standardized way.<br>
<br>
But most glTF features do not require new X3D nodes to be represented<br>
in the scene graph, and an ability to import those is very useful,<br>
probably expected by authors and not too hard to implement since all<br>
pieces are already in place. From a specification perspective this<br>
ability then would need to be very well defined, again requiring<br>
careful selection of what can be imported and how. Other formats such<br>
jpeg or nrrd, though simpler, are already referenced in the spec., so<br>
I think it may be possible for the spec. to be precise on how certain<br>
glTF features get absorbed into a X3D scene.<br>
<br>
For example, glTF "nodes" can be directly represented by named X3D<br>
Transform nodes, and glTF cameras by X3D Viewpoint nodes. The exported<br>
DEF names could be the glTF names (perhaps with a prefix) where<br>
provided or a unique constructed name using the index from the glTF<br>
('gltfTRANFORM_0') where not provided.<br>
<br>
Perhaps that is all which could be required in a spec. in terms of<br>
interplay between glTF and X3D.<br>
<br>
It is less clear how glTF animations should be required to be absorbed<br>
into X3D from a spec perspective. One approach is as shown which<br>
requires a named TimeSensor for each animation (which can target<br>
different channels in glTF). The DEF name would be after the index in<br>
the glTF animations array ('gltfCLOCK_0'). But implementations may<br>
choose to not use a TimeSensor/Interpolator/Route combo and use a more<br>
direct approach. I suppose then still a virtual TimeSensor could be<br>
required to be exported to provide an interface for the animation.<br>
<br>
If PhysicalMaterial gets picked up by X3D, it would become the node to<br>
represent the glTF material, also named after the index<br>
('gltfMaterial_0').<br>
<br>
I hope to find the time and strength at some point to compare glTF<br>
skinned skeleton animation with HAnim animation. I think they are<br>
largely compatible.<br>
<br>
-Andreas<br>
<br>
On Thu, Nov 22, 2018 at 5:52 AM Michalis Kamburelis<br>
<<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> Good discussion :) Some notes from my point of view:<br>
><br>
> 1. I agree with Leonard that "unpacking" all glTF meshes (expressed in<br>
> glTF in a format very efficient to deliver to GPU) into X3D<br>
> IndexedFaceSet is not the optimal way of using glTF. The optimal way<br>
> of integrating glTF into anything (including X3D) is to use the glTF<br>
> mesh data in the format it is provided, and pass it straight to GPU<br>
> (without transforming it, e.g. changing interleaved into<br>
> non-interleaved).<br>
><br>
> That said, I think we should enable this by introducing new X3D<br>
> nodes able to express the same things that glTF allows (e.g. mesh data<br>
> can be in a binary file, vertex and texture coords can be interleaved<br>
> etc.). I guess that this is similar to "BufferGeometry" in X3DOM<br>
> mentioned by Andreas.<br>
><br>
> My goal is to be able to have 100% of the scene graph expressed<br>
> using X3D nodes. And I want to load this scene graph from X3D files,<br>
> glTF files, or a variety of other formats (<br>
> <a href="https://castle-engine.io/x3d_extensions.php#section_ext_inline_for_all" rel="noreferrer" target="_blank">https://castle-engine.io/x3d_extensions.php#section_ext_inline_for_all</a><br>
> - in CGE we load already Collada, 3DS, MD3, Wavefront, Spine JSON and<br>
> some more into X3D scene graph ).<br>
><br>
> IOW, I would not like to see "glTF model" to be a "black box"<br>
> inside X3D scene, where whole glTF content lives as something<br>
> unrelated to the X3D scene graph. This would be bad for developers<br>
> using my engine, and for implementation of my engine too: in both<br>
> cases, we now enjoy the flexibility/power/simplicity coming from the<br>
> fact that *everything* rendered in 3D world is a X3D scene graph.<br>
><br>
> 2. I'm not sure whether glTF is an ""archive format"", but I know it<br>
> is a good asset interchange format. It's a precise specification.<br>
> Although the mesh data is provided in a GPU-friendly format (binary,<br>
> with interleaving etc.), but it is clearly specified how does this<br>
> format look like, and you can always unpack and transform this mesh<br>
> data on CPU, convert it to other formats and so on.<br>
><br>
> And as a practical matter, Blender->glTF 2.0 exporter is simply<br>
> better than Blender->X3D exporter, e.g. because it supports<br>
> animations. For purely practical reasons, this makes glTF 2.0 a better<br>
> interchange format right now. Blender->X3D exporter doesn't get as<br>
> much development.<br>
><br>
> ( In Castle Game Engine, we have a slightly extended X3D exporter,<br>
> and a way to export animations to castle-anim-frames which is really<br>
> just a series of X3D files:<br>
> <a href="https://castle-engine.io/creating_data_blender.php" rel="noreferrer" target="_blank">https://castle-engine.io/creating_data_blender.php</a> . However,<br>
> integrating glTF animations (as X3D nodes!) would be much more<br>
> efficient than our castle-anim-frames. )<br>
><br>
> 3. As for skinned animations, I believe that H-Anim is not limited to<br>
> humanoid animation. In my eyes, it would be better if it was called<br>
> "skinned animation" than "humanoid animation", and the node<br>
> "HAnimHumanoid" could be called "AnimatedModel" or something like<br>
> that.<br>
><br>
> The specification doesn't limit H-Anim use to humanoids, and (from<br>
> earlier threads on x3d-public) it was not intended to be limited to<br>
> humanoids. I think that H-Anim capabilities are good, it's just an<br>
> unfortunate naming, suggesting that it's tied to humanoids.<br>
><br>
> However, I do not have good knowledge of glTF animation<br>
> capabilities. I cannot say whether H-Anim satisfies everything that<br>
> glTF can express. But if it doesn't, my solution (and reason for it)<br>
> would be the same as in AD 1: We should extend X3D (with new<br>
> nodes/fields) to make it possible to express glTF functionality using<br>
> X3D nodes.<br>
><br>
> Best regards,<br>
> Michalis<br>
><br>
> Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br>
> ><br>
> > It is true that glTF is designed to easily upload to the GPU. But the<br>
> > fact of the matter is that it is used increasingly as an exchange and<br>
> > asset format (there are many exporters and importers). It is also the<br>
> > case that many/most importers translate glTF into their native data<br>
> > structures first, due to convenience (three.js does that, for example)<br>
> > before uploading to the GPU. x3dom added a BufferGeometry X3D node for<br>
> > that purpose which is a thin wrapper around the glTF mesh geometry. It<br>
> > is not too hard to import into X3D since there are X3D nodes<br>
> > equivalent to most glTF features (perhaps except for<br>
> > skinning/morphing). The ability of glTF to act as a library without<br>
> > rendering is actually advertised by Khronos. I think many of the glTF<br>
> > creators would now hesitate to call it the jpeg of 3d although they<br>
> > still do since it is such a good line. It has become larger than that.<br>
> > <a href="https://www.khronos.org/assets/uploads/developers/library/2018-webinar-gltf-2/Webinar-glTF-2-Status-and-Outlook_Jul18.pdf" rel="noreferrer" target="_blank">https://www.khronos.org/assets/uploads/developers/library/2018-webinar-gltf-2/Webinar-glTF-2-Status-and-Outlook_Jul18.pdf</a><br>
> > is a good status report. It is interesting how the outlook makes it<br>
> > more similar to X3D (lights, sound, events, arbitrary animations).<br>
> > glTF 2.0 will not change. It is a standard (with rough edges). There<br>
> > will be a glTF 3.0 at some point but nobody is interested in<br>
> > disrupting the ecosystem hugely.<br>
> > Many glTF examples have hard to understand animations due to<br>
> > collada2gltf and other automated conversions:<br>
> > <a href="https://github.com/KhronosGroup/glTF/issues/1052" rel="noreferrer" target="_blank">https://github.com/KhronosGroup/glTF/issues/1052</a><br>
> > Yes, three.js can control the named animations, but only after<br>
> > importing them into its own animation system. It would be necessary to<br>
> > have an equivalent mechanism for X3D which probably requires some<br>
> > importing.<br>
> > Here is an animated glTF loaded into x3dom which only uses trafo<br>
> > animation (no sknning/morphing):<br>
> ><br>
> > <a href="https://raw.githack.com/andreasplesch/x3dom/glTF2TSAP-test/test/functional/inline-gltf.html" rel="noreferrer" target="_blank">https://raw.githack.com/andreasplesch/x3dom/glTF2TSAP-test/test/functional/inline-gltf.html</a><br>
> ><br>
> > If you look inside the Inline node in the devtools, you can see all<br>
> > the TimeSensor/Route/Interpolator combos which could be then<br>
> > controlled. It would be possible to add a control GUI, for example.<br>
> ><br>
> > As a first support level, one could ignore animations, and only import<br>
> > cameras. The glTF scene otherwise is just equivalent to an inert Shape<br>
> > under the grouping Inline.<br>
> > As a full support level, one could expose everything under a name space.<br>
> > Intermediate levels could mean importing cameras and being able to<br>
> > control (start/stop) animations tied to their targets but not the<br>
> > targets/nodes themselves.<br>
> ><br>
> > -Andreas<br>
> ><br>
> > > Date: Tue, 20 Nov 2018 07:58:29 -0800<br>
> > > From: Leonard Daly <<a href="mailto:Leonard.Daly@realism.com" target="_blank">Leonard.Daly@realism.com</a>><br>
> > > To: <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
> > > Subject: Re: [x3d-public] glTF Importing [was: X3D working group<br>
> > > meeting minutes16 NOV 2018]<br>
> > > Message-ID: <<a href="mailto:f345230f-01bc-9211-3bbb-b4e301ec41cc@realism.com" target="_blank">f345230f-01bc-9211-3bbb-b4e301ec41cc@realism.com</a>><br>
> > > Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
> > ><br>
> > > It seems to me that importing glTF defeats the entire purpose of glTF.<br>
> > > It is optimized to deliver data to the graphics card. An attempt to<br>
> > > import that data into X3D not only looses all of the optimization, it<br>
> > > adds overhead converting into the player's X3D data structure, then back<br>
> > > to the graphics card calls. Also, as others have pointed out, there is<br>
> > > no reason that glTF would be an archive format. It may change as<br>
> > > graphics cards change. That would require the specification and player<br>
> > > to track the changes and make the necessary adjustments.<br>
> > ><br>
> > > glTF animations are potentially full skin animations (weighted and moved<br>
> > > according to bone). These are not necessary H-Anim type models (they may<br>
> > > be trees, mechanical parts, etc.). That would need to be implemented<br>
> > > highly efficiently in X3D before this would work. There are ways to<br>
> > > control animation. I'll get to that below.<br>
> > ><br>
> > > It seems to me that it is much better to use glTF as it was designed --<br>
> > > import everything into the graphics card. It was the developer's choice<br>
> > > to use that glTF file. Trying to give an X3D player control over all<br>
> > > aspects of the file is the 3D equivalent of trying to give an X3D player<br>
> > > control of individual pixels in an imported image.<br>
> > ><br>
> > > glTF animations are named; however, there is nothing that requires the<br>
> > > names to be anything useful. A named animation may not even be a<br>
> > > complete motion. For example. the glTF monster (it's in the repository)<br>
> > > has over 20 named animations. All contribute to the full motion cycle of<br>
> > > the monsters. Individual animations are things like the tail motion, or<br>
> > > the movement of the right front foot. It is possible to identify<br>
> > > animations (by name) that are needed for any particular effect and<br>
> > > control them on a frame-by-frame basis. I don't know all of the details,<br>
> > > but it is available in THREE.js so it can be implemented.<br>
> > ><br>
> > > Leonard Daly<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > > Added note to glTF lights below:<br>
> > > ><br>
> > > > On Tue, Nov 20, 2018 at 1:23 AM Andreas Plesch<br>
> > > > <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a> <mailto:<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>>> wrote:<br>
> > > ><br>
> > > > ad point clouds:<br>
> > > ><br>
> > > > massive, lighted point clouds should be possible to implement in<br>
> > > > x3dom/x_ITE as webgl shaders exist. But still significant<br>
> > > > investment in resources/time.<br>
> > > ><br>
> > > > ad glTF inline:<br>
> > > ><br>
> > > > EXPORT/IMPORT: I would favor default exporting/importing of all<br>
> > > > glTF nodes as equivalent X3D nodes using their glTF names or index<br>
> > > > as DEF names, probably under an inline provided namespace name as<br>
> > > > prefix.<br>
> > > ><br>
> > > > Scenes: a glTF without a scene but just a collection of nodes is<br>
> > > > valid. Since the scene graph is then incomplete, it is required<br>
> > > > not to be rendered. It can be used as a library of resources to be<br>
> > > > included somewhere else in the X3D. This way a by default imported<br>
> > > > glTF which only contains a material can be used in a Shape node's<br>
> > > > material field. Referencing a geometry is trickier since in glTF<br>
> > > > geometries do not have a name or an index. They are part of a mesh<br>
> > > > (Shape in X3D). So 'mesh_1' could refer to the complete mesh as a<br>
> > > > Shape, and 'meshgeometry_1' or just 'geometry_1' to just the<br>
> > > > geometry of mesh_1.<br>
> > > > A single glTF can contain multiple scenes although I have not seen<br>
> > > > one. X3D could just bail and say undefined, or always render the<br>
> > > > first one only.<br>
> > > ><br>
> > > > Cameras: almost 1:1 mappable to Viewpoint, except for near/far<br>
> > > > which correspond to NavigationInfo fields. As such added to<br>
> > > > Viewpoint list and stack.<br>
> > > ><br>
> > > > Animations: can be mapped to TimeSensor/Interpolator/Route combos.<br>
> > > > But glTF does not define when an animation begins playing. It is<br>
> > > > expected that after import the player/app decides that. Most glTF<br>
> > > > viewer just start playing all animations after loading. Control in<br>
> > > > X3D would be via imported TimeSensor.<br>
> > > ><br>
> > > > cubicspline: as mode of interpolator.<br>
> > > ><br>
> > > > Lights: glTF itself does not define lights. A proposed material<br>
> > > > commons extension defines lights but is in limbo.<br>
> > > ><br>
> > > ><br>
> > > > There is now another extension:<br>
> > > > <a href="https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Khronos/KHR_lights_punctual" rel="noreferrer" target="_blank">https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Khronos/KHR_lights_punctual</a><br>
> > > > . It defines point, directional and spot lights, largely compatible<br>
> > > > with X3D lights but has a different recommended attenuation law, and<br>
> > > > required non-rendering/culling beyond the max. distance. The extension<br>
> > > > is supported by the glTF blender exporter. There is no ambient light.<br>
> > > ><br>
> > > ><br>
> > > > PBR material: cannot be mimicked by Blinn-Phong shading and<br>
> > > > requires a different set of parameters. In effect, a new<br>
> > > > PBRMaterial X3D node is needed. Equations for an example shader<br>
> > > > are provided, but not normative. While not included in glTF, image<br>
> > > > based lighting (IBL) is often used in glTF viewers. An<br>
> > > > EnvironmentLight X3D node was proposed.<br>
> > > ><br>
> > > > That became longer than expected. Thanks for reading,<br>
> > > ><br>
> > > > Andreas<br>
> > > > ---<br>
> > > ><br>
> > > ><br>
> > > > Message: 2<br>
> > > > Date: Fri, 16 Nov 2018 18:06:11 +0000<br>
> > > > From: "Brutzman, Donald (Don) (CIV)" <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
> > > > <mailto:<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>>><br>
> > > > To: X3D Graphics public mailing list <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
> > > > <mailto:<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>>><br>
> > > > Subject: [x3d-public] X3D working group meeting minutes16 NOV<br>
> > > > 2018:<br>
> > > > ? ? ? ? X3D Semantic Web, X3Dv4<br>
> > > > Message-ID: <<a href="mailto:d5aaf236-0290-f122-cb15-1dbcc0954f69@nps.edu" target="_blank">d5aaf236-0290-f122-cb15-1dbcc0954f69@nps.edu</a><br>
> > > > <mailto:<a href="mailto:d5aaf236-0290-f122-cb15-1dbcc0954f69@nps.edu" target="_blank">d5aaf236-0290-f122-cb15-1dbcc0954f69@nps.edu</a>>><br>
> > > > Content-Type: text/plain; charset="utf-8"<br>
> > > ><br>
> > > > 0. Attendees: Anita Havele, Michalis Kamburelis, Vince<br>
> > > > Marchetti, Christophe Mouton, Nicholas Polys, Dick Puk and Don<br>
> > > > Brutzman.<br>
> > > > ==============================<br>
> > > > 3. Primary working group goal is X3D version 4.0.<br>
> > > ><br>
> > > > ? ? ? ? X3D Version 4.0 Development<br>
> > > > <a href="http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development" rel="noreferrer" target="_blank">http://www.web3d.org/wiki/index.php/X3D_version_4.0_Development</a><br>
> > > ><br>
> > > > New.? Can we propose certain parts of X3Dv4 as recommended for<br>
> > > > implementation testing by the end of the year?? Our motivation<br>
> > > > is encourage accelerated development of the most important<br>
> > > > capabilities and get them widely available for testing and<br>
> > > > demonstration.? Intended target implementations are X3DOM,<br>
> > > > X_ITE, Castle Game Engine and perhaps others.<br>
> > > ><br>
> > > > Candidates:<br>
> > > ><br>
> > > > a. *3D Printing and Scanning Profile*.? Addition of Point<br>
> > > > size, Point normals, possibly point sprites.? Leonard<br>
> > > > correctly notes that we need to look ASTM E57<br>
> > > > mappability/portability as well. Anything else?<br>
> > > ><br>
> > > > ? ? ? ? Wikipedia E57: A file format developed by ASTM<br>
> > > > International for storing point clouds and images.<br>
> > > ><br>
> > > > ? ? ? ? ASTM Committee E57 on 3D Imaging Systems<br>
> > > > <a href="https://www.astm.org/COMMITTEE/E57.htm" rel="noreferrer" target="_blank">https://www.astm.org/COMMITTEE/E57.htm</a><br>
> > > ><br>
> > > > ? ? ? ? Wikipedia: Point cloud<br>
> > > > <a href="https://en.wikipedia.org/wiki/Point_cloud" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/Point_cloud</a><br>
> > > ><br>
> > > > b. *Inline support for glTF and Physically Based Rendering*.<br>
> > > > -? Michalis notes that required, well-defined glTF lighting<br>
> > > > model implies experimental X3D lighting-model changes that<br>
> > > > correspond to).<br>
> > > > - Vince described how we need to scope this to Shape/mesh<br>
> > > > capabilities, or possibly other glTF capabilities also e.g.<br>
> > > > Camera etc.<br>
> > > ><br>
> > > > c. Others?? *RenderedTexture* might be easy.<br>
> > > ><br>
> > > > <a href="http://www.xj3d.org/extensions/render_texture.html" rel="noreferrer" target="_blank">http://www.xj3d.org/extensions/render_texture.html</a><br>
> > > ><br>
> > > > ? ? ? ? TODO: Michalis will post further information<br>
> > > ><br>
> > > > For CAD Design Printing Scanning group's arena, there is a lot<br>
> > > > of work going on with STEP.? It would be good to consider our<br>
> > > > best strategies for STEP support in 2019: encourage<br>
> > > > translators/import/export?? Best practices? Native support in X3D?<br>
> > > ><br>
> > > > This is a year-end opportunity to prioritize the most feasible<br>
> > > > and valuable next steps for progress.? We would publish and<br>
> > > > prioritize a "short list" of what nodes need to be implemented<br>
> > > > next.<br>
> > > ><br>
> > > > Great discussion today!? Nicholas and Michalis each have blogs<br>
> > > > in preparation for release Real Soon Now (RSN).<br>
> > > ><br>
> > > > We intend to proceed in this direction.? I will need help to<br>
> > > > get this properly proposed publicly by year's end.? Who is<br>
> > > > willing to lead each category?<br>
> > > ><br>
> > > ><br>
> > > > ------------------------------<br>
> > > ><br>
> > > > End of x3d-public Digest, Vol 116, Issue 20<br>
> > > > *******************************************<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > --<br>
> > > > Andreas Plesch<br>
> > > > Waltham, MA 02453<br>
> > > ><br>
> > > ><br>
> > > > _______________________________________________<br>
> > > > x3d-public mailing list<br>
> > > > <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
> > > > <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
> > ><br>
> > ><br>
> > > --<br>
> > > *Leonard Daly*<br>
> > > 3D Systems & Cloud Consultant<br>
> > > LA ACM SIGGRAPH Past Chair<br>
> > > President, Daly Realism - /Creating the Future/<br>
> > > -------------- next part --------------<br>
> > > An HTML attachment was scrubbed...<br>
> > > URL: <<a href="http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20181120/97aa80c2/attachment-0001.html" rel="noreferrer" target="_blank">http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20181120/97aa80c2/attachment-0001.html</a>><br>
> > ><br>
> > > ------------------------------<br>
> > ><br>
> > > Subject: Digest Footer<br>
> > ><br>
> > > _______________________________________________<br>
> > > x3d-public mailing list<br>
> > > <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
> > > <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
> > ><br>
> > ><br>
> > > ------------------------------<br>
> > ><br>
> > > End of x3d-public Digest, Vol 116, Issue 25<br>
> > > *******************************************<br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Andreas Plesch<br>
> > Waltham, MA 02453<br>
> ><br>
> > _______________________________________________<br>
> > x3d-public mailing list<br>
> > <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
> > <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
<br>
<br>
<br>
-- <br>
Andreas Plesch<br>
Waltham, MA 02453<br>
<br>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div></div>
</div>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Nicholas F. Polys, Ph.D.<br><br>Director of Visual Computing <br>Virginia Tech Research Computing <br><br>Affiliate Professor<br>Virginia Tech Department of Computer Science<br></div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Nicholas F. Polys, Ph.D.<br><br>Director of Visual Computing <br>Virginia Tech Research Computing <br><br>Affiliate Professor<br>Virginia Tech Department of Computer Science<br></div>