Java 3D API Specification
Java 3D API Specification
A P P E N D I X  F |
|
VRML Support |
This appendix is designed to help VRML browser-developers architect a VRML browser and runtime environment using the Java 3D API. Sun has already prototyped a VRML 1.0 and VRML 2.0 3D-only browser. It has limited browsing functionality but includes the ability to load worlds, navigate, and pick.
VRML files come in one of two formats, VRML 1.0 and VRML 2.0. These two file formats are sufficiently different that developers will most likely support them separately. In general, VRML 1.0 files allow the definition of static geometry, predefined "viewpoints", linking to other worlds, and some simple browser specific semantics (pick to transport, menu to change viewpoint). The newer, VRML 2.0 file format provides an improved facility for defining static geometry and includes support for representing a broader range of information such as active components and sound.
A developer can use Java 3D functionality to build a VRML loader and browser much as he or she would use C and OpenGL to write a VRML loader and associated browser. The combination of Java and the Java 3D API-like the combination of C and the OpenGL API-provide programmers with sufficient functionality to write complete applications. The Java-based approach additionally allows the development of complete applets.
F.1
VRML 1.0
VRML 1.0 files describe geometry, the material properties associated with that geometry, and the placement of that geometry with respect to other geometry, all within a single virtual world. The file format also includes other properties such lights, attach points (via cameras), and links to other files.
VRML 1.0 files also assume the existence of a browser and, over time, there have been some default browser semantics that have become a de facto standard. Specifically these include browser-constructed menus, gleaned from the VRML 1.0 file, that allow an end user to choose among a predefined set of viewpoints, browser controls that allow an end user to navigate within the virtual world, and mouse-based pick operations that allow an end user to gain access to other worlds.
F.1.1
VRML 1.0 files do not map directly into Java 3D objects. However, Java 3D objects support the complete functionality needed to support VRML 1.0 files. Thus, a developer can write a simple loader to parse a VRML 1.0 file, construct a Java 3D scene graph that represents the information contained in the VRML file, and let Java 3D render the scene. Unfortunately, this does not address the browser issue.
F.1.2
VRML 1.0 browsers allow end-users to navigate within a VRML world, to "pick" objects by using their mouse, to choose among viewpoints defined within the scene graph via menus, and other housekeeping tasks (such as loading a world).
By using Java, specifically Java's AWT package, developers can construct windows, menus, and buttons that allow end-user access to developer-written functionality. A developer would build a browser that would interface with the VRML 1.0 loader to load a VRML world and retrieve references to relevant scene graph information. The browser would interface with the Java 3D API to draw the world, to change viewpoints, to process pick operations, and to navigate within the world.
F.2
The VRML 2.0 file format allows the description of geometry, material properties, and object placement but in a more facile manner than the VRML 1.0 file format. In addition, the VRML 2.0 file format includes mechanisms for describing sensors, routes and fields, script nodes, interpolators, support for collision detection, and support for picking.
A similar approach to the one used for VRML 1.0 would have worked (a loader/browser combination) had there not been sensors, routes, fields, and script nodes. These new features require a different approach since information flow within a VRML 2.0 file is specified via routes: Java 3D does not include a similar structure.
F.2.1
VRML 2.0 files do not map directly onto Java 3D objects. A developer could mitigate this by mapping a VRML 2.0 object specification onto a set of Java 3D objects that mimicked the object's functionality. Unfortunately, this does not work in general. VRML 2.0's runtime semantics, specifically the ability to retarget routes to other fields and the ability to access all the descendants of a "referenced" VRML 2.0 object, require that the same structure as specified in the VRML 2.0 file exist within the runtime environment.
Another problem area involves script nodes based on languages other than Java. We do not anticipate developers defining interpreters for other languages that run within the Java environment. We expect that developers will support only Java-based script nodes.
This mismatch between VRML 2.0 and Java 3D is bidirectional, there are Java 3D constructs and behaviors that do not map directly onto the VRML 2.0 file format.
F.2.2
Developers can host a VRML 2.0 file within a Java 3D environment by constructing exactly the same scene graph structure as specified in a VRML 2.0 file. They can then use the Java 3D behavior system or its mixed mode callback features to implement field value propagation. The remainder of this section defines one such approach.
F.2.2.1
A developer defines a series of Java objects that represent the corresponding VRML 2.0 objects. These Java objects also construct an associated Java 3D object or set of objects. Actions that occur on the thin-layer VRML 2.0 objects reflect those changes in the underlying Java 3D objects. In places, where the VRML 2.0 structure cannot reference a VRML 2.0 node or nodes, the developer need not construct the thin-layer VRML 2.0 nodes.
A central object is the Field object. It contains a field value, references to all fields that either affect it or it affects, and code to update the Java 3D instance variable associated with the VRML 2.0 field value. It also includes methods that allow adding or removing fields at runtime.
F.2.2.2
VRML 2.0 activities start with either a user interaction (browser-generated) or with a sensor firing. In either case, a field value is changed. In the simplest case, the act of changing a field's value causes that field to update its associated Java 3D instance variable and then propagate the new value to all of its recipients or mark itself as active (waiting for a future propagation step - possible because of a timestamp issue or because of lazy evaluation).
This model is, of course, less than optimal in terms of execution efficiency and a developer can easily think of a number of techniques that will improve the model's performance characteristics, such as implementing a pull model (a field knows that its source field's value has changed but only retrieves that value if its value is needed in a render step).
F.2.2.3
The VRML 2.0 runtime-environment developer must provide one last feature, control over field propagation. The developer can either use a Java 3D behavior that performs propagation at each frame by setting a WakeupOnElapsedFrames criteria or by using a mixed immediate mode render callback function to perform the same activity.
F.2.3
A VRML 2.0 browser can use much the same technique as the VRML 1.0 browser. It, of course, must know how to interact directly with the VRML 2.0 scene graph.
F.2.4
A VRML browser need not provide access to the complete VRML 2.0 scene graph and indeed, a developer can take advantage of this to minimize the number of thin VRML 2.0 objects. If there is no way to reference a VRML 2.0 node then its thin object need not exist.
An environment that allows editing must keep the entire thin-object scene graph in memory.
In either the view-only or the editing case, a developer can straightforwardly write a VRML 2.0 file to disk by traversing the thin-object in-core representation.
Java 3D API Specification
Copyright © 1997, Sun Microsystems, Inc. All rights reserved.