From 54f1415fa01061f0bcc5126605713b9a391cec46 Mon Sep 17 00:00:00 2001 From: phil Date: Fri, 29 Dec 2017 22:53:47 +1300 Subject: Some excellent doc files added --- doc-files/VirtualUniverse.html | 265 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 265 insertions(+) create mode 100644 doc-files/VirtualUniverse.html (limited to 'doc-files/VirtualUniverse.html') diff --git a/doc-files/VirtualUniverse.html b/doc-files/VirtualUniverse.html new file mode 100644 index 0000000..2f9dd14 --- /dev/null +++ b/doc-files/VirtualUniverse.html @@ -0,0 +1,265 @@ + + + + + Java 3D API - Scene Graph Superstructure + + +

Scene Graph Superstructure

+

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). +

+

+

+

The Virtual Universe

+Java 3D defines the concept of a virtual universe +as a three-dimensional space with an associated set of objects. Virtual +universes serve as the largest unit of aggregate representation, and +can also be thought of as databases. Virtual universes can be very +large, both in physical space units and in content. Indeed, in most +cases a single virtual universe will serve an application's entire +needs. +

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. +

+

The Virtual Universe +

+

+

+ +

+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. +

+

+

+

Establishing a Scene

+To construct a three-dimensional scene, the programmer must execute a +Java 3D program. The Java 3D application must first create a +VirtualUniverse object and attach at least one Locale to it. Then the +desired scene graph is constructed, starting with a BranchGroup node +and including at least one ViewPlatform object, and the scene graph is +attached to the Locale. Finally, a View object that references the +ViewPlatform object (see "Structuring +the Java 3D Program") +is constructed. As soon as a scene graph containing a ViewPlatform is +attached to the VirtualUniverse, Java 3D's rendering loop is engaged, +and the scene will appear on the drawing canvas(es) associated with the +View object. +

Loading a Virtual Universe

+Java 3D is a runtime application programming +interface (API), not a file format. As an API, Java 3D provides no +direct mechanism for loading or storing a virtual universe. +Constructing a scene graph involves the execution of a Java 3D program. +However, loaders to convert a number of standard 3D file formats to or +from Java 3D virtual universes are expected to be generally available. +

Coordinate Systems

+By default, Java 3D coordinate systems are right-handed, with the +orientation semantics being that +y is the local gravitational +up, +x is horizontal to the right, and +z is directly +toward the viewer. The default units are meters. +

High-Resolution Coordinates

+Double-precision floating-point, single-precision floating-point, or +even fixed-point representations of three-dimensional coordinates are +sufficient to represent and display rich 3D scenes. Unfortunately, +scenes are not worlds, let alone universes. If one ventures even a +hundred miles away from the (0.0, 0.0, 0.0) origin using only +single-precision floating-point coordinates, representable points +become quite quantized, to at very best a third of an inch (and much +more coarsely than that in practice). +

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. +

+

+

+

Java 3D High-Resolution +Coordinates

+Java 3D high-resolution coordinates consist of three 256-bit +fixed-point numbers, one each for x, y, and z. +The fixed point is at bit 128, and the value 1.0 is defined to be +exactly 1 meter. This coordinate system is sufficient to describe a +universe in excess of several hundred billion light years across, yet +still define objects smaller than a proton (down to below the planck +length). Table +1 shows how many bits are needed above or below the fixed point +to represent the range of interesting physical dimensions. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Table 1 – +Java 3D High-Resolution Coordinates
2n Meters Units
87.29Universe (20 billion light years) 
+
69.68Galaxy (100,000 light years)
53.07Light year
43.43Solar system diameter
23.60Earth diameter
10.65Mile
9.97Kilometer
0.00Meter
-19.93Micron
-33.22Angstrom
-115.57Planck 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. +

+

+

+

Java 3D Virtual World +Coordinates

+Within a given virtual world coordinate system, positions are expressed +by three floating point numbers. The virtual world coordinate scale is +in meters, but this can be affected by scale changes in the object +hierarchy. +

Details of High-Resolution +Coordinates

+High-resolution coordinates are represented as signed, +two's-complement, fixed-point numbers consisting of 256 bits. Although +Java 3D keeps the internal representation of high-resolution +coordinates opaque, users specify such coordinates using 8-element +integer arrays. Java 3D treats the integer found at index 0 as +containing the most significant bits and the integer found at index 7 +as containing the least significant bits of the high-resolution +coordinate. The binary point is located at bit position 128, or between +the integers at index 3 and 4. A high-resolution coordinate of 1.0 is 1 +meter. +

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.) +

+ + -- cgit v1.2.3