3D chat

[Canardia]

There is a slight delay anyway with the default character controller acceleration settings. I didn't notice any additional delay due to network lag, but only the normal physics acceleration.

[Scott Richmond]

There was a constant jitter for me and my 300 odd ping. I think what needs ot change is that the client should be assuming it got the physics right. In other words, don't ask the server that player x is moving here then update the client - Let the client tell the server where its going and wait for no one. Just have the server monitor the client movements and if they're outside of some magic tolerance level, pull the client back.

[Canardia]

Yeah, that's what I would improve too. I would also make the oildrums have collision enabled, and sync them not 10 times per sec, but maybe only 1-2 times per sec, or maybe even every 5 secs.

 

That would require that instead of using the character controller, you would replace it with a real physics body also, like a cube or cylinder. Then it would respond to physics forces more realistically, and doesn't need to be manually pushes around so much. The best would be of course to have a ragdoll physics body for the character.

[Rick]

There is a slight delay anyway with the default character controller acceleration settings. I didn't notice any additional delay due to network lag, but only the normal physics acceleration.

 

No, that was network lag. Create yourself a server and then move around. Then join another person server and move around. As long as the key press is being sent to the server and the server is doing the moving there will be that lag. If it's a 300ms round trip and if that's how it's being done, you will visually notice that. As long as the server is doing the movement and sending that movement back to the client there isn't any way to get around the sluggish feeling of movement.

 

I did just that, I think with version 15 or 14 and there was a difference and I only had a 110ms lag.

[Rick]

Yeah, that's what I would improve too. I would also make the oildrums have collision enabled, and sync them not 10 times per sec, but maybe only 1-2 times per sec, or maybe even every 5 secs.

 

That would require that instead of using the character controller, you would replace it with a real physics body also, like a cube or cylinder. Then it would respond to physics forces more realistically, and doesn't need to be manually pushes around so much. The best would be of course to have a ragdoll physics body for the character.

 

That's called client side prediction, which is what I've been saying is required. That basically hides the lag. The problem is that opens up a can of more issues to handle.

 

He tried updating the oildrums 2x a second and it didn't look right. Since the physics are being done server side, things on the client would sort of "snap" to a position sometimes.

[Canardia]

The client still does physics, but no collisions and no gravity. So all physics objects in the client always move in a straight line, until they get a new position from the server, then they move in a straight line to that position.

 

With collisions and gravity enabled, they would also move in curves, and probably wouldn't need much corrections from the server at all.

 

The only time they would need corrections from a server is when a player collides with the objects, but the player positions are done currently on a higher frequency network channel anyway, so it wouldn't matter how slow the objects are updated, they just do their own physics mostly.

[Rick]

If the physics objects are getting a new position from the server x times a second I assume on the client SetPosition() is called on these bodies? If that's the case then the physics is basically not happening on the client since SetPosition() basically kills physics from happening on bodies.

 

My guess would be that reducing the physics updating and letting the client handle the physics more would probably result in some warping or scenes not being in sync.

 

How you described is what I was doing for my MMO testing for player movement. The issue I had was that sometimes in the client I was able to get to places in the terrain from my local controller that the server wasn't able to get to with it's controller of my character. Sometimes when you have steep hills or valleys in the terrain. Since the server couldn't get to that place when it updated me every 5 seconds it would snap my client back.

[Canardia]

Of course it's not using SetPosition, but SetBodyForce. Else they would warp from place to place and stop, instead of smoothly moving to their place and continuing the movement when no command is given.

[Rick]

SetPosition() with interpolation would work the same way and I would assume be more precise than SetBodyForce().

 

What is being done when the server sends the update of where the body should be?

[Canardia]

It doesn't really make any sense to use SetPosition with physics objects (except for initial positioning before the game has started). Then you can use meshes as well. SetBodyForce works accurately, and moves the physics object to the wanted position. It doesn't warp it there.

[Rick]

So you would set the oildrums position to where the server says they should be by applying forces to them? I wouldn't think that would be exact enough.

[Canardia]

It is very exact, plus the position is just half of the truth, the server should tell also movement velocity and rotation velocity.

[Rick]

Do you know for a fact that's how Josh is doing this or are you saying that's how you'd do it? If applying forces and such is how Josh is doing it then I'll buy it because I'm seeing it and it seems ok, but if that's not how he's doing it I'm not buying that applying forces would give the exact positions.

 

If this isn't how Josh is doing it I'd love to see your idea Lumooja and see how it looks.

 

I think I would just do extrapolation and interpolation on the meshes on the client side.

[Canardia]

I don't know how Josh is exactly doing it, but that's how I imagine it is done, plus how I would do it with the collisions and gravity additionally, and the ragdoll player. The CalcBodyVelocity function is designed to position a physics body accurately, so why should it not do what it's designed to do? And last time I tried it, it worked fine.

[Niosop]

I think the server is doing all physics calculations and the clients are just interpolating between the last known position and the new position it gets from the server. So the client is basically just a rendering terminal that sends input to the server and gets back position information. One way to tell for sure. Connect to a server, then as the barrels are falling kill your network connection. If the client is doing any processing then they'll keep falling, if not they'll hang in mid air.

[Canardia]

They keep moving in straight lines and rotating, that's why I think they are physics bodies without gravity and collision.

[Rick]

I thought that's what he was doing. If that's the case there is no point in having bodies at all client side. Just SetPosition() on the meshes. Interpolation and extrapolation smooths things out. SetPosition() doesn't automatically equal jerkyness like Lumooja seems to think.

 

Lumooja, you were talking about applying forces client side before. I don't think that would be the way to do it. I agree with CalcBodyVelocity though. By interpolating client side you can smooth out the movemnet, and my extrapolating client side you can send less data and predict where they are going.

[Rick]

They keep moving in straight lines and rotating, that's why I think they are physics bodies without gravity and collision.

 

 

They do? Maybe he changed it. Last night when he shut the server down everything on my screen stopped. The oil drums weren't moving.

 

He's most likely doing a million different tests.

[Josh]

I need someone to create a server with the latest version. I am testing client-side prediction, and can only do it if I have a remote server with some latency.

[Rick]

This reminds me of a cool debugging feature you could implement into the network commands. Simulate lag.

[Josh]

I tried updating the controllers on the client side. The major problem with that is the controllers no longer influence any physics objects.

 

Client-side prediction did not have a good outcome. It resulted in "teleporting", which is something that really bugs me about networked games.

[Rick]

The problem is not having client-side prediction is basically not even an option. The games of today all use it and players expect instant feedback in any sort of game that requires it, ie FPS, RPG, etc. Something like an RTS you can hide it in various ways though. This is often why when you give an order to a unit it says something or plays an animation like a solute before it actually does the task.

 

To get it working correctly, you would need to use extrapolation for the other players on your client screen. Since you don't just want to set those players to the position when you get an update from the server, you want each client to guess where the other players are going based on where they were going before you got your last update. Then, when you get an update you see how far off is this player locally from where the server just said it was. That's where you interpolate between those 2 locations to smoothly move from where that player is to where the server says that player is over a few frames.

 

At one point player WoW I had 2 accounts. I would open up 2 windows and would put one toon on follow from another. I could see this happening. On one of my machines I would stop running and locally it was instant, when I look at the other machine you could see it catching up and interpolating to get from where it was to where the server said the other toon was. It was pretty interesting to see actually.

[Josh]

The problem is this leads to instant corrections when the client and server results diverge, which is very often if you have an interesting physics simulation running. This is why multiplayer games rarely have very advanced physics interactions.

 

You can create the player controllers on the client machines and let the clients dictate their orientations. This result would be the same as what you described above.

 

Alternatively, you can let the server control everything, if you are willing to accept lag on servers with bad latency.

[Canardia]

I guess the CalcBodyVelocity() and CalcBodyOmega() does not work accurately after all. At least I didn't get it to work with the Penumbra style picking up and floating models around very fast. I takes a while before the model is placed and rotated to the wanted position. If those functions would work accurately, I would need only one SetBodyForce() and SetBodyOmega() call to make the model be in the wanted position. Those functions would be needed also for networked physics, to interpolate the client's objects to the server's positions.

[Rick]

Alternatively, you can let the server control everything, if you are willing to accept lag on servers with bad latency.

 

I wouldn't even say bad latency. I had 110ms which is far from bad and the delay was noticeable. Adding this to a fast twitch game would only amplify the sluggish felling.

 

This is why multiplayer games rarely have very advanced physics interactions.

 

I couldn't agree more. We just can't have our cake and eat it too.

 

 

The problem is this leads to instant corrections when the client and server results diverge, which is very often if you have an interesting physics simulation running.

 

I would be curious to see extrapolation and interpolation ran on the barrels dropping to see how the clients handle it though. At 8+ times a second I wouldn't think it would be all that bad. With that you could have the physics happening on the server, it's just that the client's wouldn't really be able to have advanced interactions with it. They could perhaps start a physics effect, but interacting with the objects would be an issue.

 

It could lead to some cool gameplay stuff though. Say you shoot a ring holding a draw bridge. The joint breaks on the server and the bridge comes crashing down via physics that is being ran on the server.