Goal Outline

This section contains a brief overview of the central points of this project. The three main goals are described in more detail below. Each goal is briefly defined and some outstanding issues are raised.

Motion

By motion, we mean specifically that a user sitting at one client can see the motion of certain other users in the same VRML space. This motion must be relatively accurate and timely. Movement information only makes sense if it is not delayed too much. While we cannot control the latency due to the net, we must try to reduce the latency due to the code.

Motion data contains information about the most recent positions of avatars in the space. Since there is some latency, the positions are not the current positions. Each client receives updates about other avatars in the vicinity of its avatar. These updates come from a special kind of server located (usually) on a remote machine. Data in the VRML loaded for the space tells the client which server to use for getting motion data.

Eventually, the motion server will be specified by placing a URL to it in a Multiuser node in the VRML file, but until this is standardised on, it is handled in a Named Info node.

Avatar Descriptions

Avatars are described in VRML. Each client tells the WorldsMultiuser server about itself via a message containing the VRML description for the client's avatar. There are restrictions on the size of the avatar description due to limitations on packet size imposed by the networking layer, so typically this will be a couple of nodes with maybe a transform and a WWWInline pointing at a publicly accessable VRML file.

Other aspects of the description are currently implemented as seperate messages. At some point these may be included in the VRML, but this would neccessitate several pieces of functionality being able to parse VRML including the ID server. This extra information can or does include:

• user name An Info node could be used within the VRML description to describe a users name. How this name is displayed is dependent on the client.
• other services Other nodes in the avatar description can define references to services such as text, audio or video. Since these capabilities are specific to the client machine in question, they must be set up individually.

Text

Users must be able to communicate with each other. Our third goal states that we want to support simple text communication. Support in the protocol for a number of different modalities of text communication is required, although only a reduced set will be implemented here.