glTF-Blender-IO
glTF-Blender-IO copied to clipboard
KhronosGroup
Objects don't have a "default" pose to use when not being animated
This is a conceptual problem with how animations work.
In glTF, when an animation is playing any values that are not targeted by the animation have their default value as stored in the nodes array (least that's the normal way to do it). When an animation stops playing, all values go back to these default values.
However in Blender, AFAICT (please correct me if I'm wrong) there are no "default" values that anything can be reverted to. When an animation stops playing, all values are left in whatever state they were last in. Essentially animations in Blender seem to just be overwriting a whole bunch of mutable variables.
This leads to problems with both import and export.
Test file
Here's a test file: AnimDefaultValuesTest.gltf
I'll show you what it looks like in the Three.js viewer.
The default, unanimated pose looks like this.
There are two one-frame animations. The first is called A:BothUp. The cube and icosphere are both raised off the plane.
The second is called B:CubeUp. Only the cube is raised off the plane. The icosphere is not targeted and has its default values.
Let's import it.
Problem: can't play B:CubeUp
Since A:BothUp is the first animation, the importer sets it up to be playing.
It is therefore impossible to now play B:CubeUp, because there is no way to put the icosphere back into its "default" state. The "default" state is not stored anywhere in the .blend file so we couldn't restore it even in principle.
Problem: can't ever go back to the "default" pose
Like I said, it's not stored anywhere.
Problem: can't roundtrip
If you re-export the test file you'll see that the default pose as well as both animations now all look like this
Again, no info about the default values that could be used.
This also means the result of exporting depends on what order the animations get processed in.
What to do about it?
Dunno.
I confirm that there is no default pose on blender. Maybe, when importing, we can store these data in a not visible custom data. And we can use these data on animation management panel discussed in #840 I will propose something for #840 and #1047 for 2.90
The best idea I could come up with is to import the default pose as if there were a one-frame animation with a special name (say <Default>) containing the default pose.
So any animated object would get a new NLA track named <Default> with a one frame action with its default values. The user could edit the default pose like a regular animation this way too.
Then if the exporter found an NLA strip animation named <Default> it wouldn't create an animation for it, but would use it to setup the default values for the nodes.
I've been dealing with this issue for a while but didn't quite understand the cause. I believe it's what I was seeing when I reported this issue: https://github.com/KhronosGroup/glTF-Blender-IO/issues/923
We're using this workflow when exporting avatars for Mozilla Hubs. In order to have hand animations for 6-DOF VR controllers, we stashed all the various hand poses in separate NLA tracks and then usually have 1 or 2 idle animations that loop.
When exporting with 'Always Sample Animations' OFF, the hand poses work correctly. However, when exporting with it ON (as we sometimes need to do depending on the idle animation(s) used) the hand poses get all kinds of messed up-- triggering one hand animates both hands sometimes, for example. When going through all the various animations in a glTF viewer, it's clear that the animation data got corrupted upon export. (This has occurred on just about every release of the exporter.)
So now that I've found this issue thread, I'm realizing it's very likely that not returning to a default pose is what's making some of the animations 'stack up' during the export process.
I've attached the .blend file as well as two .glb files-- one with 'Always Sample Animations' ON and one with it OFF.
Be sure to look at the difference in a glTF viewer when testing the various hand poses. Note in the 'Always Sample' version, some of the poses affect BOTH hands, inexplicably.
Also worth noting: Renaming the animations greatly affects not just the order the clips get exported (and get listed in various viewers), but also affects the WAY in which they get corrupted. (EDIT: Just realized this was mentioned above)
Incidentally, it took me quite a while to figure out that the Action Track names are what get shown in viewers but the actual Action Clip names are what determines the list order. The Action Strip names have no bearing on anything. 😕
So in my example above, the Track names (0-16) show up in viewers as such. But they will be slightly out of order because I renamed the first 5 clips differently (C, B, A, D, E)
I'm not entirely sure why this was chosen as the preferred method, but it's definitely confusing.
Strip names are ignored because — while we can't export this yet — an NLA track could have multiple strips baked into one animation. NLA track order affects rendering within Blender itself, whereas order of Actions is (afaik?) meaningless, so I guess it might be better to preserve the former. Would you want to open a new issue specifically for the ordering question?
About export, here is a proposed way of doing: https://github.com/KhronosGroup/glTF-Blender-IO/issues/1386#issuecomment-998458145 Any thoughts?
Any thoughts?
That script change works and should be default behavior, the current behavior is completely nonsensical. Why should the exportation change the animation data?
I agree that the change should be the default behavior. Would you accept a PR using that approach to fix part of this issue?
If anyone wants the fix, I applied a complete version of the change linked above to the 3.2 release branch: https://github.com/LPGhatguy/glTF-Blender-IO/commit/16e16c18ecad8f25b0587f3cc56d13d6786dac86
