[dustbunny]

Hey Glenn, what do you mean by 'rollback determinism'? Is there some particular thing missing from Box3D now that makes it difficult to synchronize with solely the inputs?

My reading of Box3D's docs is that it has 'cross platform determinism', and 'recording/replay'? Isn't that sufficient?

Synchronize inputs, determine if inputs were 'mispredicted', if so, rollback the physics world, apply the changed inputs and resimulate?

Just for context: I implemented state-sync netcode into box2d in 2018 and shipped multiple real games using it - and I work on netcode professionally.

I'm planning on adding full netcode support for box3d and releasing it as part of a larger framework.

https://box2d.org/documentation3d/md_simulation.html#autotoc...

[gafferongames]

Hi! Rollback determinism is a term invented by Erin Catto here:

https://box2d.org/posts/2024/08/determinism/

Physics engines like Box3D have a significant amount of internal state and caching, like contact caching, and other things to speed things up.

I've talked to Erin a lot about stuff like: "Hey, what if I want to do an FPS or a vehicle, but I want to roll back only the character or vehicle, like in an FPS?"

From these discussions (and many other inputs I'm sure) Erin has had a big think about determinism, and come up with his own determinism and replay stuff.

In the article he uses the term "rollback determinism" to mean you'd be able to synchronize (or at least invalidate) any of this caching so that it doesn't affect the way the simulation replays if you were to rollback the simulation fully and then change the state only for a few objects.

For example, if you were to rewind and replay a physics simulation just for say the player predicted object like a vehicle and any objects that it happens to touch, expanding these objects out recursively as they touch other things.

Or if you were to do rollback on the player controller like we normally do in FPS, and the player started predicting a physically simulated door they push into, and then any other object the door pushes and so on, this sort of thing.

This should not affect you if you only step the physics simulation ahead with inputs, and do the GGPO thing where you copy fork, and step that sim ahead with predicted inputs, throw away, copy fork and predict again... that's already deterministic today.

cheers

[dustbunny]

I see. This helps a lot thank you.

Thank you for your time. I respect you deeply and have valued your work.

For box2d, in the past I added a function to delete the entire contact cache and then I experimented with either calling that every single frame on both client and server, or only during a rollback.

In one game, I did the former and in most others, I did that latter.

In those box2d games, the entire world was predicted/resimulated, including remote players. A smart smoothing technique was used on remote players to dampen network artifacts. It worked well, even sniper rifles worked well. (The player movement had a certain flavor)

I am currently building something custom on top of Jolt, but will experiment with box3d.

The smart detection of what needs to be resimulated is something I'm just about to start on.

My mind is turning on how partial resimulation could be done on top of box3d's 'keyframe' recording system....

[gafferongames]

That's awesome!

[gafferongames]

OK I chatted with Erin, he says Box3D doesn't have the ability to clone a world yet, but he does plan to add it. So maybe reach out to him. I think you'll need the clone a world functionality to do the rollback properly GGPO style.

[dustbunny]

Awesome, thanks for engaging with me and talking to Erin about it.

I hacked together world cloning in box 2d and am confident I could do it in box 3d as well. Especially with the record/replay/validate system to help guide the implementation.

I'll find a way to send you and Erin my project when I get it working (or when I fail)