Infinite Bouncing Ball fails

[Wolftousen]

This is somewhat related to #200 , but that was specific to XPBD.

I've tried to make the same thing happen in Avian2d, but am failing to get an infinite bounce no matter what. The balls bounce decays rather quickly.

I did try without parallel and without simd and got the same results. I was unable to try with f64 due to build errors that I haven't had time to look into.

It also happens in release mode and debug mode.

My Cargo.toml:

[package]
name = "game"
version = "0.1.0"
edition = "2021"

[dependencies]
bevy = { version = "0.15.0", features = ["dynamic_linking"] }
leafwing-input-manager = "0.15.1"
leafwing_abilities = "0.9.0"
avian2d = { git = "https://github.com/Jondolf/avian", branch = "main", features = ["2d", "parallel", "simd"]}
bevy_prototype_lyon = "0.13.0"

# Enable a small amount of optimization in the dev profile.
[profile.dev]
opt-level = 1

# Enable a large amount of optimization in the dev profile for dependencies.
[profile.dev.package."*"]
opt-level = 3

My code:

use bevy::{color::palettes::css::*, prelude::*};
use bevy_prototype_lyon::prelude::*;
use avian2d::prelude::*;

fn main() {
    App::new()
        .insert_resource(ClearColor(Color::srgb(0., 0., 0.)))
        .insert_resource(Gravity(Vec2::NEG_Y * 98.1))
        .insert_resource(Time::<Fixed>::from_hz(120.0))
        .add_plugins((DefaultPlugins, ShapePlugin, PhysicsPlugins::default()))
        .add_systems(Startup, spawn)
        .run();
}

fn spawn(mut commands: Commands) {
    //camera
    commands.spawn((Camera2d, Msaa::Sample4));

    //shapes
    let circle = shapes::Circle {
        radius: 10.0,
        ..Default::default()
    };

    let rect = shapes::Rectangle {
        extents: [50.0, 5.0].into(),
        origin: RectangleOrigin::Center,
        ..Default::default()
    };

    //ball
    commands.spawn((
        Collider::circle(10.0),
        Friction::ZERO.with_combine_rule(CoefficientCombine::Min),
        Mass(1.0),
        AngularVelocity(0.0),
        LinearVelocity([0.0, 0.0].into()),
        ColliderDensity(0.0),
        AngularDamping(0.0),
        LinearDamping(0.0),
        SweptCcd::default(),
        RigidBody::Dynamic,
        Restitution::PERFECTLY_ELASTIC.with_combine_rule(CoefficientCombine::Max),
        ShapeBundle {
            path: GeometryBuilder::build_as(&circle),
            ..default()
        },
        Fill::color(GREEN),
    ));

    //start indicator
    commands.spawn((
        ShapeBundle {
            path: GeometryBuilder::build_as(&rect),
            transform: Transform::from_xyz(0.0, 15.0, 0.0),
            ..default()
        },
        Fill::color(RED),
    ));

    //floor
    commands.spawn((
        RigidBody::Static,
        Collider::rectangle(50.0, 5.0),
        ShapeBundle {
            path: GeometryBuilder::build_as(&rect),
            transform: Transform::from_xyz(0.0, -100.0, 0.0),
            ..default()
        },
        Fill::color(BLUE),
        Friction::ZERO.with_combine_rule(CoefficientCombine::Min),
        Restitution::PERFECTLY_ELASTIC.with_combine_rule(CoefficientCombine::Max),
    ));
}

[Wolftousen]

I did manage to try it with f64, but made no difference. I also increased the substeps to 32 and that also made no difference.

I added some logging to the collision event to try to track things down better:

Bounce	Collision State	Impulse	Ball Linear Velocity Y	Impulse - Start Velocity	Start Velocity - End Velocity	Percent Difference from Start Velocity
1	start	0	130.79079
2	end	130.81633	129.9734	0.02554	0.81739	0.006249599073
3	start	0	129.97339			0
4	end	129.99893	129.156	0.02554	0.81739	0.006288902675
5	start	0	129.15602			0
6	end	129.18156	128.33864	0.02554	0.81738	0.006328624868
7	start	0	128.33862			0
8	end	128.36417	127.52124	0.02555	0.81738	0.006368932438
9	start	0	127.521255			0
10	end	127.5468	126.70387	0.025545	0.817385	0.006409794195
11	start	0	126.70386			0
12	end	126.7294	125.886475	0.02554	0.817385	0.006451145214
13	start	0	125.88649			0
14	end	125.91203	125.06911	0.02554	0.81738	0.006492992219
15	start	0	125.06909			0
16	end	125.112946	124.25171	0.043856	0.81738	0.006535427738
17	start	0	124.251724			0
18	end	124.27727	123.43434	0.025546	0.817384	0.006578451982
19	start	0	123.434326			0
20	end	123.50015	122.61694	0.065824	0.817386	0.006622031541
21	start	0	122.61696			0
22	end	122.6425	121.799576	0.02554	0.817384	0.006666157765
23	start	0	121.79956			0
24	end	121.89102	120.98218	0.09146	0.81738	0.006710861681
25	start	0	120.98219			0
26	end	121.00774	120.16481	0.02555	0.81738	0.006756201057
27	start	0	120.164795			0
28	end	120.24893	119.34741	0.084135	0.817385	0.006802200262
29	start	0	119.34743			0
30	end	119.37297	118.530045	0.02554	0.817385	0.006848785935
31	start	0	118.53003			0
32	end	118.63614	117.71265	0.10611	0.81738	0.006895973957
33	start	0	117.71266			0
34	end	117.738205	116.89528	0.025545	0.81738	0.006943858035
35	start	0	116.89526			0
36	end	117.02701	116.07788	0.13175	0.81738	0.00699241355
37	start	0	116.077896			0
38	end	116.10344	115.26051	0.025544	0.817386	0.00704170241
39	start	0	115.2605			0
40	end	115.414215	114.443115	0.153715	0.817385	0.007091631565
41	start	0	114.44313			0
42	end	114.46867	113.62575	0.02554	0.81738	0.007142237372
43	start	0	113.62573			0
44	end	113.74649	112.80835	0.12076	0.81738	0.00719361715
45	start	0	112.808365			0
46	end	112.83391	111.99098	0.025545	0.817385	0.007245783591
47	start	0	111.99097			0
48	end	112.1337	111.173584	0.14273	0.817386	0.007298677742
49	start	0	111.1736			0
50	end	111.19914	110.35622	0.02554	0.81738	0.007352285075
51	start	0	110.3562			0
52	end	110.52457	109.53882	0.16837	0.81738	0.007406742893
53	start	0	109.53883			0
54	end	109.56438	107.90407	0.02555	1.63476	0.01492402283

You can see that the Impulse is usually off by 0.02554 (or a close multiple) from the starting velocity of the ball.

Then the Start and End Velocity of the ball is almost always off by 0.81739. This is insanely consistent until the last bounce when it is just 2x that number. This also feels to large of a value to be a rounding error.

So I changed my restitution to be 1.006249599073 (this is the % difference between the start and end velocity of the first bounce when restitution was 1.0) and things seem to be working pretty well, I've had it running for about 10 minutes and the ball is staying on point with maybe some minor fluctuation that could be attributed to rounding issues.

For reference, here is the system i added for logging on Update:

fn print_collisions(world: &World, mut collision_event_reader: EventReader<Collision>) {
    for Collision(contacts) in collision_event_reader.read() {
        let mut state = "start";

        if !contacts.collision_started() {
            state = "end"
        }

        let velocity = world.get::<LinearVelocity>(contacts.entity2);

        println!(
            "{:?} | {:?} | {:?}",
            state,
            contacts.total_normal_impulse,
            velocity.unwrap()[1]
        );
    }
}

[Wolftousen]

After changing my restitution to 1.006249599073, I tried a few things to see if that value would be stable:

Change	Result	Notes
2x mass of ball	stable
20x mass of ball	stable
10x gravity (981)	unstable	to get stability, new value for restitution was 1.01999980917146408790443111199947
100x gravity (9810)	unstable	to get stability, new value for restitution was 1.06249999522171290353876884260177, but this caused the ball to go a little to high, but was stable at the new height. An interesting observation is that if I changed it to 1.062, it became unstable and the ball started to climb in height instead of decrease, even though the restitution was lower.

[Wolftousen]

It should also be noted that if gravity is left at the default of 9.81 (and you do not change the length unit) that restitution 1 is also not stable and will cause the ball to decrease in height, all be it very slowly compared to other values of gravity.

So there is some kind of direct correlation to gravity here, maybe not causation though.

[Jondolf]

Hi! Could you try setting the SpeculativeMargin of the ball to zero while SweptCcd is enabled? I suspect that this problem is caused by speculative collision, which applies a predictive impulse to prevent tunneling, but it has the downside of absorbing some of the impact and making restitution a bit worse. With SweptCcd, you probably don't need speculative collision either way in this case, and it should work better with restitution.

[Wolftousen]

That worked and resulted in stability.

May want to add a note to the speculative documentation about the impulse and restitution conflicts and how to account for them.

Also the docs about swept and speculative ccd make it seem like enabling swept on an entity disables speculative. Is there a way to disable speculative other than setting the margin to zero?

[Jondolf]

May want to add a note to the speculative documentation about the impulse and restitution conflicts and how to account for them.

Yup, agreed!

Also the docs about swept and speculative ccd make it seem like enabling swept on an entity disables speculative.

The CCD docs do briefly mention: "Speculative collision is enabled by default, but swept CCD is opt-in with the SweptCcd component. The two approaches can also be used together." and: "Swept CCD might also not account for chain reactions properly, so if a fast-moving body bumps into another body, making it a fast-moving body that potentially bumps into even more bodies, the collisions might not propagate accurately. However, speculative contacts do detect secondary collisions quite well, so using the two together can help mitigate the issue."

Having both enabled can be valuable in some cases. Swept CCD has the problem of "time loss", and successive contacts within a single timestep may not be handled properly. Speculative collision can help with that, while still having swept CCD as a sort of safety net to fully prevent tunneling for more complicated scenarios.

Is there a way to disable speculative other than setting the margin to zero?

Speculative collision is quite cheap, and setting the margin to zero is basically equivalent to disabling it. You can disable it globally by setting NarrowPhaseConfig::default_speculative_margin to zero.

[Jondolf]

Added some brief documentation on how speculative collision can affect restitution in #598. Closing this issue now since it seems to be resolved.