[Question] Does physics rollback work for collision or overlap state?

[leozzyzheng]

I'm very interesting to this framework and want to use it to replace the NGO to implement client side prediction and rollback.

But my game is heavy physical game, so there will be many physical states need prediction and rollback, I see there is a prediction option in Netick, so I'm curious whether the collision or overlap state could be reconciled when I rollback?

I read document of PhysX, only sync transform to rigidbody will result an invalid physical state: https://nvidia-omniverse.github.io/PhysX/physx/5.1.3/_build/physx/latest/class_px_rigid_dynamic.html#:~:text=virtual%20void%20setGlobalPose(const

which means if I rollback a rigidbody to make it teleport inside another rigidbody, it won't report collision enter or stay event.

Does Netick solved this problem?

[karrarrahim]

Does Netick solved this problem?

This problem is outside the scope of the networking solution. You can't control how PhysX engine invokes the collision callbacks. It's not possible to do anything about this problem.

However, you can implement your own Enter/Exist callbacks using physics queries to ensure they work as expected. That's what we recommend for accurate collision callbacks.

I'd like to point out that PhysX is not designed for multiplayer. It performs very poorly when simulated multiple times in one frame. It's not usable for high numbers of rigidbodies. This is why we want to integrate a third-party physics engine for better rollback and simulation performance.

[leozzyzheng]

@karrarrahim Thanks for the quick reply.

I found scene queries also can't implement prediction when there are more than two moving rigidbodies collision with each other. So I'm looking into some 3rd physics engines like bullet or UnityPhysics, do you have a better recommended one? Thanks in advance!

[karrarrahim]

There are many others, such as Bepu and Rapier. Bepu requires .NET Core to perform well, so it's only a proper option after Unity switches from Mono to .NET Core runtime.

Prediction works fine with rigidbodies with PhysX. It's only a problem with collision callbacks. I am not sure of what scenario are you thinking of that will not play as expected, or why you need reliable collision callbacks.

If you are thinking of a complex situation, then it's always going to be difficult to network those. Rigidbodies take a lot of bandwidth to sync, so it's not even feasible to sync many of them together. 10 and more, and they use a ton of bandwidth. This is because, in addition to position and rotation, you are also syncing velocity and angular velocity. All of these variables change every tick and need to be sent.

Bit-wise determinism with input sync is the better model for physics-based games, not state-sync. Because with determinism, you only need to sync player inputs, not object states.

[leozzyzheng]

@karrarrahim Thanks for the advice. I'm developing a network game with high quality physical performance. Each collision with player input has a big impact of game play.

Prediction do work fine with PhysX, but in network game, I need implement Lag Compensation so I need apply the client input to history on server, which means I need rollback the whole world to achieve this. The rollback is the problem I'm thinking.

Collision is very important in my gameplay, if I missed collision when I rollback the world on server, then result might be much different between server and client prediction, that's why need reliable collision callbacks or queries.

I'm looking into the Bullet physic engine and it can save and restore the physic world state, seems every fit to my requirement.

[karrarrahim]

Oh, so you are talking about rewinding on the server for lag compensation?

This is not a problem. You can easily record the states of each object in the server for some duration of time, and then simply look up the view of the client when performing lag compensation. This is a non-physical operation, it has nothing to do with collisions. The server "rollback" is a sort of a look-up, nothing more. There are many resources on how to do this.

We have already implemented all of this in Netick. Doing a lag-compensated raycast is as simple as Sandbox.Raycast. However, lag compensation is not included in the free version of Netick.

[leozzyzheng]

@karrarrahim Sounds cool! May I ask more detail about how Netick implement it?

Thinking this timeline:

Frame N, ball is outside a box. Frame N + 1, ball is inside box, OnTriggerEnter called. Frame N + 2, ball is moved away, OnTriggerExit called.

If current frame is N+2, and I need rollback to frame N+1, then how Netick restore the overlap state? Or it need myself to write down the state into my component?

[karrarrahim]

Sorry, I don't understand how this relates to what I said.

Typically with lag compensation, you don't care at all about collision callbacks, as they don't relate to the problem being solved. Lag compensation != prediction, they are completely different things.

Are you trying to confirm in the server that the client correctly pushed the ball inside the box, to ensure server-authority?

If so, you don't need to do anything to solve this problem, at least not with Netick. Because in such a game, you would be predicting the ball in the client. The server would execute the inputs of the client as they come to produce the same results as the client prediction (if the prediction was correct, which it will be if only one client hits the ball at the same time), and the game would be completely server-authoritative without additional work. No lag compensation needed.

[leozzyzheng]

@karrarrahim Yes, I'm trying to confirm the client prediction on server.

The server would execute the inputs of the client as they come to produce the same results as the client prediction

Server need rollback to history state because the client input happens in the past, so I think it is something related to lag compensation.

Let's say Client generate the input at Frame N, server also run at Frame N. The input may arrive at Server at Frame N + 1, then server need use world of Frame N to apply the input.

Then problem is, the physic state can't be fully rolled-back to Frame N, such as collision state might be invalid if I just rewind the position of rigidbody.

This is indeed another part of the network game, not directly related to Netick, it's very nice that you can discuss it with me, feel free to close this topic if I spent too much time of you :)

[karrarrahim]

Server need rollback to history state because the client input happens in the past, so I think it is something related to lag compensation.

In Netick, the client runs ahead of the server. So when the input of the client comes in the server, it comes at the time it's needed, it's not considered old in the server. This is because all of the hard work is done by the client.

Therefore, the server does not do any rollback or lag compensation (for this particular example). The game, in the server, runs like it's single-player.

The problem you are talking about is completely solved, by default. We have a full Rocket-Leauge-inspired game sample made with Netick coming soon, demonstrating the exact mechanic you are talking about. No lag comp is needed. The code of the game is actually very close to single-player games.

This is indeed another part of the network game, not directly related to Netick, it's very nice that you can discuss it with me, feel free to close this topic if I spent too much time of you :)

No it's fine. You can also join our discord server to discuss this further or with other users :)

[leozzyzheng]

@karrarrahim

In Netick, the client runs ahead of the server. So when the input of the client comes in the server, it comes at the time it's needed, it's not considered old in the server. This is because all of the hard work is done by the client.

Will server correct client wrong prediction? I think there must be some cases that server will simulate a different result than client, such as two client catch the ball at the same time. How client reject the already simulated physics state?

[karrarrahim]

The client is being corrected all the time. It will be quite rare for this to be mispredicted in a visually bad way.

This is nothing to worry about.

[leozzyzheng]

@karrarrahim One more question, if Client run ahead of Server, it means the Client run 0.5*RTT ahead of Server, so Client A send input to Server and dispatch to Client B 1*RTT later, Client B get 0.5*RTT old Client A's position which might be different with prediction, what position will be shown on Client B? The Client A's server position + prediction movement?

[karrarrahim]

Yes. It will work as expected, if players don't change their inputs, the game will be perfectly synchronized, without any mispredictions. Mispredictions are mostly caused by the inability to predict the inputs of other clients.

[leozzyzheng]

Yes. It will work as expected, if players don't change their inputs, the game will be perfectly synchronized, without any mispredictions. Mispredictions are mostly caused by the inability to predict the inputs of other clients.

@karrarrahim So if Mispredictions happens, lets say Client A shoot to the mistake position of Client B, Client B jumped away at this frame, then Client A will see the shooting doesn't do any damage to Client B?

I see a lot of articles like OverWatch and RocketLeauge GDC presentation, they all do a rollback on server to make Clients can more easily shoot what player see on its client. Do you think it's required for the network model you described?

[karrarrahim]

I see a lot of articles like OverWatch and RocketLeauge GDC presentation, they all do a rollback on server to make Clients can more easily shoot what player see on its client. Do you think it's required for the network model you described?

Only FPS games do server "rollback", which is just rewinding to client view for bullet hit-detection. Physics-based games don't do that.

Rocket League does not do that at all.

Here's an article we wrote recently that explain prediction in a bit more detail: https://netick.net/docs/2/articles/prediction-in-depth.html

I am going to close this issue. You can join our Discord server for further discussion: https://discord.com/invite/uV6bfG66Fx