Compacting/Changing Body Ids for deterministic ordering

[JonECG]

First off, thanks Jorrit for all the great work you've done with Jolt and all the help you've given to the community. It's a really cool project!

I've seen in the docs and in the discussions, mentioning approaches for deterministically getting state consistent over the network. So another one for the pile.

As a game/simulation goes on, with bodies being created and destroyed, the body vector can become sparse. So if a client were to join/rejoin later on, even if they know the order to create bodies, the body ids will not line up. And they will also need any cached contacts. So the guidance I've seen is something along the lines of

1. Network non-jolt state of the runtime for the start of the tick that the client is joining (in my case, entity ids and other inputs)
2. Network the authoritative body ids, and how that might map to your own runtime state
3. Reconstruct the physics system using combined runtime state (orientation, velocity, shapes, materials, layers, etc) and creating with the preallocated body ids
4. Network the SaveState with EStateRecorderState::Contacts for the same snapshot
   (omitting constraints)

But theoretically, I could see us getting around the need for actually sending body ids if the runtime input alone is enough to determine which bodies should be created, in a deterministic order, if we had a way to remap the bodies to the bodies as if we were to allocate them in order from a blank slate.

I imagine this would need to happen before sending off the SaveState or running the physics system update for all clients and server. What isn't clear to me is how much of a perf hit this would be, and maybe likely isn't worth a continual cpu cost to make a one-time network save on join. But I could potentially see this benefiting shared authority or p2p games where there may not be as clear of a centralized authority for body id creation.

I'm still pretty new to the codebase, so my apologies if I'm a bit ignorant.

[jrouwe]

Network the SaveState with EStateRecorderState::Contacts for the same snapshot

There is more state than contacts. E.g. the bodies store information to determine when they can go to sleep. Constraints store information about the previous update that is used in the next update. Failing to send this information will make the simulation go out of sync.

Reconstruct the physics system using combined runtime state (orientation, velocity, shapes, materials, layers, etc) and creating with the preallocated body ids

Position, orientation and velocity are part of the state, so SaveSate should sync that information. You only need to set the things that are not modified by the physics update (shapes, materials, layers etc.).

if we had a way to remap the bodies to the bodies as if we were to allocate them in order from a blank slate.

Several things are keyed off the BodyIDs that would need to be updated when reordering bodies (e.g. the contact cache). I don't see the advantage of doing that and I would recommend to send the BodyIDs in the initial state message and using BodyInterface::CreateBodyWithID to ensure that a body with the same ID is created on the other side. This also makes it very easy to call PhysicsSystem::RestoreState as that too uses the BodyID to figure out which state goes where.

[JonECG]

Thanks for the info! I had oversimplified and overlooked some of the body state as you mentioned.

I suppose to avoid digging too deep into a potential xy problem I'll back up and mention that I'm trying to see if there is a way to remove the idea of a single peer in my networked game as a central body id authority. In my case, from a given runtime state I can determine what bodies would need to exist, and could deterministically assign a given order to them.

Currently I've been prototyping this approach by just having each peer create the physics system and bodies from scratch at the start of every tick predict/reprediction, aware that I'm doing very very awful things by doing this. But I had the idea that if all peers were able to actually remap the bodies to the body ids as if they were being freshly allocated in the order a fresh client, then they could all separately resolve to the same body ids and ordering without actually having to send some authoritative body id mapping.

For now, I'll elect a single runtime to be the id authority. But I might tinker around to see if I can get something working with the approach above to potentially see how awful it might be on performance

[jrouwe]

I'll back up and mention that I'm trying to see if there is a way to remove the idea of a single peer in my networked game as a central body id authority. In my case, from a given runtime state I can determine what bodies would need to exist, and could deterministically assign a given order to them.

For the initial state I think you have to rely on sending IDs, but once you're in sync then you could use an algorithm to determine the next ID in a consistent way across clients. E.g. pick the smallest ID that is not used yet (or has been freed). The problem is that if there's no single authority then who is going go guarantee that everybody receives the bodies to add in the same order so that you can consistently create these IDs?

Currently I've been prototyping this approach by just having each peer create the physics system and bodies from scratch at the start of every tick predict/reprediction, aware that I'm doing very very awful things by doing this.

Yes, this is indeed not very good and will result in very poor performance as you completely need to rebuild/optimize the broadphase every frame.