[x3d-public] STEP interpolation, was Blender > Exporting rigtransforms to HAnim?
Joseph D Williams
joedwil at earthlink.net
Thu Jul 20 17:50:29 PDT 2023
➢ Perhaps that is in the domain of a Script but seems generally useful for many applications..
Yes, it is in the domain of a fine prototype posemixer or something that gracefully transitions from one animation and another.
> Hence the logic "what to do with joints that are not touched by
> this animation" is left to the animation player. Which can do anything
> it wants -- and Blender, glTF viewers, Spine do "use the initial joint
> transformation" by default.
Yeah, by default. If you add this feature, please give a choice. Wow, what is somebody going to do when they get to x3d and find out x3d doesn’t have that auto reset function. Well they have to make sure their animations are complete.
It is easy to have more than one animation working on a character. You mentioned walking and hand wave. From different routines. What if I switch handwave for salute, does that reset my entire skeleton walk?. Face it this is just a little helper that actually cannot be used to document the complete animation or transition between animations. Again, this built-in fix probably actually operates a bit different than we think. And there must be a way to tell it not to bother. I’d like to see some official description. Maybe write this up: “When the render machine does not think you have included enough joints in your animation we fix some by setting what we think you left out to default. Here is a list of interfaces we moved to default.”
By the way, of course the joint centers and rotations at default are fully known and always available in the Humanoid. So helper can do anything at authortime but leave my runtime alone.
Please, this is not x3d, its really a troubleshooting step. Sounds like ‘all joints not animated are set to default’ could make omissions easier to spot in most cases. That is the same thing that happens in x3d animations, except as you point out, if you change animations at random and don’t take control of every joint in the new those not controlled remain as is. X3d does not need decorative features like this. This is one of those things that give an illusion of understanding but in the end when you have been depending on this sort of helper and it actually gets complicated, you discover a mess and think why the heck did I let them do that (cover my …) to me for so long.
>a model with >100 joints, and >20 animations.
So many joints because most don’t know about Displacers and have to use and reuse sets of small joints for lots of small skin animations. When they understand, then they move to sets of coordinate Interpolators or morphers, or displacers for deformations. And, mostly don’t care much about realtime. And some don’t even know about joints, they think the skeleton is put together with a bunch of bones
But hey let’s try to get something like attached into gltf, I’ll help all I can.
This is example of relatively low complexity with a couple of animations.
Note that if you interrupt an animation then, if the new animation does not address that joint then the joint remains where it was last set.
Thanks,
Joe
From: Andreas Plesch
Sent: Wednesday, July 19, 2023 8:40 PM
To: Michalis Kamburelis
Cc: Joseph D Williams; X3D Graphics public mailing list
Subject: Re: [x3d-public] STEP interpolation,was Blender > Exporting rigtransforms to HAnim?
On Wed, Jul 19, 2023 at 9:17 PM Michalis Kamburelis
<michalis.kambi at gmail.com> wrote:
>
> 1. There's a good reason why all 3 things I listed (Blender, most glTF
> viewers, Spine) behave this way:
>
> In practical applications, you can easily have a model with >100
> joints, and >20 animations. When a 2D / 3D artist wants to add a new
> animation, e.g. "wave a hand": The author wants to deal with (animate)
> only the few joints of that hand that are important for this
> animation. The author doesn't want to explicitly set keyframes on all
> the unused joints (that would be both unnecessary work, and also make
> further edits of it difficult -- when the initial pose changes, or new
> joints appear).
>
> Hence the logic "what to do with joints that are not touched by
> this animation" is left to the animation player. Which can do anything
> it wants -- and Blender, glTF viewers, Spine do "use the initial joint
> transformation" by default.
I think an X3D based animation viewer could do the same if an author
wants that. It is not hard to store coordinates for an initial pose in
a CoordinateInterpolator and route it to the shape when desired.
glTF does not prescribe how to actually use the frame transform data
for animations. It is up to a scene author to determine how fast it
should play or how it should be combined with other animations. It
sounds like the default of using the initial joint transform could be
a side-effect of resetting the whole scene in some cases when a new
animation is loaded. Generic glTF viewers just want to show something
which uses the animation. The expectation still is that when the glTF
is actually used ( for example to showcase a product ) the author
needs to take responsibility that the animation is played the way the
author intended.
I think it would be interesting to have the ability in X3D to get
weighted averages of multiple interpolators for mixing and blending
animations. I think that how blending animations is typically done ? A
MixerInterpolator node which accepts children interpolators of the
same type with input weights, computes the weighted average of all at
the same input fraction and provides that as value_changed. Perhaps
that is in the domain of a Script but seems generally useful for many
applications..
Regards, Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230720/3e16e7b9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JoeLevel2LOA3SSPYRWRJKNoGeometryHud.zip
Type: application/zip
Size: 22563 bytes
Desc: not available
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20230720/3e16e7b9/attachment.zip>
More information about the x3d-public
mailing list