The key problem is to make calculations to happen in multiple concurrent threads during fixed update period - result of computations is a set of force-vectors that has to be applied to the rigid body during the same fixed update step. My current basic idea is to get some object to be fixed-step invoked before everything else, spawn a thread for each job, and join the threads. But it’s complicated by the fact that FixedUpdate doesn’t actually runs at a set frequency, but called an appropriate number of times before Update to simulate set frequency, which means that its timing is irregular. And further, I can’t seem to find a way to force specific execution order, i.e. master object first and slave objects second. Anyway, does that even matter? Can I just apply forces from whichever object happen to carry out fixed step? Only having master object to have FixedUpdate guarantees that it’s executed first. From what I imagine, it only matters because FixedUpdate runs at a different rate than Update, so outside of it you’d be applying too much/not enough force per unit of time, and at unsynchronized moments, compared to the rest of physics interactions.
I’m making a boat racing game, and that includes water physics. I decided to go full autistic with this and to deploy actual buoyancy simulation. The code calculates underwater mesh surface and applies realistic forces to the boat hull. The problem is, computations aren’t exactly cheap, has to be carried out for every boat, and due to dashing nature of the gameplay, fixed update will have to run at high rate. So I expect it to tank performance. The way around it is to get the expensive calculations to be carried out in their own threads, thus reducing performance impact.