Bounciness issues with large dtime steps

[kno10]

Minetest version

Minetest 5.9.0 (Linux)
Using LuaJIT 2.1.1719379426 (OpenResty)
Built by GCC 14.2
Running on Linux/6.8.12 x86_64
BUILD_TYPE=Release
RUN_IN_PLACE=0
USE_CURL=1
USE_GETTEXT=1
USE_SOUND=1
STATIC_SHAREDIR="/usr/share/minetest"
STATIC_LOCALEDIR="/usr/share/locale"

Irrlicht device

X11

Operating system and version

Debian sid

CPU model

No response

GPU model

Intel

Active renderer

No response

Summary

When there is lag in the server (generating map chunks, spawning structures, mobs...) and it misses some dtime steps, entities can bounce badly on beds. Seen for example in Voxelibre and Mineclonia.

The reason is an incomplete interpolation in collision.cpp.

First the acceleration is applied over the entire dtime:
https://github.com/minetest/minetest/blob/dc21924f31ff52174553c4441ce8c861f842c6f9/src/collision.cpp#L365-L367

then a collision is searched with the updated speed (this is probably okay as an approximation).
Then when a collision was found, it is assumed it was at the updated speed:
https://github.com/minetest/minetest/blob/dc21924f31ff52174553c4441ce8c861f842c6f9/src/collision.cpp#L505

When not bouncing that likely does not matter as much, because the collision sets the speed to 0, but not when on bouncy material (such as beds in Voxelibre and Mineclonia):
https://github.com/minetest/minetest/blob/dc21924f31ff52174553c4441ce8c861f842c6f9/src/collision.cpp#L538

A perfect simulation would of course mean checking some parabola, which is expensive. I think checking a linear movement from the start to the destination is okay as an approximation, but the error in the collision speed causes larger issues with bouncyness.

Steps to reproduce

1. Mineclonia + World Edit
2. Place a bed
3. Place a villager onto it
4. run //lua local t0 = os.time() while os.time() < t0+2 do end
5. Result

[Zughy]

Here comes THE SCREWDRIVER

output2.mp4

(I've used this command to make it lag

//lua local t0 = os.time() while os.time() < t0+2 do end

[Zughy]

Is #13140 the same thing?

[kno10]

I do not think #13140 is the same, because there are no collisions involved in the description.

I have also prepared a draft fix in 1519875 but still waiting for the build to finish. Nevertheless, this may help understanding what I believe is missing from the velocity computations.

[kno10]

As for testing, it should also be possible to

• run something that provokes lag, such as your screwdriver
• jump on a bouncy node
• have some entity/mob fall on a bouncy node

[appgurueu]

As for testing, it should also be possible to

• run something that provokes lag, such as your screwdriver
• jump on a bouncy node

This does not seem to work (tested in devtest and mineclonia). IIRC local player physics run at a different, fixed small stepsize (which can be afforded because each client does their own and there is only a single local player per client).

It also can't be reproduced with items, since those zero the velocity on collision (:

So this unfortunately isn't nice to reproduce in devtest. But in Mineclonia I can reproduce it, and the engine code shows that it's indeed an engine issue.

[kno10]

"This does not seem to work" -> "This test does not work"
(otherwise it sounds as if the patch does not work - but if I understand you correctly, it is just the proposed test that does not work?)

[appgurueu]

"This does not seem to work" -> "This test does not work" (otherwise it sounds as if the patch does not work - but if I understand you correctly, it is just the proposed test that does not work?)

No no, the patch works, that's why I was commenting on the issue. I just had a bit of trouble trying to reproduce the issue in devtest in the first place due to the aforementioned reasons :)

[kno10]

Can we try to get the second iteration of this #15408 into 5.11.0?
(And maybe some full parabolic collision in another revision)

[Zughy]

That's too risky to review and merge during a feature freeze unfortunately. We have to postpone it to 5.12 :c