Java 3D's superstructure consists of one or more VirtualUniverse objects, each of which contains a set of one or more high-resolution Locale objects. The Locale objects, in turn, contain collections of subgraphs that comprise the scene graph (see Figure 1).
Virtual universes are separate entities in that no node object may exist in more than one virtual universe at any one time. Likewise, the objects in one virtual universe are not visible in, nor do they interact with objects in, any other virtual universe.
To support large virtual universes, Java 3D introduces the concept of Locales that have high-resolution coordinates as an origin. Think of high-resolution coordinates as "tie-downs" that precisely anchor the locations of objects specified using less precise floating-point coordinates that are within the range of influence of the high-resolution coordinates.
A Locale, with its associated high-resolution coordinates, serves as the next level of representation down from a virtual universe. All virtual universes contain one or more high-resolution-coordinate Locales, and all other objects are attached to a Locale. High-resolution coordinates act as an upper-level translation-only transform node. For example, the coordinates of all objects that are attached to a particular Locale are all relative to the location of that Locale's high-resolution coordinates.
While a virtual universe is similar to the traditional computer graphics concept of a scene graph, a given virtual universe can become so large that it is often better to think of a scene graph as the descendant of a high-resolution-coordinate Locale.
To "shrink" down to a small size (say the size of an IC transistor), even very near (0.0, 0.0, 0.0), the same problem arises.
If a large contiguous virtual universe is to be supported, some form of higher-resolution addressing is required. Thus the choice of 256-bit positional components for "high-resolution" positions.
2n Meters | Units |
---|---|
87.29 | Universe (20 billion light years) |
69.68 | Galaxy (100,000 light years) |
53.07 | Light year |
43.43 | Solar system diameter |
23.60 | Earth diameter |
10.65 | Mile |
9.97 | Kilometer |
0.00 | Meter |
-19.93 | Micron |
-33.22 | Angstrom |
-115.57 | Planck length |
A 256-bit fixed-point number also has the advantage of being able to directly represent nearly any reasonable single-precision floating-point value exactly.
High-resolution coordinates in Java 3D are used only to embed more traditional floating point coordinate systems within a much higher-resolution substrate. In this way a visually seamless virtual universe of any conceivable size or scale can be created, without worry about numerical accuracy.
The semantics of how file loaders deal with high-resolution coordinates is up to the individual file loader, as Java 3D does not directly define any file-loading semantics. However, some general advice can be given (note that this advice is not officially part of the Java 3D specification).
For "small" virtual universes (on the order of hundreds of meters across in relative scale), a single Locale with high-resolution coordinates at location (0.0, 0.0, 0.0) as the root node (below the VirtualUniverse object) is sufficient; a loader can automatically construct this node during the loading process, and the point in high-resolution coordinates does not need any direct representation in the external file.
Larger virtual universes are expected to be constructed usually like computer directory hierarchies, that is, as a "root" virtual universe containing mostly external file references to embedded virtual universes. In this case, the file reference object (user-specific data hung off a Java 3D group or hi-res node) defines the location for the data to be read into the current virtual universe.
The data file's contents should be parented to the file object node while being read, thus inheriting the high-resolution coordinates of the file object as the new relative virtual universe origin of the embedded scene graph. If this scene graph itself contains high-resolution coordinates, it will need to be offset (translated) by the amount in the file object's high-resolution coordinates and then added to the larger virtual universe as new high-resolution coordinates, with their contents hung off below them. Once again, this procedure is not part of the official Java 3D specification, but some more details on the care and use of high-resolution coordinates in external file formats will probably be available as a Java 3D application note.
Authoring tools that directly support high-resolution coordinates should create additional high-resolution coordinates as a user creates new geometry "sufficiently" far away (or of different scale) from existing high-resolution coordinates.
Semantics of widely moving objects. Most fixed and nearly-fixed objects stay attached to the same high-resolution Locale. Objects that make wide changes in position or scale may periodically need to be reparented to a more appropriate high-resolution Locale. If no appropriate high-resolution Locale exists, the application may need to create a new one.
Semantics of viewing. The ViewPlatform object and the associated nodes in its hierarchy are very often widely moving objects. Applications will typically attach the view platform to the most appropriate high-resolution Locale. For display, all objects will first have their positions translated by the difference between the location of their high-resolution Locale and the view platform's high-resolution Locale. (In the common case of the Locales being the same, no translation is necessary.)