BEPUphysics

Hi Norbo,

First thank you for your time and for this great piece of sotware called Bepu!

In my network game, I receive the players' position and in order to move them I need to use forces to avoid teleportation of objects. I use prediction in server's side, thus, the position that arrives to the client is very near to the actual position, and my objective is to put the objects in client side as close as posible to this position and doing it smoothly.

Right now I am using a linear motor to move them to their new position, it works but it creates excesive lag. I am trying to adjust the travelling time of the object to the latency of the network, adjusting the damping of the spring, but it is very difficult and my results are not very good.

Any idea on how to move an object to a known position using forces and in a known time?

When it comes to network updates, I typically just snap the object to the new state immediately by setting the position/orientation/velocities/input to whatever the server sent. It's true that this sort of teleportation can have nasty effects in some cases, but it actually tends to work pretty well for network updates because the source of the update is a valid simulation. Provided the remote simulation isn't allowing things to tunnel through walls, the received states will be reasonable.

If the game often has objects sitting on other moving objects, it may be a good idea to make the update packet relative to the support. So, even if a character is on a moving elevator, the character won't pop beneath the floor. This mitigates the need for physical correction since the updates don't frequently cause invalid states.

Using forces to do correction will run into quite a few problems due to their physical nature and the nonphysical nature of the underlying network issue. CharacterControllers, for example, have constraints which will fight the corrective forces because they don't want to slide.

If the appearance of teleportation is too jerky, the objects can be rendered with graphical interpolation. Source games use this. Physical state interpolation may also be workable, but intermediate states may be nonphysical, and delay in reaching the new state increases the chance that it is invalid.

However, in my experience, a game with good update prioritization and action-game-level bandwidth budget can get away with no smoothing at all. It might not be as smooth as it could be, but it seems perceptually acceptable and is much simpler.