8719a81 breaks bone overrides in some circumstances

[appgurueu]

This regression applies if you set a bone override on a bone with a perfect rotation (rotation matrix just flips the signs of some axes, e.g. 180° rotations around one axis).

8719a81 breaks playeranim and character_anim.

Both these mods "re-animate" the player (originally for the reason that 5.2 and lower did not support overriding single bones), that is, they calculate bone transforms in pure Lua for all bones and apply them via bone overrides.

The problem boils down to the fact that both these mods override the Body bone rotation to identity, when they should override it to a 180° rotation around the Y axis. It's easy to see that these mods are in the wrong by inspecting character.b3d and observing that this is what the body rotation should be (as a quaternion, that's 0, 1, 0, 0 in XYZW order).

Problem is, older Luanti would falsely decompose a perfect 180° Y axis rotation (which is represented exactly this way in the b3d model!) into a -1, 1, -1 scaling and an identity rotation. In other words: These mods are working around an older Luanti bug. I now fixed this bug, and now these mods are setting wrong rotations for all bones that have such perfect rotations:

The bugs are relatively easy to pinpoint:

• https://github.com/minetest-mods/playeranim/blob/f763ce648e81bb59e613ac46c1ec4c33f267d1fc/model.lua#L51
  • Should be {x = 0, y = 180, z = 0} (for body). Similar for other bones.
• https://github.com/appgurueu/modlib/blob/5f0dea2780b88d44d85b9704e0e81348c459404d/b3d.lua#L1125
  • The claim in the comment is false and the composition should be removed.

Furthermore the manual head rotation needs to be fixed.

For a mod to be affected, it needs to apply a bone override to a bone which is rotated by exactly 180° around one of the cardinal axes, thereby inverting the other two axes. This means there will likely be more affected mods than these two.

Impact:

• playeranim has ~1.5k downloads on CDB. character_anim has ~43k downloads.
• playeranim serves a total of ~50 players on only 5 servers at the time of this writing, the most notable being Your Land (@Bastrabun) and Blocky Survival with 30 and 15 players respectively. character_anim serves ~10 players on a few more servers.
• Even if we fix the mods, it's still bad:
  • New clients joining servers running older versions of these mods will see players incorrectly.
  • Older clients will see the models incorrectly, because they are sent the same overrides.

Affected servers

Possible solutions:

• headanim is a decent alternative that is unaffected by these changes, but only works on 5.3+. This seems a good compromise to me so far.
• Put the bug back in. Not a decent option long term. May be a decent option for 5.11.
• Put the bug back in, but behind a flag. May be a bit tricky, but could work. I don't like having to enable "correct" behavior though.

[Zughy]

These mods are working around an older Luanti bug. I now fixed this bug

Problem solved then, I don't see how it's an issue of ours when we did our part. The rest is just more noise in the code

[nininik0]

There is a similar issue after 5.8 with 3d_armor_flyswim where the animation is jittery and loops, so it dosent show the full animation because it resets, which looks ugly and not good, and applies to all but the walking animation.

[appgurueu]

There is a similar issue after 5.8 with 3d_armor_flyswim where the animation is jittery and loops, so it dosent show the full animation because it resets, which looks ugly and not good, and applies to all but the walking animation.

That sounds like a different issue, possibly not even an engine issue. This issue is specifically about a change in behavior in 5.11-dev.

[sfan5]

Someone reported a Mineclone-related breakage here: https://irc.minetest.net/minetest/2025-01-20#i_6236567

[appgurueu]

An additional workaround I think I can offer:

Using modlib's b3d tools, I could produce slightly modified versions of models (at load time even) which avoid triggering the bug by very slightly rotating bones (not that this rotation should matter for playeranim or character_anim, because it is entirely overwritten by the bone override anyways). This would enable consistency between older and newer Luanti client versions. Users would still have to upgrade playeranim or character_anim (or their Mineclon* version).

Alternatively, I could turn these perfect rotations into no rotation and negative scale in the b3d and then make some slightly tricky changes to preserve the TRS representation with negative scaling inside Irrlicht, but I don't see much of an advantage of this (except that it doesn't require updating the affected mods, but since there's only a handful and character_anim and player_anim should be pretty easy to fix, it doesn't matter much; making the engine changes would probably be trickier).

[appgurueu]

Using modlib's b3d tools, I could produce slightly modified versions of models (at load time even) which avoid triggering the bug by very slightly rotating bones (not that this rotation should matter for playeranim or character_anim, because it is entirely overwritten by the bone override anyways). This would enable consistency between older and newer Luanti client versions.

I've implemented this. See appgurueu/character_anim@61b62ae.

I have messed a bit with playeranim but I won't deal with it. My hack can in principle also be applied to playeranim, but the rotations need to be manually fixed. Users may consider switching to character_anim. If someone wants to fix playeranim, here's a diff for a start:

diff --git a/model.lua b/model.lua
index 378329b..dd8d64b 100644
--- a/model.lua
+++ b/model.lua
@@ -48,13 +48,13 @@ local BONE_ROTATIONS = {
 		body_lay = {x = 270, y = 0, z = 0},
 	},
 	MTG_5_0_x = {
-		[BODY] = {x = 0, y = 0, z = 0},
+		[BODY] = {x = 0, y = 180, z = 0},
 		[HEAD] = {x = 0, y = 0, z = 0},
-		[CAPE] = {x = 0, y = 0, z = 0},
-		[LARM] = {x = 0, y = 0, z = 0},
-		[RARM] = {x = 0, y = 0, z = 0},
-		[LLEG] = {x = 0, y = 0, z = 0},
-		[RLEG] = {x = 0, y = 0, z = 0},
+		[CAPE] = {x = 180, y = 0, z = 0},
+		[LARM] = {x = 180, y = 0, z = 0},
+		[RARM] = {x = 180, y = 0, z = 0},
+		[LLEG] = {x = 180, y = 0, z = 0},
+		[RLEG] = {x = 180, y = 0, z = 0},
 
 		body_sit = {x = 0,   y = 0, z = 0},
 		body_lay = {x = 270, y = 0, z = 0},

You can use the code in character_anim to "wiggle" the models.

I consider this problem solved / workaroundable. I initially raised this issue because ensuring consistency between older and newer clients was problematic. But with this model workaround it's possible.

I've spent too much time digging this hacky hole deeper already. I will not spend time putting the engine bug back in.

[appgurueu]

For what it's worth, note that:

• Nudging the bone rotations can also be done e.g. in Blender if you prefer that. You should probably not animate bones which you override, that may complicate things.
• As a very quick and dirty workaround, if you only target 5.9+, you should alternatively be able to also override the scale of the bone to 1, 1, 1, forcing consistency for 5.9, 5.10, and 5.11+ clients.
• I believe you could also try putting the negative scale in there. This might give you a relatively easy workaround that works on all clients: You just have to set the proper scale per-bone in each bone override, hence forcing newer clients to exhibit the bug again. You can possibly get away without editing models at all this way.

[appgurueu]

For those who want further details and/or a good story, I have a blog post for you: https://appgurueu.github.io/2025/02/20/breaking-bones.html