Motion

Overview

In a shared multiuser environment participants must see each other react and act as if they were physically present. The closer we model the physical world, the better the shared experience will become. One of the major points about the physical environment is its dynamic nature. Motion comprises one of the most important components of this dynamicism. In an active space, things move. We limit ourselves to providing only moving avatars for now. Future versions of our work may support more types of moving things.

Actions

Two fundamental types of operations occur in our motion solution. First, the client updates a centralized server for a space about its position and orientation in that space. Second, the server sends information to each client about that clients neighbors. The motion server and client use IDs from the ID Server to identify clients.

Client Updates

The client sends updates to the server containing the client's current position in the space and its current orientation. These updates are sent on a periodic basis. If lost, the server will just get the next update.

The client update also contains information about the horizon and number of updates that the client wishes to receive, these are used by the server as a guideline for optimising use of bandwidth.

The client normally will signoff with the ID server by sending SetID(INVALID_ID) to the ID server. The ID server tells the motion server that the client logged off. The client should also tell the motion server that it logged off by sending an update with the orientation set to all zeros. Note that the position does not have to be zeros. The motion server will try to notify the id server that the client signed off.

Neighbor Updates

The server sends neighbor updates to clients. Each such update contains update positions and orientations for the client's neighbors. The server only updates neighbours that have sent a ClientUpdate to the server, this will be frequently (around 5 times a second) when a client is moving, and less frequently (around once a second) when the client is stationary.

Notes

Security

The Motion Server checks the host and port of each packet to make sure that the update is really from the client it claims to be from. The ID server takes similar actions where feasible.

Consistency, Coherency, and Scalability

Since motion is a form of shared state, we must maintain coherency and consistency. In short, when you move, I should see you move on my screen in a manner that approximates your motion as closely as possible in space and time. Strict constraints exist on our implementation. Our bandwidth is very limited and we have latency from the Internet.

The restrictions mentioned above force certain implementation decisions on us. Instead of a simple system where each client in the space sends updates about its position to every other client, we centralize updates through a special server. A peer-to-peer solution requires too much bandwidth to work on target machines. Using a server allows us to compress updates and generate limited sets of updates. The motion server only tells a client about its nearest neighbors. This lowers the bandwidth required.

Problems with the server solution include scaling and realism. Having all motion updates go through one centralized resource requires that the motion server be able to handle interaction with all the people in the space. We have solutions for scaling spaces to use multiple motion servers, but it is not trivial. Realism suffers because only the nearest neighbors are updated. If I am standing in a crowd, I can still see people who are very far away if they are within my line of sight. By only updating nearest neighbors, only people close to me will be updated.

A problem with periodic updates occurs from the fact that motion is not consistent. Clients under human control typically change velocity and position abruptly. Due to latency, we cannot use predictive algorithms to predict client positions too far in the future. If we did, we would run the risk of having clients run through walls. A possible solution adapts the update frequency to the dynamics of the client's motion. If the client is moving in a highly dynamic way, it sends out more frequent updates. If it is moving linearly or very little, it sends out less frequent updates.

A key part of the strategy to handle a lot of users is the Horizon algorithm. (which is no longer available on the net).

Axis and Angle, or Quaternion

There is a debate as to whether orientations should be expressed as Axis and Angle as VRML's SFROTATION, or using a Quaternion. The former has the advantage of being easily compatable with existing practice, the latter requires more complex math, but has the advantage of also carrying information as to how the avatar got from one orientation to another.

Currently this protocol uses a SFROTATION with the vector normalised to a signed integer, and a rotation reduced to a Unsigned Int with 256 representing 2*pi radians.

Motion Packets

Neighbor Update Packet

Sent By:

Motion Server

Received By:

Client

When Sent:

This packet is sent every xxx seconds.

Interpretation:

This packet contains a list of avatars and their positions and orientations. The client is expected to use this list to correctly display these neighboring avatars in the world. If the client has never seen a particular ID before, it must query the ID Server to find an avatar description.

Fields:
    Command=NEIGHBOR_UPDATE
    Origin (x,y,z)
    Total Disappears        ( The number that would have been sent if no limit)
    Disappears Sent         ( The number actually sent )
    ID*                     (  ID's of disappeared avatars )
    Total Updates           ( The number that would have been sent if no limit)
    Updates Sent            ( The number actually sent )
    Client Update*          ( Repeated set of updates containing )                 
        ID
        Delta(x,y,z)        ( 16 bits, 1=1 centimeter)
        Orientation (x,y,z,rotation)

Client Update Packet

Sent By:

Client

Received By:

Server

When Sent:

This packet is sent 5 times a second when moving, or once a second when stationary.

Interpretation:

The client sends the server its current position and orientation. The server uses this information to keep track of the avatars in the space it is handling.

Fields:
    Command=CLIENT_UPDATE
    ID
    Position (x,y,z)
    Orientation (x,y,z,rotation)
    Horizon
    Maximum No of Disappears to send
    Maximum No of Neighbours to send