[x3d-public] Using IMPORT / EXPORT to selectively include partsof glTF file in X3D, and multiply them as much as necessary

[John Carlson]

How is shared buffer different from DEF/USE?

John

On Tue, Apr 5, 2022 at 12:42 PM GPU Group <gpugroup at gmail.com> wrote:

> 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).
> - 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
> - then re-did gltf parsing code so it used those accessor/bufferView and
> blob buffer techniques.
> - 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 web3d.org official name? I think someone said x3dom uses
> Buffer. I'm using BufferGeometry.)
> Could it be done through IFS? Yes but that was the long inefficient way I
> was trying to fix.
> 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.
> 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.
> -Doug
>
>
> On Tue, Apr 5, 2022 at 11:12 AM Joseph D Williams <joedwil at earthlink.net>
> wrote:
>
>>
>>    - Shape { url='library.gltf#name }
>>
>>
>>
>> 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:
>>
>>
>>
>> <IndexedFaceSet DEF='sternum_Geo' url='library.gltf#joe_sternum’ />
>>
>>
>>
>> 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.
>>
>> Even better, in terms of validation, by requiring the naming of the top
>> level gltf asset schema directly. For example
>>
>>
>>
>> <IndexedFaceSet DEF='sternum_Geo' url='node.library.gltf#joe_sternum’ />
>>
>>
>>
>> So in this case it could be verified that the gltf node asset contains
>> specific data to produce the IFS.
>>
>>
>>
>> Is it possible to deal with how to for general use author-defined
>> json-encoded files for any field of any node?
>>
>>
>>
>> <IndexedFaceSet DEF='sternum_Geo' …
>>
>>    <Coordinate DEF='lfemur_Coord' point=”url-
>>
>> url=’point.json’
>>
>> ,,, />
>>
>>
>>
>> Thanks for these breakthrough implementation steps for using gltf
>> standard stuffs in x3d.
>>
>> Joe
>>
>>
>>
>>
>>
>> *From: *GPU Group <gpugroup at gmail.com>
>> *Sent: *Tuesday, April 5, 2022 7:45 AM
>> *To: *X3D Graphics public mailing list <x3d-public at web3d.org>
>> *Subject: *Re: [x3d-public] Using IMPORT / EXPORT to selectively include
>> partsof glTF file in X3D, and multiply them as much as necessary
>>
>>
>>
>> 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
>>
>>
>>
> _______________________________________________
> 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/c19c2869/attachment-0001.html>