#Making predicted physics faster

1 messages · Page 1 of 1 (latest)

cloud lichen
#

The test. Just 7 colliders, 6 static, 1 dynamic.
RTT delay: 80
RTT jitter: 12
Safety - off
Jobs debugger - off

image-1.png
#

before:

image.png
#

after:

image.png
#

About a 2x speedup, this required modifying entities, physics and netcode.
This was done by removing all sync points between fixed update frames.
The follow steps are just a proof of concept, I will flesh out what I think would probably need to be done to be production acceptable but others might have different ideas.

#

Entities

The simplest, need to get rid of completing the systems previous handle in BeforeOnUpdate.
This would obviously cause issues in a theoretical app that could cause infinite long dependency chains and would need to be addressed.
(My first thought of a solution is a system that runs at start of initialization that caches a handle of all dependencies from EM and plays it back 1 frame delayed.)

image.png
#

Physics

The primary cause of the problem where it hard completes the previous handle in BuildPhysicsWorld. This seems to mainly be because resetting world
world.Reset actually disposes and recreates nativearrays, for example

        private void SetCapacity(int numBodies)
        {
            // Increase body storage if necessary
            if (m_Bodies.Length < numBodies)
            {
                m_Bodies.Dispose();
                m_Bodies = new NativeArray<RigidBody>(numBodies, Allocator.Persistent, NativeArrayOptions.UninitializedMemory);
                EntityBodyIndexMap.Capacity = m_Bodies.Length;
            }
        }```
This stops it being used in a job as you can't dispose native containers in a job.
For this above demo my proof of concept only called this on the first tick which would prevent structural changes within the fixed step buffers (which seems like a terrible idea) however the correct fix would be to rewrite physics to use NativeList instead of NativeArray and reinitialize size instead of disposing. I already quickly test this and it seems to work but it would likely be breaking to users when accessing static/dynamic arrays.
#

Netcode

Netcode adds a final sync point after all this setting Simulate to true at the end of the prediction at the bottom of NetcodeClientPredictionRateManager. This is easy enough to fix by simply moving this work off main thread into a job.

image.png
cloud lichen
#

This probably concludes my experimentation with this
Do not follow the above steps, this is just a proof of concept. You should not do this yourself. I have not tested this remotely enough to find all the problems that will arise
(also please don't hound unity which sometimes happens when I post something like this. They are good at listening to feedback and actioning it especially the netcode team [they gave me change filters!]. if any action come from this it will take time, no one's just going to drop what they're doing because some loud annoying guy posted some crazy proof of concept on the internet.)

#

CMarastoni

We are optimising the physics loop to reduce the burden of this multiple simulation steps, but still requires some time and validation.
Posted like an hour ago. Wish that was posted a few days ago before I went all crazy~

cloud lichen
#

We recently investigated and started implementing physics loop improvement (they will be available in the future) that does not requires breaking safety or compromises logics.
We are had up to 3-5x speed up (even more in certain scenario). Usually that implies doing things only once (i.e building the physics world).