Liquid Reality: Physics and Locales
by Christopher Blohm & Keith Hentschel
Using Dimension X's Java-based API, Liquid Reality, we've extended the
functionality of VRML 2.0, adding such factors as real world physics and
multi-user capability. Liquid Reality is a set of Java classes that provide
everything you need for parsing, rendering, and writing out VRML 2.0, as
well as for manipulating the VRML 2.0 scene graph. This API could also be
used to create the much discussed global networked cyberspace. We've written
here about a possible way to implement the 'beacons and locales' proposal, which is based on research done at MERL, using Java.
We implemented direct control over a VRML world through Java pop-up menus with controls for the various attributes of the object one might wish to modify (position, rotation, color, scale, or any other exposed field). This "PopupNode" class has an eventOut for each field that can be modified that is in turn routed to a corresponding eventIn of the Transform or Material node to be affected. A basic client/server environment may be constructed by altering the time when the Java code posts the eventOut to the browser; if the client browser is not connected to the server, the event is simply posted directly to the scene (user manipulation of the Java control causes an event to be posted immediately and then handled by the browser), and if a connection exists, the user interaction results merely in a message sent to the server that updates its internal representation of the scene and then notifies each interested client that is connected to it of the change. The client receives the notification and, only then, posts the message to the browser causing the change to be displayed (user manipulation of the control causes a message to be sent over the network to the server, which then sends a message back to each client interested in the affected object, resulting in the event being posted to the browser).
While simple to implement and quite portable between different VRML 2.0 browsers, this technique is incredibly inefficient and slow to respond to changes. Fluid motion is just not possible in this way; as an object moves, the server is notified of its new position for every frame of movement, and this can easily overrun a 28.8 modem connection even if just one object in the scene in motion. Not very enticing.
In Bouncey, objects are, by default, unaffected by all the forces of physics, and it is possible to selectively enable only the elements you wish. Horizontal platforms, for example, enable only surface friction; they hang in midair because they are unaffected by gravity.
Once you implement physics and have the ability to both effect changes to any node in the scene (either via of routes and Script nodes or direct use of your browser's API) and create new objects and place them directly into the scene and remove them as well, you can develop a scaleable virtual environment as below.
The approach defines a larger space by breaking the world up into smaller regions (locales), each with its own local coordinate system, the implications of which follow.
Locale shape may be either creator designed, arbitrator assigned, or server created. The key to their functioning is not necessarily in their shape or arrangement, but in being able to locate a locale by numeric identifier (or through a resolver which maps strings to identifiers as DNS maps IPs), Each locale must have a bounding shape specified which may be tested for intersection to determine when objects are moving from region to region. Locales specify their neighbors along with a Transform which locates that neighbor in space, not with absolute coordinates, but in relation to the locale the user currently inhabits, and perform necessary adjustments to velocities or the effects of gravity if it is deemed that the laws of physics should differ within the new space.
As an object moves from one locale to another, there are three possibilities for each neighbor of the locale the object is entering:
1) The neighbor was also a neighbor of the previously inhabited locale and requires only adjustment of the root node and possibly a single traversal of all nodes beneath this root (every object in the locale) to scale geometry if space is defined in different terms in the new region, or to provide locale-wide scaling as desired.
2) The neighbor was not a neighbor of the previous locale and must be requested from the server first then inserted into the scene with appropriate transformations applied.
3) A locale which was a neighbor of the region just exited is not a neighbor of the current locale and so is simply detached from the scene.
Locales also require a bounding box to be specified as their surrounding. When the user collides with an edge of the boundary, the appropriate neighbor is determined and the scene is adjusted as above. If a neighbor has not yet finished loading, movement may be blocked until completed. Locales need not be loaded in their entirety; the server decides an appropriate progression, perhaps first sending only temporarily visible bounding boxes, then the least detailed representation of each object, and so on until the process is complete.
An all-relative, locale-based approach to multi-user environment construction affords great flexibility and scaleability. For example, a mirror may be constructed by having a locale neighbor itself, but with a transform that reverses the geometry the creates the mirror image; vast regions may be enclosed in tiny objects as long as they remain invisible from outside of the region. A doorway could be constructed which would cause the user to re-enter the same locale only scaled and upside-down with everything in shades of blue.
Most complex transformations would require a complete traversal of the new locale's portion of the scene graph (such as recoloring all material nodes into shades of blue), but simple joining of neighboring locales which share the same laws of physics/concepts of size and dimension could require nothing more than an adjustment of the "translation" exposedField of the root node.
The key feature of this technique, however, is that it allows arbitrary scaleable virtual worlds to be constructed piece-by-piece. As every locale has its own coordinate system and all positions, forces, and velocities are defined in these coordinates, the only upper limit to the size of the environment is the number of locale identifiers possible; all points are specified as [ID,x,y,z] in an entirely local coordinate system, eliminating world size restrictions which result when the maximum range achievable for a chosen coordinate data type is reached. Extremely large worlds may be constructed in this manner with completely undetectable and seamless transitions.
Liquid Reality's Java API is used directly in this example; the server maintains its own internal representation of the scene and the VRML browser being used merely as renderer.
For more information on this topic see the www-vrml mailing list, Mark Pesce's cyberspace protocol, the TerraVista project, MERL, and DimensionX.
Christopher Blohm, Principal and Creative Director at the WebPool Syndicate Inc., an Internet content development company specializing in 3D environments and software design. Along with WebPool's Senior Programmer Keith Hentschel, Chris has been working to develop leading edge VRML applications particularly in the area of shared space functionality. In addition Chris is an instructor at the Vancouver Film School's Multimedia campus where he teaches VR design to 3D animation and Multimedia students. He is also regularly asked to speak to corporations and conference audiences. With associate developers in both the US and Japan, Chris and the WebPool are actively involved in the growing VRML development community.
#VRML V2.0 utf8 |
NavigationInfo | Java Chat | Subscribe | Tell Friends
© 1996 Aereal, Inc. Please send suggestions to firstname.lastname@example.org.