Subscribe Now Free!
Read Viewpoint
Yet?

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.

Java Server
We've placed our VRML robot arm in the Liquid Reality tool kit. In addition, we've used Java to write both a multi-user server and a set of classes that allows multiple clients to manipulate the arm's position and rotation. This is a prototype multi-user environment developed for a Vancouver based robotics company that wants to use VRML in a tele-robotics operation.

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.


A different approach is needed to add more realism to the world.


Why Use Velocity in M-W Scene?
By adding velocity, one can more accurately simulate the real world. Many optimizations are possible with respect to communication with a server in a multi-user context. Only the changes in velocity need be transmitted from the server to the clients (browsers); each client then performs its own translation of the object along its last known path, essentially functioning as a dynamically created PositionInterpolator node.


Physics:
Last year, before the merging of VRML and Java, we created a 3D Java world named Bouncey. It implements basic kinematics: gravity, mass, velocity (translational and rotational, i.e. if you hit an object on its side it will spin), friction (surface and air), and an additional few pseudo-attributes to simulate the effects of density and surface rigidity (which control the degree of recoil/bounce of the object) in a simpler, less computationally intensive manner. All masses are point masses, located by default at [0,0,0] in object coordinates, and gravity acts uniformly downward into the xz-plane.

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.

[VRML-bouncey 2.0]
Using Liquid Reality, which implements the VRML 2.0 specification, the 3D graphics library is taken care of. In Bouncey, we had to create this strictly in Java, a very arduous task. As a widely supported standard, VRML allows developers to concentrate on expanding the functionality and content of their virtual worlds without having to worry about low-level 3D programming needed on every platform they wish to support. Many companies have put in long months defining specification. We are using the Liquid Reality API directly for nearly all scene manipulations rather than VRML 2 routes, and, while this is less portable to other browsers, it allows for greater speed and flexibility. VRML-Bouncey, implements all kinematics, friction, etc., of the Java-Bouncey, but here any VRML geometry can be imported for use in the file. This could be used, for example, in VRML billiards.


The Future
VRML 2.0 not only provides a comprehensive system for manipulating the scene dynamically through routes and script nodes and a standard minimal API but also allows world designers and programmers the freedom to selectively ignore portions of the specification and use lower level, more direct methods of affecting the scene if the particular browser provides them.

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.


"MERL Spline"
MERL's Spline, Scalable PLatform for INteractive Environments, breaks up its large worlds by implementing a technique discussed in a paper entitled "Locales and Beacons: Efficient and Precise Support For Large Multi-User Virtual Environments":

    Locales are an efficient method for solving all of the aforementioned problems. They break up a virtual world into compact chunks that can be described and communicated independently. In addition, locales can be used to support a number of special effects that allow virtual worlds to easily transcend reality. While having many benefits, locales introduce an additional problem, in that it is difficult to find something when you do not know what locale it is in. This problem is solved by the companion concept of beacons, which makes it possible to find something no matter where it is.

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.


Relative URLs


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 | WorldInfo | ViewPoint | Shape
NavigationInfo | Java Chat | Subscribe | Tell Friends

© 1996 Aereal, Inc. Please send suggestions to suggest@vrmlsite.com.