Deprecate fixedStep from World

[krispya]

Deprecate fixedStep from World

[marcofugaro]

fixedStep() is the recommended way of using cannon.js, that's why it's there by default.
It's even in the basic example in the cannon.js README.

It solves the issue that many users have when using step() without interpolation. Many users have been reporting that the scene runs differently on different browsers (for example on VR, where the requestAnimationFrames runs at more hertz).
You can read more about this in this article: Fix your Timestep!.

Advanced users can still use world.step() normally as it's not been removed.

[krispya]

Hmm, the example you linked uses step() but looking at the cannon-es README it does explicitly recommend fixedStep() for new users: https://pmndrs.github.io/cannon-es/docs/index.html

It is confusing to me coming from engines like Unity which don't have interpolation on by default. I had checked the the docs and it said nothing about it either: https://pmndrs.github.io/cannon-es/docs/classes/World.html#fixedStep

I had to look at the source code to realize it was doing it automatically, passing into step() with interpolation. An easy fix here would be to add this note to the documentation. I do see the value in explicitly having a separated fixedStep and step method though.

Another gotchya is that even after enabling interpolation, it isn't enough to use body.position and body.quaternion, you need to use body.interpolatedPosition and body.interpolatedQuaternion

So even though the README recommends to use fixedStep(), it still isn't interpolated when it gets to driving the three mesh:

function animate() {
  requestAnimationFrame(animate)

  // world stepping...

  sphereMesh.position.copy(sphereBody.position)
  sphereMesh.quaternion.copy(sphereBody.quaternion)

  // three.js render...
}
animate()

Instead it should be:

function animate() {
  requestAnimationFrame(animate)

  // world stepping...

  sphereMesh.position.copy(sphereBody.interpolatedPosition)
  sphereMesh.quaternion.copy(sphereBody.interpolatedQuaternion)

  // three.js render...
}
animate()

This is likely why most users don't see interpolation. I can add interpolation notes to the README.

[marcofugaro]

It is confusing to me coming from engines like Unity which don't have interpolation on by default.

It is basically the same as using FixedUpdate from Unity, read the article I posted.

Another gotchya is that even after enabling interpolation, it isn't enough to use body.position and body.quaternion, you need to use body.interpolatedPosition and body.interpolatedQuaternion

Nah man, you're confusing yourself. This is not interpolation, this is just "catching up". It runs more internal steps to make sure the simulation is run at the same time across every framerate. interpolatedPosition won't have any effect because the steps are run subsequently.

interpolatedPosition and interpolatedQuaternion are used instead when the timeStep is much greater, for example in multiplayer physics. Check out the canvas_interpolation example, we're simulating a slow connection by making the timestep half a second.

For the default usecase, using .position and .quaternion is correct.

[krispya]

Thanks for talking this through. I have read the article a few times in the past but maybe I'm not understanding fixed loop properly. The issue as I understand it with all fixed step loops is that there is time banking necessary, there is always some time left over as a remainder because the steps don't evenly divide with dt. This remainder is what I am using to interpolate in my own loop.

Now consider that the majority of render frames will have some small remainder of frame time left in the accumulator that cannot be simulated because it is less than dt. This means we’re displaying the state of the physics simulation at a time slightly different from the render time, causing a subtle but visually unpleasant stuttering of the physics simulation on the screen.

One solution to this problem is to interpolate between the previous and current physics state based on how much time is left in the accumulator:

Is this interpolation factor not what is being processed in the lerp/slerp loop right after the while loop here?

cannon-es/src/world/World.ts

Lines 501 to 506 in 3877539

	for (let j = 0; j !== this.bodies.length; j++) {
	const b = this.bodies[j]
	b.previousPosition.lerp(b.position, t, b.interpolatedPosition)
	b.previousQuaternion.slerp(b.quaternion, t, b.interpolatedQuaternion)
	b.previousQuaternion.normalize()
	}

As I understand it, this time banking issue affects the smoothness whether it is catching up or not, it's not as noticeable if the frame rate is high.

[marcofugaro]

Is this interpolation factor not what is being processed in the lerp/slerp loop right after the while loop here?

Nope, it's referring to the .accumulator property:

cannon-es/src/world/World.ts

Line 479 in 3877539

this.accumulator += timeSinceLastCalled

Cannon has a max number of substeps the simulation can use to catch up, so we need to clear that time banking.

cannon-es/src/world/World.ts

Lines 496 to 498 in 3877539

	// Remove the excess accumulator, since we may not
	// have had enough substeps available to catch up
	this.accumulator = this.accumulator % dt

[krispya]

Ah yeah! I think we might be misunderstanding each other. All I'm saying is that the way the step loop is written, the interpolation will always run on every physics body using the ratio of the time remainder on the accumulator and the delta time (which will always be there no matter how many substeps run since rAF varies) even if you aren't using it.

But this is far off topic so I'll close the ticket. Thanks for the discussion.