[x3d-public] gltf for Humanoid loa4 level 1

John Carlson yottzumm at gmail.com
Tue Jul 30 17:29:40 PDT 2024


Joe, we’ve discussed how Blender conversions of animation in X3D to glTF
get played in various X3D browsers.  Feel free to import as VRM [ sic ] and
export as glTF.  Feel free to import as BVH and export as glTF.

Vince has tried to get X3D meshes converted to glTF with a stylesheet.

We’re kind of waiting on the folks who do conversions from X3D to STL to
produce X3D to glTF.  Triangles and transforms are not an HAnim solution.

Using the OOTB blender x3d importer is a non-starter since it doesn’t
import HAnim.  This might change, but I’m not seeing Blender people wanting
to help with X3D.

There may be other Blender importers.

There may be online X3D to glTF converters.

glTF interactivity extension may be right around the corner.

Perhaps a next step is to provide an HAnim to glTF mapping.

On Tue, Jul 30, 2024 at 6:57 PM Joe D Williams via x3d-public <
x3d-public at web3d.org> wrote:

>
>
> https://github.khronos.org/glTF-Tutorials/gltfTutorial/gltfTutorial_002_BasicGltfStructure.html
>
> gives some example tutorials with some user code. Even shows skinning with
> a simple set of rotation transforms.
> At least gltf is down to it and doesn't mind calling a joint a joint as
> the primary animation driver.
>
> Image 2a: The glTF JSON structure
>
> and following summary of elements text shows x3d we have everything needed
> to transcode hanim skeleton(s), geometries, and animations from x3d hanim
> to gltf and back. Well, not quite transcoding, because some level of
> relatively simple computational text name and value transformations might
> be needed to match x3d native xml nodes and fields to native gltf node and
> field names and content.
>
> This is to be expected, because x3d hanim nodes and fields and SAI are
> meant to be best authortime in terms of basic human-readable syntax,
> hierarchies, data stuffing, and realtime event processing, while the gltf
> has no 'runtime' or event system of any kind that I have seen. So our gltf
> oriented more toward the idea that the x3d hanim authortime has made it
> possible to simply reorganize or even precompute gltf data structures and
> elements for best transport and to optimize realtime delivery by the
> expected host runtime.
> Or, even transport to another gltf or x3d authortime.
> In fact the interchangability of using basic standard native gltf assets
> integrated with x3d native assets in a 'live' x3d authortime is handled
> just fine using standard x3d SAI.
>
> Image 2b: The glTF structure
>
> Gives a bit more detail about how a set of assets, even a single file of
> multiple embedded or in local or remote files of assets can be documented.
> Again, the basic is the 'scene' and it is composed of strongly typed but
> very versatile nodes and fields, some represented as buffers that appear to
> have few default definitions, but can be derived by the x3d definition of
> its SF form and content. So, for a gltf source collection of names and
> data, by the time it gets to the gltf it better be ready to execute without
> much ado. That is why x3d xml schema validation of the original input can
> be important and that comparable schema validation for the gltf json form
> be developed to the same degree.
>
> On and on through the tutorial and we see that like I said, there appear
> to be few defaults, like gltf may not be aware or types like MFvect3F, you
> must tell the name and parameter and how to interpret and access the data
> structure for every element. However, we are happy to see some familiar
> names for things like skin and joints
>
> Not to worry because the x3d native data, or data the live browser runtime
> would have to compute anyway for data is very well known and literally
> every standardized gltf asset definition is covered by x3d node and data
> types.
>
> Has anyone tried a conversion of an example hanim model into a single or
> set of gltf asset files?
> Attached is most simple loa4 with small geometry and basically just the
> skeleton Joint, Segment, Site nodes and measurements.
> We need an loa4 because lower loas can be easily found by reduction.
>
> The top reason for HAnim is transportable animations. The gltf can
> accommodate and even accelerate this good thing. It providing a very
> condensed form for a 'standard' skeleton hierarchy with realistic and
> custom dimensions then import realistic 'standard' and custom animations
> (learn unit quaternions, not hard just something about cosines and half
> angles and square roots?) along with geometry and behaviour accessories
> faster and easier and more reliably for interactive operations in a
> 'standard' time and event-driven virtualized environment.
>
>
> please note: "The local transform matrix always has to be computed as M =
> T * R * S."
> also see:
> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/components/grouping.html#Transform
>
> If you want to know about x3d hanim Displacers, check out gltf sparse
> accessors.
>
>
> https://github.khronos.org/glTF-Tutorials/gltfTutorial/gltfTutorial_007_Animations.html
>
> Some artifacts move around using the basic stuff of x3d. True, it is like
> gltf is made for convenient use by x3d and www.
> Because it is.
>
> Thanks and Best,
> Joe
>
>
>
> . le
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> 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/20240730/5ddc7536/attachment-0001.html>


More information about the x3d-public mailing list