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