Re: The updating of an entity (Server to Client)

Discuss any questions about BEPUphysics or problems encountered.
Post Reply
jaja1
Posts: 43
Joined: Sat Nov 15, 2014 3:27 am

Re: The updating of an entity (Server to Client)

Post by jaja1 »

Up until this point in my server I have been getting the positions of certain entities to be updated in my client and sending them about 60 times per second. Since the entity follows a path using BEPUPhysics' path following utilities the server tells the client when to update the entity's position. However, when updating the position of the entity on the client I have noticed a somewhat jittery movement.

I do not believe it is lag because my player moves smoothly and is updated many more times per second every time he/she sends a movement request! I am using a Vector3.lerp between the last known position of the entity and the new position sent by the server. I am using Unity3D as the client's engine.

Would you say this is the most efficient approach from a general standpoint as well as from BEPU engine's standpoint?
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: The updating of an entity (Server to Client)

Post by Norbo »

First, I would check if it is network related by running the client server on the same machine or over a LAN. If there's still a lot of visible jitter, it's probably not the usual network issues. Some options:
1) Make sure the client and server are actually updating at the same rate (make sure the client and server both have enough compute power to actually simulate at full speed).
2) If Space.Update(dt) is used, the engine will take a variable number of time steps of length Space.TimeStepSettings.TimeStepDuration per Space.Update(dt) call to keep up with the accumulated time. So, one Space.Update call might do 0 substeps, while another might do 2. This can cause slight jitter. The solution is to either use the engine-provided interpolated states or to call Space.Update() without a parameter to execute a single time step, leaving the time management up to you.
3) Make sure there aren't other clientside timing or performance issues causing apparent jitter.

If it's actually network related, note that even with many packets sent per second, 'lag' can still cause noticeable jitter and bad behavior. When using raw UDP as the underlying protocol, packets can be reordered, duplicated, lost, or just delivered at inconsistent, jittery intervals. Each of these issues need to be dealt with for things to work well, since each one can cause noticeable problems all by itself.
-If state update packets get reordered, the game may process the state for time T AFTER time T+1, causing the object to warp back and forth.
-If a state update gets duplicated, the game may try to process the same state update more than once, causing a hiccup.
-If a state update gets dropped, the effective interval between state updates lengthens. For state updates in particular, this typically isn't a huge issue so long as the client can fill in the gaps (with interpolation or simulation or whatever).
-If the pingtime jitters, the client's view of the server's simulation will be extremely jerky. This can feel really, really bad. Depending on a game's netcode, a connection with an average ping of 50ms and constant jitter from 25 to 150ms can feel significantly worse than a connection with 200ms ping and zero jitter.

Reordering and duplication are pretty easily solved for state updates by using message sequence numbers or something similar, but dealing with delivery jitter still requires some dedicated effort. I'm not entirely sure on the details of your smoothing method (interpolating between the last known and latest state might be a good idea, depending on what exactly that means), but there are definitely methods of smoothing which turn out acceptable. In the worst case, there's always the option of jitter buffers, though these require some fixed delay on the client and introduce significant complexity. (I typically just accept the full physical state immediately and hide the graphical discontinuity with exponentially decayed offsets or springs, depending on the object.)

BEPUphysics itself doesn't have a lot to say about this. Pretty much all the stuff you'd find in, say, the gafferongames.com series applies. (The only caveat being that deterministic lockstep networking is generally not worth it with BEPUphysics except under very specific circumstances.)
jaja1
Posts: 43
Joined: Sat Nov 15, 2014 3:27 am

Re: The updating of an entity (Server to Client)

Post by jaja1 »

Thanks Norbo! That site and your advice was a great help. I managed to some what curb the problem. I will keep working at it to get it just right.
Post Reply