One of the goals of the MW proposal is to provide the functionality needed to build these different models *without* dictating which approach should be used. The features described would be used identically in both models.
This appendix highlights the key base requirements that any multi-user world has in common and shows which parts of the proposal address those requirements. We then give an example to show how this might be implemented.
The second aspect is a special case of the first in that a special object, the user representation, or avatar is shared among browsers viewing the world. In this appendix we discuss the specific case of shared avatars and then generalise the functionality to support any shared item.
For both these cases, the approach is the same. One or more Script nodes are put into the world, specifying a general purpose, or application specific applet which carries out the network functionality. For each piece of shared information, either Routes are added to and from the appropriate events to the ScriptNode, or the node itself is passed to the script which can then get and set fields. The former is used when information is needed every time it changes, the latter when it is only needed occasionally.
It is necessary for the browser to make available the spatial location of the user (the camera viewpoint) relative to a know point, so that the scripts controlling the multi-user functionality can send this position to other browsers.
Moving Worlds provides two ways to do this.
It must be possible to uniquely identify the users in the shared space. This is necessary to allow the browser to tell the server or the other browsers who is sending the location information.
This also will be application specific, for example does the application need friendly names, email addresses, URL's of Avatars etc. Typically this will be handled by a script accessing a configuration file to read the information.
Once the spatial location is available then the script needs a means to send the information to other browsers or the server. The protocol used to do this will be highly dependant on the application, for example it could be VRML+ or DIS or VSCP. Rodger: Do we want to mention these ? Mitra: Yes, since they will be meaningfull to the readers, and we want to specifically say that we will work with any of these approaches
Moving Worlds supports this by allowing scripts to run asynchronously, any of the languages likely to be used for Applets have network functionality. So a Java Applet for example can use the normal mechanisms to spawn a thread that then uses Java's network classes to send to the network. There are no specific API calls needed in Moving Worlds to provide this functionality.
Information is received over the network, either from a server or a peer, and needs to be used to update the shared scene.
In Moving Worlds, scripts use normal language constructs to handle application dependant protocols. When a user's browser first joins a shared world, information about that user's avatar is sent to other browsers sharing that world. This information will typically include a VRML description (or a URL to a VRML description) of the avatar.
This can be put into the world in several ways, for example, one or more nodes will be placed in the world, either at the top level (if using the _Self node for location information) or in the same frame as the BoxProximitySensor nodes.
Once the avatar is created scripts will be provided with a SFNode pointer to the node(s) and will use the AppendNode call in the API to add the Avatar along with a frame so that it can be moved around in response to future updates.
In the case of trying to share state across the network, whether that is a SFBoolean representing whether a light is on or off, or the time an animation should start, or the position of a movable object, it is neccessary that a script can have access to read and write this state.
In Moving Worlds this is accomplished by routing events to and from the states to be shared, to the script that is responsible for propagating the changes.
Mitra: The nasty part - that I've been trying to convince Gavin we need fixed!
A seperate eventIn and eventOut (or a seperate script) are provided for every state that can change, so that it can be associated with a unique name before sending it over the network. Rodger: it's here that you need to discuss naming in general, where does the unique name come from. Mitra: Exactly! It could be a DEF name, or it could be a name associated with a route, or it could be a name associated with the eventIn on the script node, both the former work with fan in, but are not passed in the event. The latter doesn't work with fan in.
One fix would be to support the "userData" field on routes to allow us to use fan-in without losing the information as to which peice of state was being sent
As information is received off the network, the script can either send an event via a route to change the state, or can use getField if it has a SFNode pointer to the portion of the scene graph being changed.
Separator { DEF bar BoxProximitySensor { } # To detect our own position DEF foo Separator { } # Avatars are added here } DEF baz Script { eventIn SFVec3f position eventIn SFRotation orientation field SFNode avatarRoot IS foo behavior "http://xyz.com/mynetworkprotocol.java" } ROUTE bar.position -> baz.position ROUTE bar.orientation -> baz.orientation
This example will need rewriting to match the final version of the API, it should be close though class MyNetworkProtocol extends VRMLApplet implements Runnable { void start() { # spawn thread to monitor network } void eventIn(Event e) { # send position and orientation events to server } void run { # monitors network, # on receipt of appropriate events from network calls # sends add, delete, change events to avatarRoot. } }