Substep-dependent normalImpulse measurement and friction behavior in Obi Rope 6.5.4

[nakai]

Hello,

I found two contact-related issues that appear to depend on the number of substeps in Obi Rope 6.5.4 using the Burst backend.

Test setup:

- Rod mass: 2.1 kg (21 particles, 0.1 kg each)
- Fixed timestep: 0.01 seconds
- Incline angle: 45 degrees
- Static friction coefficient: 1
- Dynamic friction coefficient: 1
- Rolling contacts: disabled
- Sleep threshold: 0

Under these conditions, both the expected normal force and the tangential component of gravity are approximately 14.57 N.

1. Normal contact force measurement
Simply dividing the final normalImpulse value by either the fixed timestep or the substep duration did not produce an accurate force.
The positional correction applied by the contact constraint is scaled using the number of remaining substeps. 
Does this mean that each change in the normal constraint multiplier must be converted using the remaining time at the corresponding substep?

In my tests, the following conversion produced a normal-force estimate consistent with the expected value:

normal impulse increment = change in normal Lagrange multiplier / (remaining substeps × substep duration)

This requires recording the change in normalImpulse at every substep.
 I could not reconstruct the normal force over the full physics step from the value obtained only in the final collision callback using a single time value.

2. Friction behavior
The friction issue appears to affect not only force measurement but also the motion produced by the simulation.
With one substep, the cable remained approximately in equilibrium on the 45-degree incline. 
However, with two or more substeps, the cable slid down the incline even though the timestep, friction coefficients and constraint iteration count were unchanged.

In a representative test with three substeps:

- Normal force: approximately 14.57 N
- Friction force actually applied by the simulation: approximately 10.3 N
- Expected limiting Coulomb friction: approximately 14.57 N

The friction force reconstructed from the contact data agreed with the value calculated independently from the cable’s momentum change. 
Therefore, the lower friction value was not only caused by an error in reading the collision callback. The simulation itself appeared to apply approximately 10.3 N of friction.
This suggests that the normal impulse used to calculate the Coulomb friction limit may be underestimated when multiple substeps are used.
To address this behavior, I converted the change in the normal Lagrange multiplier at each substep into a normal impulse using the corresponding remaining interval.
I then accumulated these impulses and used the accumulated value to calculate the Coulomb friction limit.

I would like to confirm the following points:

1. In Obi 6.5.4, does normalImpulse require a correction that accounts for the number of remaining substeps?
2. In the Burst backend, can the friction limit used by the simulation depend on the number of substeps?
3. Is converting each substep’s change in the normal Lagrange multiplier using its corresponding remaining interval, accumulating the resulting normal impulses, and using them for the Coulomb friction limit consistent with the intended solver implementation?
4. Has this behavior been changed in newer versions of Obi?

Thank you.

[josemendez]

Hi!

1. In Obi 6.5.4, does normalImpulse require a correction that accounts for the number of remaining substeps?

The value you get is that of the last step. In general, this can't be adjusted for the number of substeps, since each substep is an entirely indepedent integration/constraint evaluation cycle. See below for the reason why its designed this way (*).

2. In the Burst backend, can the friction limit used by the simulation depend on the number of substeps?

No, each substep is its own independent solve so to speak.

3. Is converting each substep’s change in the normal Lagrange multiplier using its corresponding remaining interval, accumulating the resulting normal impulses, and using them for the Coulomb friction limit consistent with the intended solver implementation?

(*)The way contacts against rigidbodies work is that both particle and rigidbody state are linearly extrapolated to end of the frame (that is, across multiple substeps) and the contact constraint solved there. The resulting impulse is divided by the amount of remaining substeps. The reason for this is that the rigidbody engine and the particle engine are updated at different timesteps/frequencies (rigidbody simulation in unity doesn't have substepping), so this is effectively a partitioned multirrate simulation.

As a consequence, the value you get for the last substep multiplied by the amount of substeps is often an acceptably good approximation of the force over the entire step, though it is often an underestimation.

Code:

This suggests that the normal impulse used to calculate the Coulomb friction limit may be underestimated when multiple substeps are used.

This is precisely right: each substep uses only the normal impulse calculated for the current substep, which is smaller the more substeps you have as a result of the method explained above.

4. Has this behavior been changed in newer versions of Obi?

No, it works the same way in the latest version (7.2) and still does in upcoming versions (8).

If you're looking for accurate values, skip substepping entirely (only 1 substep) and divide your project's current timestep size by the amount of substeps you were using. Eg. if you were using 4 substeps and timestep = 0.02, use 1 substep and timestep = 0.02/4 = 0.05. This way particles and rigidbodies update at the exact same frequency, which is more accurate - but also a lot heavier in terms of performance.

Kind regards,