<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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.gmail-m-7026684662938563481msolistparagraph, li.gmail-m-7026684662938563481msolistparagraph, div.gmail-m-7026684662938563481msolistparagraph
{mso-style-name:gmail-m_-7026684662938563481msolistparagraph;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
.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;}
/* List Definitions */
@list l0
{mso-list-id:289094778;
mso-list-type:hybrid;
mso-list-template-ids:-1303743164 -1 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:\F0D8;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;
mso-fareast-font-family:"Times New Roman";
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l1
{mso-list-id:1407727110;
mso-list-template-ids:-1;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style></head><body lang=EN-US link=blue vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Fine work Doug,</p><p class=MsoNormal>In the gltf forms, I can see how the data forms were structured for direct use at run time according to some typical best practice style for simple transport without giving up the farm easily. From your description and experience, then I would certainly advocate for a new field name to specify the primitive properties using gltf buffer style. </p><p class=MsoNormal><o:p> </o:p></p><ul style='margin-top:0in' type=disc><li class=MsoListParagraph style='margin-left:0in;mso-list:l0 level1 lfo2'>I parse the whole gltf scene to web3d nodes, except for the geometry going to BufferGeometry which I pretend is a web3d node.</li></ul><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Nice workaround, and can show it works, but is this just a bit too simple? All of a sudden the Shape includes lots of other nodes that don’t match the spec for an x3d Shape node. </p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Like you see for others, the gltf asset may include data for various fields of several x3d nodes and data that does not correspond to any existing field(s) of any x3d node. I think of the fact that at least in x3d Hanim a skin is the same as in gltf, but further that the x3d lists the vertices and weights by joint while the gltf style butters end up as weights per vertex. Not only entirely different (but derivable from x3d code) but some connection with the original actuating skeleton might have been lost? However, should there be an Hanim extension that allows this style of data import instead of existing Hanim markup? </p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks Again, </p><p class=MsoNormal>Joe</p><p class=MsoNormal><o:p> </o:p></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:gpugroup@gmail.com">GPU Group</a><br><b>Sent: </b>Tuesday, April 5, 2022 10:42 AM<br><b>To: </b><a href="mailto:x3d-public@web3d.org">X3D Graphics public mailing list</a><br><b>Subject: </b>Re: [x3d-public] Using IMPORT / EXPORT to selectively includepartsof glTF file in X3D, and multiply them as much as necessary</p></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Good questions Joe. I struggled recently to refactor old (freewrl) browser code to better parse and use glTF more efficiently A strange thing: glTF likes everything in one giant scene buffer blob, with nodes sharing the same blob buffer, and there being offset, stride, datatype, number of components) for each array (aka vertex attribute / index). </p><div><p class=MsoNormal>- so I refactored a bit of old code to use that technique - sharable buffer (although going through x3d nodes they aren't shared, just one buffer per node), and accessor/bufferView</p></div><div><p class=MsoNormal>- then re-did gltf parsing code so it used those accessor/bufferView and blob buffer techniques.</p></div><div><p class=MsoNormal>- What I found: the specific geometry node types we have like IFS aren't necessary. You can skip those and do a new node type that has _no_ fields. Just the (hidden/internal) accessor/bufferviews and buffer. (Could/should there be a <a href="http://web3d.org">web3d.org</a> official name? I think someone said x3dom uses Buffer. I'm using BufferGeometry.)</p></div><div><p class=MsoNormal>Could it be done through IFS? Yes but that was the long inefficient way I was trying to fix.</p></div><div><p class=MsoNormal>Ideally I'd finish fixing old code so all x3d geometry nodes resolve (after parsing, initializing/compiling) to some internal code and structure that looks like what I'm doing with BufferGeometry.</p></div><div><p class=MsoNormal>Back to the question Shape url='' and defining it carefully. I parse the whole gltf scene to web3d nodes, except for the geometry going to BufferGeometry which I pretend is a web3d node. So there are shapes, materials, punctual lights that map well. For geometry - no. You'd need to instance it at the Shape level in the main scene, to avoid having to say an illegal node type BufferGeometry {url='library.gltf#name'}. A true gotcha.</p></div><div><p class=MsoNormal>-Doug</p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Tue, Apr 5, 2022 at 11:12 AM Joseph D Williams <<a href="mailto:joedwil@earthlink.net">joedwil@earthlink.net</a>> wrote:</p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><ul type=disc><li class=gmail-m-7026684662938563481msolistparagraph style='mso-list:l1 level1 lfo1'>Shape { url='library.gltf#name }</li></ul><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Great, just so amazing that it looks so direct to import, a set of data. The critical part is that this needs to be carefully defined. This can be used only where it can be shown that the gltf file contains only data exactly equivalent to the content defined by the x3d standard for some Shape. Why not more like:</p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><IndexedFaceSet DEF='sternum_Geo' url='library.gltf#joe_sternum’ /></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>That would be easier to map the named fields from the gltf file to the equivalent fields of an x3d node in x3d user code. In the end the standard will (I think) have to state that x3d can use certain ‘standard’ json-encoded gltf files that conform to Standard gltf JSON-Schema documentation. And, importantly, defining which of the gltf named fields are used directly, or converted, to construct the equivalent x3d nodes and fields. </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Even better, in terms of validation, by requiring the naming of the top level gltf asset schema directly. For example </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><IndexedFaceSet DEF='sternum_Geo' url='node.library.gltf#joe_sternum’ /></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>So in this case it could be verified that the gltf node asset contains specific data to produce the IFS. </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Is it possible to deal with how to for general use author-defined json-encoded files for any field of any node?</p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><IndexedFaceSet DEF='sternum_Geo' … </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <Coordinate DEF='lfemur_Coord' point=”url-</p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>url=’point.json’ </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>,,, /></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Thanks for these breakthrough implementation steps for using gltf standard stuffs in x3d.</p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Joe</p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>From: </b><a href="mailto:gpugroup@gmail.com" target="_blank">GPU Group</a><br><b>Sent: </b>Tuesday, April 5, 2022 7:45 AM<br><b>To: </b><a href="mailto:x3d-public@web3d.org" target="_blank">X3D Graphics public mailing list</a><br><b>Subject: </b>Re: [x3d-public] Using IMPORT / EXPORT to selectively include partsof glTF file in X3D, and multiply them as much as necessary</p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Looks good - I like it. -Doug</p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>(PS the ExternProto was an analogy. The syntax looks like this:</p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Shape { url='library.gltf#name }</p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>)</p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> </p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Mon, Apr 4, 2022 at 8:23 PM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a>> wrote:</p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:4.8pt'>( No real avocados were hurt while generating screenshots for this email :) )<br><br>I started to write an answer to Doug email "Other ways to use gltf ><br>like ExternProto" and then I realized that I just pursue a different<br>approach, so I may as well create a new thread. The goal is similar:<br>how to get *part* of glTF scene into X3D file? But here I decided to<br>do it using IMPORT / EXPORT + Inline, not ExternProto.<br><br>I thought that IMPORT / EXPORT may be nice, as IMPORT / EXPORT have an<br>explicit purpose "make something available to the outer scene".<br><br>So I tried how far can I take it. And implemented it in<br>CGE/view3dscene, and made demos :) You can now use IMPORT / EXPORT to<br>selectively take (and reuse as many times as you wish) parts of inner<br>glTF models inside outer X3D file.<br><br>1. Older demo: I have already used this approach for animations in<br>glTF in CGE/view3dsdcene, i.e. I export them from glTF and you can<br>IMPORT and control them. See<br><a href="https://github.com/castle-engine/demo-models/tree/master/blender/skinned_animation" target="_blank">https://github.com/castle-engine/demo-models/tree/master/blender/skinned_animation</a><br>, file skinned_anim_run_animations_from_x3d.x3dv does<br><br>"""<br>DEF InlinedAnimations Inline {<br> url "skinned_anim.glb"<br>}<br>IMPORT InlinedAnimations.jump AS jump<br>IMPORT InlinedAnimations.walk AS walk<br>"""<br><br>and then it can start animations jump, walk. They are just TimeSensor<br>nodes in X3D. I can ROUTE events to them.<br><br>2. I have now extended this approach to glTF materials (X3D Appearance<br>nodes) and transformation groups and cameras (X3D Viewpoint /<br>OrthoViewpoint nodes). I can export anything named from glTF this way.<br><br>See <a href="https://github.com/michaliskambi/x3d-tests/tree/master/gltf/avocado_and_exports" target="_blank">https://github.com/michaliskambi/x3d-tests/tree/master/gltf/avocado_and_exports</a><br>and attached screenshot with scene that can reuse Avocado appearance,<br>or transformation, or mesh.<br><br>It looks like this:<br><br>"""<br>Switch {<br> children DEF InlinedAvocado Inline {<br> url "glTF/Avocado.gltf"<br> }<br>}<br>IMPORT InlinedAvocado.Avocado_2 AS AvocadoMeshes<br>IMPORT InlinedAvocado.CastleEncoded_2256_Avocado_d AS AvocadoAppearance<br>IMPORT InlinedAvocado.Avocado AS AvocadoTransform<br><br>Shape {<br> appearance USE AvocadoAppearance<br> geometry IndexedFaceSet { ... }<br>}<br>...<br>"""<br><br>3. Why IMPORT / EXPORT? I felt this way there's less extra concepts.<br><br> A. Do not want to see original glTF? Then place "Inline" inside "Switch".<br><br> B. Writing "IMPORT" is simpler than ExternProto, no need to repeat<br>the node declaration.<br><br>4. To make this work:<br><br> A. The browser must make sure to generate EXPORT for all named<br>things when importing glTF file.<br><br> B. The browser must be more tolerant for USE clauses than spec.<br><br> X3D spec says (<br><a href="https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/networking.html#IMPORTStatement" target="_blank">https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/networking.html#IMPORTStatement</a><br>) """Nodes imported into an X3D scene using the IMPORT statement may<br>not be instanced via the USE statement. """. I decided to ignore this<br>limit now in CGE/view3dscene, you can reUSE nodes you get with IMPORT.<br><br> There seems to be no drawback from this. We only resolve USE<br>looking at IMPORTed names if the name cannot be found in non-imported<br>nodes. And it makes IMPORT / EXPORT much more powerful, also for<br>X3D<->X3D interaction.<br><br>5. Note: I'm not really trying to make a case that "IMPORT / EXPORT is<br>a better approach than ExternProto". They both seem reasonable<br>approaches. I just decided to test IMPORT / EXPORT approach to the<br>fullest, and I dabbled with it already in the demo with<br>skinned_anim_run_animations_from_x3d.x3dv .<br><br>Regards,<br>Michalis<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" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a></p></div></div></blockquote></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;margin-left:4.8pt'> </p><p class=MsoNormal><o:p> </o:p></p></div></body></html>