Attachments lag behind bones under some circumstances

[hecktest]

Minetest version

5.8.0 ?

Summary

Possible regression or edge-case loose end of #2813 aka "hat lag"

Under some circumstances, an attachment will lag behind its parent bone. This is best observed when the framerate is limited.
The circumstances are very chaotic, to the point that rotating the camera around a little can reshuffle things and make the bug disappear. The presence of entities could be affecting it, it may be related to the drawing order. The bug seems to only happen when I attach the player to an empty entity.

5.6.0 very likely introduced this regression. I cannot reproduce this in 5.5.0 in any way.
It does happen in 5.5 only very rarely

Steps to reproduce

1. attach something to a player's head
2. attach the player to some vehicle entity
3. move the vehicle entity
4. detach and repeat from step 2 in varying conditions

Extra information:

• The attachment is also skinned and animated
• The models in question both use alpha clip, which may affect sorting

[hecktest]

Interesting observation: the animation is synced correctly, but a stale position of the parent vehicle is used.

[appgurueu]

I've also observed this on the CitySim server, where weapons are attached to player bodies. When players drive cars, this happens: The weapon lags behind. I had not made the connection to bones however and could not reproduce it without bones in devtest.

I can confirm this on Minetest 5.8.0 and 5.9-dev using the following code:

local nt = "no_texture.png"
minetest.register_entity("dev:car", {
	initial_properties = {
		visual = "cube",
		textures = {nt, nt, nt, nt, nt, nt},
		static_save = false
	},
	_timer = 0,
	_d = 1,
	on_step = function(self, dt)
		self._timer = self._timer + dt
		if self._timer > 1 then
			self._d = -self._d
			self._timer = 0
			self.object:set_velocity(vector.new(5 * self._d, 0, 0))
		end
	end
})

minetest.register_entity("dev:helmet", {
	initial_properties = {
		visual = "cube",
		textures = {nt, nt, nt, nt, nt, nt},
		static_save = false
	},
})
minetest.register_on_joinplayer(function(player)
	minetest.after(0, function()
		local car = minetest.add_entity(player:get_pos(), "dev:car")
		player:set_attach(car)
		local helmet = minetest.add_entity(player:get_pos(), "dev:helmet")
		helmet:set_attach(player, "Head")
	end)
end)

The "helmet" attached to the head clearly lags one (?) client (?) step behind:

Screencast.from.05-07-24.22.53.22.webm

[hecktest]

Yes, it's one client frame behind. You can force low FPS to make it more apparent.

[hecktest]

Actually, it's not just the root transform, the entire chain including animation is stale. This is a full blown regression of the hat lag, this time not related to draw order since it's broken in both stereo eyes.

[hecktest]

Tested with an unskinned attachment just to make sure it's not that.

[hecktest]

More weird behavior: the hats will follow the player's root position correctly but lag behind in pose space. The player is not attached to anything in this. NPCs display an identical bug and it persists between restarts.

[sfan5]

this possibly? minetest/irrlicht#154

Edit: no. 5.5 -> 5.6 would put this into this range minetest/irrlicht@1.9.0mt4...1.9.0mt7 but I see nothing remotely related.
commits in MT: 5.5.0...5.6.0

[hecktest]

I actually managed to force 5.5 to bug out so that range might be a red herring. I think there's two different bugs in here and one of them has been gradually getting worse.

It would probably help to explain what the game does here:

This is a tumble roll move that applies root motion from the animation by attaching the player to an empty entity and moving said entity with animation curve data.
The hair is an animated mesh attached to the head bone.

Here are the results of a re-test:
5.9: Hair never stays in place during a rooted move. Animated attachment parent bone also lagging (locally). #14817 causes further visual desync.
5.8: Hair never stays in place during a rooted move. Normal movement still unaffected.
5.7: Hair occasionally lags behind during a rooted move. Presence of an NPC (identical model and attachment setup) and the camera angle seem to affect the frequency. Bug does not occur if the player is not attached to anything.
5.6: Probably same as 5.7
5.5: Possibly harder to bug out than 5.6 (unconfirmed)

I wouldn't rule out that the lowest "layer" of this is something I missed in the last fix. The 5.8 breakage is definitely new. 5.9 adds two new bugs.

At this point it might be more economical to just carefully trace what happens during a client frame instead of trying to pinpoint a specific commit.

[FatalistError]

ok so jiggle physics aside, I've run into this issue, and it's posing a problem already for adding gun attachments, would be great to see this fixed in 5.10 alongside animation fixes 👍