#Netcode prediction resimulation ticks buildphysicsworld

1 messages · Page 1 of 1 (latest)

shy skiff
#

I've been looking at netcode and observing the heavy performance cost of lag with prediction and resimulation. With 70ms ping, I have over 10 ticks of resimulated prediction. Each comes with its very own build physics world job lasting 0.5ms (bursted) in my very light test scene.

What is the purpose of running build physics world 10 times here... I have no physics step, I'm just using physics for the casts. Can't it just build once and then step through all prediction ticks from that one BuildPhysicsWorld?

#

Ah, the answer is because things move 😐 and you have to rebuild colliders the bounding volume hierarchy and stuff so queries work...

#

does anyone else feel like this is basically a deal breaker for netcode and physics? I can't get over this physics world + prediction cost 😢

#

I am literally trying to redesign my game to either remove physics or prediction 😐

shy skiff
#

(am I over-reacting lol)

balmy wraith
#

Either do the casts manually or not use predicted physics. If you make everything interpolated, clients will not have any physics and there won't be any repreated ticks

honest blaze
#

I think official still need to further improve performance for this area

honest blaze
shy skiff
torn sequoia
#

Yeah, we do know and agree that predicted physics can be costly, especially the rebuild phase.
It is possible to do some optimisation already, but that requires modify the Unity.Physics package and partially the Netcode for Entities package to avoid these costs.
You still need to update the AABB tree though, otherwise collision will not be reported correctly.
There are tread-off possible in that space, that depend on a game-by-game basis.

honest blaze
#

Btw is that any plan for official to make prediction not affected by ping meaning higher ping will higher cost? From my testing at mobile phone, it's very costly.