<div dir="ltr">Looks good - I like it. -Doug<div>(PS the ExternProto was an analogy. The syntax looks like this:</div><div>Shape { url='library.gltf#name }</div><div>)</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 4, 2022 at 8:23 PM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com">michalis.kambi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">( 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" rel="noreferrer" 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" rel="noreferrer" 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" rel="noreferrer" 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" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div>