Everything internal to the metaverse will be handled through Open Inventor code, so we can utilize Inventor engines to animate a Sun, Moon or any other constant-motion object. Actually, we can allow people to instance engines or any Inventor feature we want, as long as we can deliver VRML as output. Input is handled by piping VRML files through a script which changes the VRML scene into Inventor format and ``flattens'' the scene by recursively pulling down all referenced ( WWWInline) scenes. The input is then read into the metaverse application using a standard SoDB::read() method. Output is piped through vrmllint before being returned to the client to ensure that it conforms to the current VRML specifications.
While the internals of the world are implemented in Inventor, the delivered scene descriptions adhere strictly to the current VRML standard.
Unlike many other multiplayer application, in this metaverse 'bots (automatons) are encouraged. Example IVL scripts to drive 'bots are be provided.
It is very important to our applications that we be able to uniquely identify each node. With avatars, for instance, we specify that articulations must have named Transform nodes with standard names. If there are two avatars in the world, each with a ``Head'', how can we distinguish between the two nodes named ``Head'' within our code? We would benefit greatly from modifications to the VRML standard which allowed us to reference these DEF-ed nodes within a URL. In the above example, we might want to refer to Joe.Head where Head would be a named node within DEF Joe WWWInline{name "http://joe.com/Joe.wrl"}. This would allow us to reference Joe's head independently of Bob's head for example. We do not think that this model of refering to nodes implies or rules out any particular implementation of behaviors that we have seen---it merely enhances the ability to manipulate VRML scenes in code.