Unexpected breakdancing with the "Planet" level demo in platformer_3d

[samoylovfp]

I'm trying to make a game with non-uniform gravity and ran into some issues with the controller, tried to browse the demos and found this issue.

Ran this from the latest commit available, 3a83862

out.mp4

[idanarye]

@Devlyn-Nelson - is this the same issue you experienced in #125?

[Devlyn-Nelson]

I imagine they are related. I didn't see that this existed in the demo, and played around with it to see if it suffered from the same quirks. the only thing i was not able to reproduce from my own example is being able to walk around the planet where the X value on the player transform likely stays at or close to 0 without sudden break-dancing.

math-quirk.webm

The demo seems to behave differently from mine when the player traverses to the "bottom" of the sphere. I tried the demo using rapier instead of avian, and the demo just forces the player to turn around at the midpoint which explains the difference between our "planet" examples. But the more important detail from the rapier version is that it doesn't have sudden break-dancing, which is making me think it is either avian or the integration between tnua and avian.

[Devlyn-Nelson]

I made a duplicate of the planet example I have in my fork using rapier instead of avian and can confirm it only happens with avian physics back-end.

[Devlyn-Nelson]

So I have done things that seem to fix the issue. When I was looking at apply_motors_system in the physics integrations I couldn't help but notice how different they were. for example the inertia being applied to the motor.ang.boost instead of the motor.ang.acceleration. I do not claim to understand why what I did seems to work but the short story is I made the avian integration apply_motors_system do exactly what the rapier integration did, plus a auto spawn for ConstantTorque and ContantForce if they are not present.

Branch I tested with.

the code

fn apply_motors_system(
    mut commands: Commands,
    mut query: Query<(
        Entity,
        &TnuaMotor,
        &ComputedMass,
        &ComputedAngularInertia,
        &mut AngularVelocity,
        &mut LinearVelocity,
        Option<&mut ConstantTorque>,
        Option<&mut ConstantForce>,
        Option<&TnuaToggle>,
        Option<&TnuaGravity>,
    )>,
) {
    for (
        entity,
        motor,
        mass,
        inertia,
        mut ang_vel,
        mut lin_vel,
        mut constant_torque,
        mut constant_force,
        tnua_toggle,
        tnua_gravity,
    ) in query.iter_mut()
    {
        let (Some(constant_torque), Some(constant_force)) =
            (constant_torque.as_mut(), constant_force.as_mut())
        else {
            commands
                .entity(entity)
                .insert((ConstantTorque::default(), ConstantForce::default()));
            continue;
        };
        match tnua_toggle.copied().unwrap_or_default() {
            TnuaToggle::Disabled | TnuaToggle::SenseOnly => {
                **constant_force = Default::default();
                **constant_torque = Default::default();
                return;
            }
            TnuaToggle::Enabled => {}
        }

        if motor.lin.boost.is_finite() {
            **lin_vel += motor.lin.boost;
        }
        if motor.lin.acceleration.is_finite() {
            ***constant_force = motor.lin.acceleration * mass.value();
        }
        if motor.ang.boost.is_finite() {
            **ang_vel += motor.ang.boost;
        }
        if motor.ang.acceleration.is_finite() {
            ***constant_torque =
                motor.ang.acceleration * inertia.principal_angular_inertia_with_local_frame().0;
        }
        if let Some(gravity) = tnua_gravity {
            ***constant_force += gravity.0 * mass.value();
        }
    }
}

[idanarye]

It saddens me that we cannot use Forces (at all - it conflicts with AngularVelocity), but since it doesn't work properly...

Do you want to open a PR?

[Devlyn-Nelson]

I can open a PR, but before I do I wanted to know if you think avain2d should be given a similar treatment for consistencies sake or should I leave it.

[idanarye]

Yes. I try to keep all backend implementations in sync, as much as possible. Also, if I'm using Forces wrong in 3D, I'm probably also using it wrong in 2D.

Also please add a comment that Forces is not used because of this ticket. Thanks!

[Devlyn-Nelson]

Actually I was able to figure out how to do it with forces, it has functions to do exactly what ConstantForce and ConstantTorque do. Would you prefer that?

[Devlyn-Nelson]

fn apply_motors_system(
    mut query: Query<(
        &TnuaMotor,
        Forces,
        Option<&TnuaToggle>,
        Option<&TnuaGravity>,
    )>,
) {
    for (motor, mut forces, tnua_toggle, tnua_gravity) in query.iter_mut() {
        match tnua_toggle.copied().unwrap_or_default() {
            TnuaToggle::Disabled | TnuaToggle::SenseOnly => {
                return;
            }
            TnuaToggle::Enabled => {}
        }

        if motor.lin.boost.is_finite() {
            *forces.linear_velocity_mut() += motor.lin.boost;
        }
        if motor.lin.acceleration.is_finite() {
            forces.apply_force(motor.lin.acceleration);
        }
        if motor.ang.boost.is_finite() {
            *forces.angular_velocity_mut() += motor.ang.boost;
        }
        if motor.ang.acceleration.is_finite() {
            forces.apply_local_torque(motor.ang.acceleration);
        }
        if let Some(gravity) = tnua_gravity {
            forces.apply_force(gravity.0);
        }
    }
}

apply_force accounts for mass and apply_local_torque accounts for inertia because Forces has those internally. using the apply functions doesn't seem to work well for the boost values.

[idanarye]

If it can be done with Forces, let's do it with Forces. I was not aware of that API, and somehow missed it when I looked at the docs (I was looking for "angular" and "acceleration" - not "torque"). I also like that we no longer need ComputedMass and ComputedAngularInteria.