[x3d-public] Using IMPORT / EXPORT to selectively include parts of glTF file in X3D, and multiply them as much as necessary
GPU Group
gpugroup at gmail.com
Tue Apr 5 09:30:29 PDT 2022
Q. Could Inline have a field
bool exportAll FALSE
and changing to TRUE would automatically export all DEFed nodes in inlined
scene whether from X3D or glTF?
- then rather than explicity EXPORTing each node, IMPORT statement can
check DEF list instead of EXPORT list
Q. could USE allow dotted name notation to avoid IMPORT AS statement:
Shape USE='inlineName.nodeDEFname'
?
On Tue, Apr 5, 2022 at 8:44 AM GPU Group <gpugroup at gmail.com> wrote:
> Looks good - I like it. -Doug
> (PS the ExternProto was an analogy. The syntax looks like this:
> Shape { url='library.gltf#name }
> )
>
> On Mon, Apr 4, 2022 at 8:23 PM Michalis Kamburelis <
> michalis.kambi at gmail.com> wrote:
>
>> ( No real avocados were hurt while generating screenshots for this email
>> :) )
>>
>> I started to write an answer to Doug email "Other ways to use gltf >
>> like ExternProto" and then I realized that I just pursue a different
>> approach, so I may as well create a new thread. The goal is similar:
>> how to get *part* of glTF scene into X3D file? But here I decided to
>> do it using IMPORT / EXPORT + Inline, not ExternProto.
>>
>> I thought that IMPORT / EXPORT may be nice, as IMPORT / EXPORT have an
>> explicit purpose "make something available to the outer scene".
>>
>> So I tried how far can I take it. And implemented it in
>> CGE/view3dscene, and made demos :) You can now use IMPORT / EXPORT to
>> selectively take (and reuse as many times as you wish) parts of inner
>> glTF models inside outer X3D file.
>>
>> 1. Older demo: I have already used this approach for animations in
>> glTF in CGE/view3dsdcene, i.e. I export them from glTF and you can
>> IMPORT and control them. See
>>
>> https://github.com/castle-engine/demo-models/tree/master/blender/skinned_animation
>> , file skinned_anim_run_animations_from_x3d.x3dv does
>>
>> """
>> DEF InlinedAnimations Inline {
>> url "skinned_anim.glb"
>> }
>> IMPORT InlinedAnimations.jump AS jump
>> IMPORT InlinedAnimations.walk AS walk
>> """
>>
>> and then it can start animations jump, walk. They are just TimeSensor
>> nodes in X3D. I can ROUTE events to them.
>>
>> 2. I have now extended this approach to glTF materials (X3D Appearance
>> nodes) and transformation groups and cameras (X3D Viewpoint /
>> OrthoViewpoint nodes). I can export anything named from glTF this way.
>>
>> See
>> https://github.com/michaliskambi/x3d-tests/tree/master/gltf/avocado_and_exports
>> and attached screenshot with scene that can reuse Avocado appearance,
>> or transformation, or mesh.
>>
>> It looks like this:
>>
>> """
>> Switch {
>> children DEF InlinedAvocado Inline {
>> url "glTF/Avocado.gltf"
>> }
>> }
>> IMPORT InlinedAvocado.Avocado_2 AS AvocadoMeshes
>> IMPORT InlinedAvocado.CastleEncoded_2256_Avocado_d AS AvocadoAppearance
>> IMPORT InlinedAvocado.Avocado AS AvocadoTransform
>>
>> Shape {
>> appearance USE AvocadoAppearance
>> geometry IndexedFaceSet { ... }
>> }
>> ...
>> """
>>
>> 3. Why IMPORT / EXPORT? I felt this way there's less extra concepts.
>>
>> A. Do not want to see original glTF? Then place "Inline" inside
>> "Switch".
>>
>> B. Writing "IMPORT" is simpler than ExternProto, no need to repeat
>> the node declaration.
>>
>> 4. To make this work:
>>
>> A. The browser must make sure to generate EXPORT for all named
>> things when importing glTF file.
>>
>> B. The browser must be more tolerant for USE clauses than spec.
>>
>> X3D spec says (
>>
>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-CD1/Part01/components/networking.html#IMPORTStatement
>> ) """Nodes imported into an X3D scene using the IMPORT statement may
>> not be instanced via the USE statement. """. I decided to ignore this
>> limit now in CGE/view3dscene, you can reUSE nodes you get with IMPORT.
>>
>> There seems to be no drawback from this. We only resolve USE
>> looking at IMPORTed names if the name cannot be found in non-imported
>> nodes. And it makes IMPORT / EXPORT much more powerful, also for
>> X3D<->X3D interaction.
>>
>> 5. Note: I'm not really trying to make a case that "IMPORT / EXPORT is
>> a better approach than ExternProto". They both seem reasonable
>> approaches. I just decided to test IMPORT / EXPORT approach to the
>> fullest, and I dabbled with it already in the demo with
>> skinned_anim_run_animations_from_x3d.x3dv .
>>
>> Regards,
>> Michalis
>> _______________________________________________
>> x3d-public mailing list
>> x3d-public at web3d.org
>> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220405/6be6f132/attachment-0001.html>
More information about the x3d-public
mailing list