Motivation behind mLinearCastThreshold

[mihe]

Since this mLinearCastThreshold setting has come up a few times in discussions surrounding CCD, I was wondering what the actual reason is for it to exist in the first place?

Is it mainly an optimization, to allow someone to enable the LinearCast motion type on many/all objects, but only have the CCD test (which I assume comes at a non-trivial additional cost) actually run for fast-moving objects, or are there other concerns that come with widely applying the CCD test, like perhaps the time stealing issue mentioned in your documentation?

If it's purely an optimization, and given that enabling CCD is an opt-in per-body property in Godot, would it make sense to just set this setting to zero (or at least a very low value) and perhaps not expose the setting at all, instead of having users individually come to the realization that the CCD test isn't running in some cases, despite enabling it, and then one way or another find their way to this project setting?

As best I can tell, Godot Physics has no threshold equivalent to this for its CCD, but I vaguely recall seeing various issues reported about its CCD, so I'm not sure how much weight that holds.

[jrouwe]

It's not only a performance optization, if you change SimpleTest to:

void SimpleTest::Initialize()
{
	CreateFloor();

	PhysicsSettings set = mPhysicsSystem->GetPhysicsSettings();
	//set.mLinearCastThreshold = 0; <--- UNCOMMENT THIS AND COMPARE WITH ORIGINAL
	mPhysicsSystem->SetPhysicsSettings(set);

	BodyCreationSettings bcs(new BoxShape(Vec3(0.5f, 1.0f, 2.0f)), RVec3(0, 10, 0), Quat::sRotation(Vec3::sAxisX(), 0.25f * JPH_PI), EMotionType::Dynamic, Layers::MOVING);
	bcs.mMotionQuality = EMotionQuality::LinearCast;	
	mBodyInterface->CreateAndAddBody(bcs, EActivation::Activate);
}

You can see the difference. Normal linear cast treshold:

normal.mp4

Setting it to zero:

zero.mp4

You can see that in this case there is a weird hop on the side that touches the floor first (restitution = 0 so there should not be a hop). This is because motion quality LinearCast can only represent linear motion during the timestep and not the angular motion. Jolt rotates the body first before doing a linear cast, there's some reasoning about it here:

JoltPhysics/Jolt/Physics/PhysicsSystem.cpp

Lines 1523 to 1534 in 1bcbe51

	// Update the rotation of the body according to the angular velocity
	// For motion type discrete we need to do this anyway, for motion type linear cast we have multiple choices
	// 1. Rotate the body first and then sweep
	// 2. First sweep and then rotate the body at the end
	// 3. Pick some in between rotation (e.g. half way), then sweep and finally rotate the remainder
	// (1) has some clear advantages as when a long thin body hits a surface away from the center of mass, this will result in a large angular velocity and a limited reduction in linear velocity.
	// When simulation the rotation first before doing the translation, the body will be able to rotate away from the contact point allowing the center of mass to approach the surface. When using
	// approach (2) in this case what will happen is that we will immediately detect the same collision again (the body has not rotated and the body was already colliding at the end of the previous
	// time step) resulting in a lot of stolen time and the body appearing to be frozen in an unnatural pose (like it is glued at an angle to the surface). (2) obviously has some negative side effects
	// too as simulating the rotation first may cause it to tunnel through a small object that the linear cast might have otherwise detected. In any case a linear cast is not good for detecting
	// tunneling due to angular rotation, so we don't care about that too much (you'd need a full cast to take angular effects into account).
	body.AddRotationStep(body.GetAngularVelocity() * delta_time);