Restitution 1.0 produces higher bounce every time.

[Wc4ever]

When I set everything to 0.0 but 1 rigid body to restitution 1.0 every next bounce goes higher. Is it intended behaviour? Usually, it is bouncing on the same height in other physics engines.

git patch with example
0001-restitution-bug.patch

[jrouwe]

Hello,

This is a known issue and has been discussed before, see: godot-jolt/godot-jolt#374 (comment)

It is something I should look into though (at least confirm that other physics engines don't have this behavior / don't do the opposite of slowly losing energy).

[Wc4ever]

Hi, thanks for answer.
I could post info of how it works in other engines if you wish.

Here is test from Bullet.
Every damping and friction set to 0. Looks like bullet calculates restitution as multiplication so both objects has to be 1.0 otherwise it dont bounce at all.

App_ExampleBrowser_8CBJGR0Tk2.mp4

Open Dynamics Engine
surface bounce 1.0

demo_tracks_EwlCLPDUta.mp4

Unity build-in engine
Gosh looks like it grows in Unity also(unexpected). Material settings Bounciness 1.0 Combine type Maximum.

Unity_46nul3Ab2c.mp4

[Wc4ever]

Flax Engine (Physx 5)
Wierdest one so far. Set both material Combine type Maximum and restitution 1.0 and it grows every bounce almost the same as in Jolt. But if I set Combine type Multiply and all materials to 1.0 seems it slows down but eventualy grows up again and then slows down.

FlaxEditor_zkI0mj6H2n.mp4

So seems I was wrong about "other engines" but at the same time rebouns at the same height makes more sense to me.

At this point if you belive there is no bug I think it could be just declarated as expected behaviour and closed.

[jrouwe]

I'll leave the bug open for now. It's definitively not physically correct. I'll see if there's a way to make this better.

Mainly for future me, I've simplified the simulation loop to:

// Code to simulate a sphere of radius 2 falling from 10 units high
Vec3 pos = Vec3(0, 10, 0);
Vec3 vel = Vec3::sZero();
Vec3 g(0, -9.81f, 0);
float dt = 1.0f / 60.0f;
float maxy = 0;
for (int i = 0; i < 1000; ++i)
{
	// Apply gravity
	// Equivalent to PhysicsSystem::JobApplyGravity
	vel += g * dt;

	// If we're penetrating the ground, we have to reverse the velocity (corresponds to restitution 1).
	// Equivalent to PhysicsSystem::JobSolveVelocityConstraints
	float penetration = 2.0f - pos.GetY();
	if (penetration > 0 && vel.GetY() < 0.0f)
		vel = -vel;

	// Update position
	// Equivalent to PhysicsSystem::JobIntegrateVelocity
	pos += vel * dt;

	// Record new height records (note we only trace when we're going down again to avoid tracing multiple lines for the same bounce)
	if (vel.GetY() <= 0.0f && pos.GetY() > maxy)
	{
		maxy = pos.GetY();
		Trace("Simulated new high: %f", maxy);
	}
}

which produces:

Simulated new high: 9.997275
Simulated new high: 10.209825
Simulated new high: 10.425099
Simulated new high: 10.643100
Simulated new high: 10.863826
Simulated new high: 11.087276
Simulated new high: 11.313452

When simulating the same setup in Jolt we get the exact same results:

New high point: 10.000000
New high point: 10.209825
New high point: 10.425100
New high point: 10.643101
New high point: 10.863826
New high point: 11.087276
New high point: 11.313451

Implementation: SimpleTest.zip

As said in the other ticket: When the collision has been detected, the gravity has been applied already so the bounce velocity is overestimated.