Virtual environments are illusion business. VE software is developed to give user immersive experience of virtual environment. What occurs on system and network level is different from what user experiences and this is especially true for networked virtual environments. Typical example is smooth movement which requires minimum of 30 frames per second in perfect synchronization. Our brains are sensitive for small deviations from the mean and this makes it challenging to offer perfect experience of movement. We can send updates of object locations, orientations and animation states only every 250 ms to 1000 ms due to limited network bandwidth. Not nearly enough for animation use. Furthermore network induces random time delay jitter in the chain of network packets.
This brings us to the illusion business. Peers send object states and network layer relays them on best effort basis. It becomes our role as the illusionist to use this information as well as possible to create illusion of smooth movement to the user. We have to accept time delay and jitter between object action at remote peer and materialization to our user. Any issues with this principle should be argued with Einstein. Our less than perfect virtual environment software and network hardware induce some delays as well. Considering these delays and jitter it is a good guess to say that delay between two peers is anything from 50-500 ms (250 ms on average).
50 ms is hardly noticeable where as 500 ms can be very disturbing in movement and reactions to control commands. Another example of immersion lost is a situation where user observes that a collision should occur but one or both objects are mislocated due to time delay. Subsequently they pass by without touching each other at remote peer which is executing collision detection algorithms. With higher speeds and smaller sizes the collision detection dilemma grows more sensitive to delay. Leaving the collision detection to clients does not remove this problem as the two clients will then reach different conclusion and at worst case one of the object receives collision impact whereas the other one handled by another client continues without impact.
In MXP architecture participant handled collision detection will simplify many things as the party who is in charge of the object will do the collision impact decissions. On the other hand it will double the problem mentioned in previous chapter. It is a tough decission whether to use bubble or participant based collision detection. Resorting to bubble collision detection would in practive require giving bubble the role of movement controller altogether. This may not be a bad thing in situations where bubble needs to centrally enforce fundamental laws like gravity. Untrusted peers is a real problem and giving the coordinating entity some powers to enforce agreed laws sounds like a good thing to do.
Movement prediction can be done in many ways but some fundamental things remain the same. Correct character location is received say every 200 ms and everything else is more or less guesswork. The most accurate result can then be achieved by forming path of these received correct points. After the path is formed it can be followed at best the fundamental 250 ms time delay behind the actual location at remote peer. This will give us 50ms jitter buffer. Higher time delay deviation will immediately be reflected to the movement user experiences. Another crack in the immersion is the angular path which can be replaced with smooth curve for better illusion of smooth movement. Smoothing will not add accuracy but will likely deviate the path further from the real object path occuring at remote peer. Smoothing can give user better experience and that is what counts.
Walking animation synchronization is like lip synchronization. It has to be exactly correctly executed to achieve immersive effect. Any deviations will cause moonwalk or skating effect. Due to this it is not possible to synchronize a walking animation from a remote peer which owns the remote walking character. Best what the remote peer can do is to state which animation should be played when the character moves in given speed range. Typical solution in modern games is to let the lower body follow the motion trajectory and match the step speed to the movement speed seen by the user. Upper body and head can follow the most recent attention direction received while hands follow the walk rhythm. This will give the user perfect walking synchronization and current attention direction.
