[x3d-public] PBR in X3D4 using glTF and import as Inline

Thu Mar 31 17:31:56 PDT 2022

OK, I will study more.  

➢ Of course you can animate bones at runtime and have them affect
the skin correctly in glTF.

Yes, it is important to provide a ‘standard’ skeleton hierarchy, with a ‘standard’ skin, with ‘standard’ surface feature site/sensor/viewpoint locations, with ‘standard’ skin vertex bindings and weights, along with ‘standard’ transportable realistic animations and interactions, (which is the point of the entire Hanim effort). 

➢ your general opinion is that "H-Anim is a better
solution than glTF skinned animation".

It is important to follow the spec motion system where skeleton-driven and Displacer-driven mesh animations are accumulated per frame. Level 1 hanim does not consider a deformable skin, only segment geometry. How to add deformable skin that is under control of joints and displacers to that model so the browser has truly level 2 hanim? That is the (set of) gltf files we need for x3d hanim, finally.
It is important that this information be presented in form where the skeleton joint center locations and hierarchy can be modified, the skin vertex base locations changed, surface feature treatments changed, and conserved, in short, to be transportable to some ‘standard’ environments, like geo and other human-scale simulations. 

➢ You mention 3dsMax as

Just sayin’ that when you find the primate, or human button, it gives you close to Hanim loa2. Believe me, they were there when HAnim was born. 

Thanks Again, your advancements are welcome and would really help to further define gltf nodes with respect to x3d Hanim.
JOe

From: Michalis Kamburelis
Sent: Thursday, March 31, 2022 2:51 PM
To: Joseph D Williams
Cc: X3D Graphics public mailing list
Subject: Re: [x3d-public] PBR in X3D4 using glTF and import as Inline

Joe,

You focused on the "Skinned mesh animation" section (
https://github.com/michaliskambi/x3d-tests/wiki/Converting-glTF-to-X3D#skinned-mesh-animation
) and I understand your general opinion is that "H-Anim is a better
solution than glTF skinned animation".

I'm a bit hesitant to write this, as I understand this can turn into a
heated debate, but I have to say I disagree. That is, IMO glTF
approach to skinned animations is (for me, for my use-case) much
better than H-Anim in X3D.

Reasons:

1. glTF skinned animation has much simpler spec. And it still gives me
all the power I expect from a skinned animation system (to express
skinned animation, to play a prepared animation or to modify bones in
any other way at runtime e.g. for inverse kinematics at runtime).
Skinned animation is just a regular section within glTF spec. This is
much simpler than H-Anim spec attached to even larger X3D spec.

2. glTF skinned animation has obvious efficient implementation on GPU.
glTF skinned animation can be explained in just 1.5 pages, on
https://www.khronos.org/files/gltf20-reference-guide.pdf , and the
efficient implementation of it is obvious.

3. glTF has much wider adoption in practice than X3D.

     I understand that this may depend on your use-case, or where one
is looking at. Of course there are communities focused on X3D, just
like communities focused on glTF.

     But, from my point of view (making CGE game engine, making games
in both CGE and Unity and Unreal Engine, making 3D general
visualization) glTF just got more popular and it has more support
across tools.

     E.g. Blender, 3dsMax, Maya, support glTF with animations. They
don't support H-Anim. Most of them (except Blender) don't even support
X3D.

    The authoring software you mention ("BSContact? VIZX3D, xite") has
much smaller user-base. At least in my domain (again, I understand
this may be different for different domains), regular 3D artists don't
even know about them. OTOH every 3D artist knows either Blender or
3dsMax, usually both. It's not just my opinion -- look at the
documentation of Unity, Unreal Engine, or Babylon: they list how to
make models for their engines in Blender, 3dsMax, Maya. They don't
list BSContact etc.

    (You mention 3dsMax as if it supported H-Anim. It doesn't, up to
my knowledge. Latest 3dsMax cannot export to X3D or VRML at all. Older
3dsMax used to be able to export to VRML 97.)

To address the particular points you make about the text on
https://github.com/michaliskambi/x3d-tests/wiki/Converting-glTF-to-X3D#skinned-mesh-animation
:

4. "… For making videos" - No. The approach I describe there works for
real-time 3D animation. Even with cross-fading animations.

    But, as I wrote there explicitly, this is A. just the
implementation of CGE (don't draw conclusions from it about what glTF
can or cannot do), B. I do not think it's the optimal implementation
-- it will change (to make skinned animation on GPU). I explicitly
mention the drawbacks of my implementation on that page.

    In general, that part of the page, saying "In Castle Game Engine
...", describes just that -- the current implementation in CGE, and
I'm open there about the fact that I want to improve it. Don't make
judgements about glTF skinned animation spec based on it.

5. "So, the gltf folks aren’t telling us how they recommend to setup a
gltf file for realtime skeleton-driven skin animations?"

    Of course they do. You seem to misunderstood that part of the
page. It just describes current CGE implementation and the drawbacks
of it. Of course you can animate bones at runtime and have them affect
the skin correctly in glTF.

Regards,
Michalis

czw., 31 mar 2022 o 21:47 Joseph D Williams <joedwil at earthlink.net> napisał(a):
>
> TODO. Work in-progress.
>
> into TimeSensor + CoordinateInterpolator. This means that at runtime, we just do CoordinateInterpolator animation, not skinned mesh animation anymore. This is not the final solution. Although in practice it works very nicely:
>
>
>
> … For making videos
>
>
>
> Still, there are some big drawbacks:
>
> You can no longer transform bones (just Transform nodes) to modify skin at runtime
>
> So, the gltf folks aren’t telling us how they recommend to setup a gltf file for realtime skeleton-driven skin animations? They are only storing data showing something that allows a fixed interpolator displacements for the skin?  Not surprising because the real animations hidden in the delivery of this type of interpolated skin gltf is some of the hardest to develop and stuff most wanted to keep hidden.
>
> I hope all can sidestep this skeleton-driven skin animation deficit of the current gltf and get all browsers doing Hanim. Actual implementation of animation technique designed to produce realltime anytime interactive animation of shapes and skins.
>
> The memory use of long-running animation is significant
>
> Lots better than just outputting complete frames of pixels for the video, which was once the best we could get.
>
> In CGE we have also implemented H-Anim, which is X3D way of doing skinned mesh animation.
>
> I think it is just the x3d way of encoding skeleton-driven skin animations as proven by years of implementations driving this technique for realtime, and really, also the Displacer animations. When this is mastered, I think it will give clues to how to encode a gltf example humanoid. For example, when storing a file for a humanoid using gltf, it might include the matrix at issue that was computed by the author tool and used directly by the runtime tool. Otherwise, doing the level2 skeleton-driven skin animation has always been heavy learning for every x3d browser maker willing to take the step.
>
> To me this also shows that we need to turn this around a bit an develop some gltf tuned for x3d. How much easier it is to read and organize user code when I can just reference a json file to hold data and thus clean up my listing.
>
> If any major 3D authoring software becomes capable of exporting to H-Anim,
>
> BSContact? VIZX3D, xite? 3dsmax? You mean if any major authoring software extends themselves from making videos and moves towards realtime interactive live scenegraph simulations?
>
> Thanks,,
>
> Joe
>
>
>
>
>
>
>
>
>
> From: Michalis Kamburelis
> Sent: Wednesday, March 30, 2022 4:19 PM
> To: Joseph D Williams
> Cc: X3D Graphics public mailing list
> Subject: Re: [x3d-public] PBR in X3D4 using glTF and import as Inline
>
>
>
> This is all documented on
>
> https://github.com/michaliskambi/x3d-tests/wiki/Converting-glTF-to-X3D
>
> .
>
>
>
> It is linked from the bottom of
>
> https://github.com/michaliskambi/x3d-tests/wiki/2022-Talk-About-X3D-PBR-glTF
>
> :)
>
>
>
> Regards,
>
> Michalis
>
>
>
> czw., 31 mar 2022 o 00:05 Joseph D Williams <joedwil at earthlink.net> napisał(a):
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > HI All, Thanks Michalis, for the show. PBR stuff very impressive and looking usable. For the gltf files imported as Inlines, I hope you will show more about how you  extract the data from tha gltf node file to create the model as an Inline. Which fields of the gltf node file are used to create what at least must be a Shape with some sort of geometry and colors? Where does the mesh and color come from and how to use this to create the vizualized model? Also the animations. How to generate the behavior model from what is in the gltf file(s)?
>
> >
>
> >
>
> >
>
> > Thanks Again for the presentation.
>
> >
>
> > Joe
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> >
>
> > _______________________________________________
>
> > 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/20220331/145222ba/attachment.html>