[x3d-public] gltf for Humanoid loa4 level 1

[John Carlson]

I do think it’s a goal of the MSF to create a lingua-franca for
conversions.  I do think X3D is probably the best open-source lingua-franca
 out there which includes humans.  Probably COLLADA is a close second, but
I’ve not investigated it much.

Perhaps X3D is the C of graphics, and everyone keeps trying to beat it and
fails.  Popularity does not mean success.  Standardization doesn’t always
mean success.  Engineering and design mean success.  Human-oriented
engineering and design is best for humans.   Read Donald Norman.

glTF may be the JPEG of graphics, but I’d rather have something lossless.

If anyone wants to tell me how to easily turn on all animations when
viewing a glTF, that would be impressive!  Say I have 146 animations which
are supposed to play concurrently (one for each joint).

John

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/a1ccbc89/attachment-0001.html>