How much can I safely subvert the default physics systems?

I have a project that runs on a fixed timestep using Unity.Physics. The fixed timestep necessitates interpolation on Update(). An earlier version of this project had the following flow:

Frame Start -> Write old non-interpolated physics data to entities -> BuildPhysicsWorld -> Step PhysicsWorld -> ExportPhysicsWorld -> Write entity positions based on interpolation between last two physics steps. -> Repeat

In my reimplementation, I realized it didn't seem to matter if I disabled ExportPhysicsWorld entirely and wrote the interpolated positions directly. Of course, on the next frame, BuildPhysicsWorld picks up this interpolated data, so I'd still need to either not run it or replace the positions before it runs. I thought about having distinct simulation and presentation worlds, but that's just a bunch more copying entities around and maintaining world synchronization.

Additionally, I noticed that if I applied my tick's changes to the physics world directly, then stepped it manually, it seemed to work fine for my simple simulation. I'm curious to know when this approach breaks down and I need something from the default systems to repair it.

With the above context, my questions:

1. To what extent can I safely/accurately manually manage my physics worlds? At a glance, it seems like if I don't add any new bodies, I can safely manually modify and simulate an existing physics world without needing to rebuild it.

2. When do I actually have to reset my SimulationContext when calling StepImmediate? Every tick? Or only when I change something specific (add a body, change a mesh, etc.)?

For the record, I've looked at what the existing systems do, but I'd rather not miss something and hunt down a "why doesn't my physics work right" bug later if I can avoid it. Maybe it's silly to reuse stuff from a stateless physics system from tick to tick, but it seems like doing so lets me do only the work that's applicable to my use case.

 

1. Yeah, if you are not adding/removing bodies, all you need to do is rebuild the dynamic BVH of the PhysicsWorld, and you can achieve that via SimulationStepInput.SynchronizeCollisionWorld (it will update at the end of the step). You can check the https://github.com/Unity-Technologi...mples/Assets/Demos/6. Use Cases/ImmediateMode sample, it does use immediate stepping interface but the logic is the same, dynamic body BVH is the only thing that you need updated in this setup.
2. Unfortunately you need to call Reset() every frame regardless of the changes to number of bodies. The reason is that it also flushes event streams, and that needs to be done regardless. It won't do any other work if you don't change the number of bodies, so it should be safe for you to do before each step.

 

Thanks! That'll all work out fine, though I'm looking forward to having a public job for ScheduleReset so I can chain my steps when needed!

This all got a little dicey when it came to knowing entity indices in the old physics world I'm interpolating from, but I'm just caching them and it seems good. Hopefully the upcoming official fixed + interp solution will just take all this nonsense out of my hands.