Added acceleration-mode velocity drive to SixDOFConstraint motors

[khiner]

A velocity motor whose MotorSettings::mSpringSettings has damping > 0 and no stiffness/frequency now produces a soft, mass-normalized velocity drive (a = -damping * v_err) via an implicit-Euler soft constraint. Previously the damping was ignored and the motor acted as a hard velocity constraint. Motors with damping == 0, and position motors, are unchanged.

Added unit test TestSixDOFMotorVelocityAcceleration covering both translation and rotation motor paths, both spring modes, and two body sizes to verify mass/inertia independence.

Disclosure: I developed this with the help of Claude Code.

[CLAassistant]

All committers have signed the CLA.

[jrouwe]

Thanks! It will take me some time to validate this change.

In the mean time: What is your use case for this and can't you use the built in friction of the constraints (e.g. SixDOFConstraintSettings::mMaxFriction)? Obviously that will not give you the exact same formula as what you've implemented here.

[khiner]

Thanks for taking a look!

My use case is the KHR_physics_rigid_bodies Robot_skinned glTF sample. It defines three angular drives in mode: "acceleration": two of them (legs and cog) have stiffness: 0 with damping > 0 and a non-zero velocityTarget. The spec's joint.drive section defines the drive as:

proportional to stiffness * (positionTarget - positionCurrent) + damping * (velocityTarget - velocityCurrent) … in acceleration mode … scaled by the effective mass of the driven degree of freedom.

So that case reduces to a = damping * (velocityTarget - velocityCurrent), which I couldn't express with Jolt as-is.

• Video of the robot with this patch:

robot_with_1977_fix.mp4

• Video with mMaxFriction:

robot_sub_mMaxFriction_1977_fix.mp4

Since it's a passive friction cap, the leg and cog drives apply no force toward their velocityTarget and the robot doesn't move.

However, I went back and realized for this scene, on master, letting Jolt's velocity motor handle these drives
looks visually just about identical (with EMotorState::Velocity ignoring mSpringSettings entirely and a hard velocity constraint at velocityTarget). I think because the damping values are large enough, even though it ignores the damping value it seems to look fine in this case:

robot_no_patch.mp4

Still, silently dropping the damping prevents implementing KHR_physics_rigid_bodies exactly. Instantaneous lock to velocityTarget instead of a ramp would show better when damping is small or the driven body is light.

Anyway, not as blocked as I thought on this one, so feel free to do what you'd like with this PR, thanks for looking :)