Dead Reckoning

1. Dead Reckoning • Objectives – • Understand what is meant by the term dead reckoning. • Realize the two major components of a dead reckoning protocol. • Be capable of identifying appropriate circumstances in which dead reckoning may be used.

2. Dead Reckoning – benefits and drawbacks • Without dead reckoning • Hosts display positional information when they receive state update messages (centralised server, de-centralised server or peer – frequent state regeneration). • With dead reckoning • Hosts may approximate the position of entities based on information held locally. • Benefit • Less message passing required to update an entities state across all hosts of the virtual environment. • Problems associated to jitter and lag are compensated for. • Drawbacks • Hosts may not share a mutually consistent view of the virtual environment.

3. Network – some background information • Bandwidth – • The rate at which the network can deliver data to a destination host. • Typical (new) Ethernet provides 100 Mbps (100, 000, 000 bits per second). • The more complex a virtual world is the more bandwidth is required. • Latency – • The amount of time required to transfer a bit of data from one point to another. • LAN latency may be less than 10 milliseconds, transcontinental connections may be 60-100 milliseconds and intercontinental connections may be over 200 milliseconds (taking the Internet as an example). • To ensure successful interaction the latency should not exceed 100 milliseconds (200 milliseconds delay overall).

4. Example – network requirements • 20 hosts each connected in a peer configuration using frequent state regeneration. • Each host is responsible for 100 animated entities (2000 in total virtual environment). • Each entity requires position vector information to be distributed for a frame rate of 25 frames per second (assume this information may be carried in 3 eight bit word lengths – we ignore packet dependent data here). • 24 * 2000 * 20 * 25 = 24, 000, 000 bits need to be distributed per second (bandwidth 24Mbs). • Assuming computational requirements are around 5ms for each frame, then latency must be less than 1000/25 – 5 = 35 milliseconds.

5. Dead reckoning – predictive modeling • Assume animation at 20 frames per second and the ability to only receive update message for the above plane once per second. • If an update message indicates the velocity/direction of the plane then we can approximate its position at t2 given initial location at t1. t1 t2

6. Throughput consistency tradeoff h1 • Predicting position may lead to an inconsistency in views of the plane’s position. • Since the last state update message the plane may have changed direction. • At the host (h1) where the plane is managed the updates would be made in real-time. • At the remote host (h2) receiving the update information the plane would be positioned using out of date information. h2

7. Convergence h1 h2 • Prediction is one aspect of a dead reckoning protocol. The other major element is convergence. • When update messages are received that indicate the plane at h2 has moved away from the true flight path (as dictated by h1) then we must move the plane of h2 to the latest known correct position of the plane (as dictated by h1). • Jumping to the new position presents an unnatural animation. • A gradual correcting of the plane’s path is used to move the plane of h2 into a more appropriate position. Convergence point

8. Derivative polynomials • Common dead reckoning protocols use derivative polynomials. • Zero-order polynomials – use entity’s instantaneous position but does not use any derivative information. • This is equivalent to frequent state regeneration. • Predicted position after t seconds = position • Order one polynomials – use velocity in calculations. • Predicted position after t seconds = position + velocity x t • Second order polynomials – use velocity and acceleration. • Predicted position after t seconds = position + velocity x t + ½ x acceleration x t2 • Second order polynomials are most popular. • Used in military simulations.

9. Which polynomial order? • Second order polynomials may appear to present more accurate prediction. • They are more computationally expensive than order one polynomials. • They may not be better at predicting position. For example, acceleration may be changing frequently making this parameter almost useless in calculations. • It may be wise to allow a choice of which polynomial order to use on a per entity basis at run-time. • This provides the greater benefit of lowering bandwidth requirements while aiming to preserve as much consistency as possible.

10. Prediction without polynomial prediction • Sometimes polynomial prediction is not appropriate. • For example, a tank traveling down a road or a particular maneuver carried out by an aircraft. • In the above examples we can predict the movement of an entity by identifying some preset maneuver that an entity will be participating in for some time. • This makes prediction a little easier. • Sometimes polynomial prediction in 2D will suffice for 3D environments. • This is especially the case when objects are traveling along the ground.

11. Convergence methods • Zero order (snap) – Immediately correct the prediction by immediately moving an entity to the latest known position (as described in a state update message). • Quick and easy. When large corrections are required an entity may appear to jump around the screen. • Linear– identify convergence point as some point in the future on the latest predicted path and linearly animate an entity from its current position to the convergence point. • Better than zero order when large corrections are required but may still promote unnatural movement as entities suddenly change direction. • Cubic spline – construct a third order curve to smooth the animation between current entity position and convergence point. • Computationally expensive (depending on the smoothing of the curve – how many intermediary points are used). • Problem – What if is there is a collision as a result of convergence?

12. Non-regular sending of state update messages • Sometimes the frequency of receiving state update messages may vary. • This is particularly true over long haul networks where message delays are variable (e.g., between 50 and 200 milliseconds). • Variable delay results in more inconsistency. • If a message is sent once every second then there could be instances when messages are received in quick succession or substantial gaps are witnessed between the receiving of messages. • Furthermore, this inconsistency may be variable on a per network link basis, the message latency times between a sender and different receiving hosts may vary quite substantially. • A method to overcome this problem would be determine the sending of a state update message based on a judgement made by the sending host. • Such a judgement is made on the state of the virtual environment as viewed by a sending host.

13. Non-regular transmission Remote prediction error • Only when the plane exceeds the predicted error bound will the host that owns the plane send a state update message. • If the dead reckoning algorithm is very accurate there may be no need to send a message again! • To prevent this (and help distinguish failed hosts and enable initialization on other hosts) there is a maximum time set as to when a host may not send a state update message. Predicted flight based on last state update message sent (as modeled by sending host – owner of plane) Actual flight as modeled by sending host (owner of plane)