aboutsummaryrefslogtreecommitdiffstats
path: root/src/main/java
diff options
context:
space:
mode:
authorCurtis Rueden <ctrueden@wisc.edu>2015-11-30 11:30:09 -0600
committerCurtis Rueden <ctrueden@wisc.edu>2015-11-30 11:30:09 -0600
commit9555742ab809af1f8f91f346368edc9eb463f711 (patch)
tree86b4a7ecce67666dc999ab7280cb03ebc13ef7d1 /src/main/java
parent2d50e9b954c99f1a2d04a160d934076b921fd709 (diff)
Move javadoc files to standard Maven location
Diffstat (limited to 'src/main/java')
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/Behaviors.html596
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/Behaviors1.gifbin9067 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/Behaviors2.gifbin2223 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/Behaviors3.gifbin2189 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/Behaviors4.gifbin2452 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/Behaviors5.gifbin4743 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/Behaviors6.gifbin4535 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/Behaviors7.gifbin4463 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/Behaviors8.gifbin22297 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/Concepts.html291
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/Concepts1.gifbin19058 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/Concepts2.gifbin14546 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/DAG.gifbin19099 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/HelloUniverse.html21
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/Immediate.html114
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/Immediate1.gifbin17085 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/Rendering.html148
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/SceneGraphOverview.html226
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/SceneGraphSharing.html250
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/SceneGraphSharing1.gifbin22601 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/SceneGraphSharing2.gifbin17159 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/SceneGraphSharing3.gifbin13186 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/SceneGraphSharing4.gifbin12419 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/SceneGraphSharing5.gifbin10695 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/ViewBranch.gifbin19210 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/ViewModel.html1064
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/ViewModel1.gifbin19585 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/ViewModel10.gifbin29787 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/ViewModel11.gifbin15569 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/ViewModel12.gifbin15520 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/ViewModel13.gifbin14982 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/ViewModel14.gifbin11968 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/ViewModel2.gifbin17085 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/ViewModel3.gifbin22430 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/ViewModel4.gifbin16502 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/ViewModel5.gifbin9524 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/ViewModel6.gifbin10590 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/ViewModel7.gifbin10958 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/ViewModel8.gifbin16583 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/ViewModel9.gifbin14194 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/VirtualUniverse.gifbin19123 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/VirtualUniverse.html265
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/intro.gifbin19452 -> 0 bytes
-rw-r--r--src/main/java/org/jogamp/java3d/doc-files/intro.html337
-rw-r--r--src/main/java/org/jogamp/java3d/package.html40
45 files changed, 0 insertions, 3352 deletions
diff --git a/src/main/java/org/jogamp/java3d/doc-files/Behaviors.html b/src/main/java/org/jogamp/java3d/doc-files/Behaviors.html
deleted file mode 100644
index 7bcc4a2..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/Behaviors.html
+++ /dev/null
@@ -1,596 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
- <meta content="text/html; charset=ISO-8859-1"
- http-equiv="content-type">
- <title>Java 3D API - Behaviors and Interpolators</title>
-</head>
-<body>
-<h2>Behaviors and Interpolators</h2>
-<p><a href="../Behavior.html">Behavior</a> nodes provide the means for
-animating objects, processing keyboard and mouse inputs, reacting to
-movement, and enabling and processing pick events. Behavior nodes
-contain Java code and state variables. A Behavior node's Java code can
-interact with Java objects, change node values within a Java&nbsp;3D
-scene
-graph, change the behavior's internal state-in general, perform any
-computation it wishes.
-</p>
-<p>Simple behaviors can add surprisingly interesting effects to a scene
-graph. For example, one can animate a rigid object by using a Behavior
-node to repetitively modify the TransformGroup node that points to the
-object one wishes to animate. Alternatively, a Behavior node can track
-the current position of a mouse and modify portions of the scene graph
-in response.</p>
-<h2>Behavior Object</h2>
-<p>A Behavior leaf node object contains a scheduling region and two
-methods: an <code>initialize</code> method called once when the
-behavior becomes "live" and a <code>processStimulus</code>
-method called whenever appropriate by the Java&nbsp;3D behavior
-scheduler.
-The Behavior object also contains the state information needed by its <code>initialize</code>
-and <code>processStimulus</code> methods.
-</p>
-<p>The <em>scheduling region</em> defines a spatial volume that serves
-to enable the scheduling of Behavior nodes. A Behavior node is <em>active</em>
-(can receive stimuli) whenever an active ViewPlatform's activation
-volume intersects a Behavior object's scheduling region. Only active
-behaviors can receive stimuli.
-</p>
-<p>The <em>scheduling interval</em> defines a
-partial order of execution for behaviors that wake up in response to
-the same wakeup condition (that is, those behaviors that are processed
-at the same "time"). Given a set of behaviors whose wakeup conditions
-are satisfied at the same time, the behavior scheduler will execute all
-behaviors in a lower scheduling interval before executing any behavior
-in a higher scheduling interval. Within a scheduling interval,
-behaviors can be executed in any order, or in parallel. Note that this
-partial ordering is only guaranteed for those behaviors that wake up at
-the same time in response to the same wakeup condition, for example,
-the set of behaviors that wake up every frame in response to a
-WakeupOnElapsedFrames(0) wakeup condition.
-</p>
-<p>The <code>processStimulus</code> method receives and processes a
-behavior's ongoing messages. The Java&nbsp;3D behavior scheduler
-invokes a
-Behavior node's <code>processStimulus</code>
-method when an active ViewPlatform's activation volume intersects a
-Behavior object's scheduling region and all of that behavior's wakeup
-criteria are satisfied. The <code>processStimulus</code> method
-performs its computations and actions (possibly including the
-registration of state change information that could cause Java&nbsp;3D
-to
-wake other Behavior objects), establishes its next wakeup condition,
-and finally exits.
-</p>
-<p>A typical behavior will modify one or more nodes or node components
-in
-the scene graph. These modifications can happen in parallel with
-rendering. In general, applications cannot count on behavior execution
-being synchronized with rendering. There are two exceptions to this
-general rule:
-</p>
-<ul>
- <li>All modifications to scene graph objects (not including geometry
-by-reference or texture by-reference) made from the <code>processStimulus</code>
-method of a single behavior instance are guaranteed to take effect in
-the same rendering frame</li>
-</ul>
-<ul>
- <li>All modifications to scene graph objects (not including geometry
-by-reference or texture by-reference) made from the <code>processStimulus</code>
-methods of the set of behaviors that wake up in response to a
-WakeupOnElapsedFrames(0) wakeup condition are guaranteed to take effect
-in the same rendering frame.</li>
-</ul>
-<p>Note that modifications to geometry by-reference or texture
-by-reference are not guaranteed to show up in the same frame as other
-scene graph changes.
-</p>
-<h3>Code Structure</h3>
-<p>When the Java&nbsp;3D behavior scheduler invokes a Behavior object's
-<code>processStimulus</code>
-method, that method may perform any computation it wishes. Usually, it
-will change its internal state and specify its new wakeup conditions.
-Most probably, it will manipulate scene graph elements. However, the
-behavior code can change only those aspects of a scene graph element
-permitted by the capabilities associated with that scene graph element.
-A scene graph's capabilities restrict behavioral manipulation to those
-manipulations explicitly allowed.
-</p>
-<p>The application must provide the Behavior object with references to
-those scene graph elements that the Behavior object will manipulate.
-The application provides those references as arguments to the
-behavior's constructor when it creates the Behavior object.
-Alternatively, the Behavior object itself can obtain access to the
-relevant scene graph elements either when Java&nbsp;3D invokes its <code>initialize</code>
-method or each time Java&nbsp;3D invokes its <code>processStimulus</code>
-method.
-</p>
-<p>Behavior methods have a very rigid structure. Java&nbsp;3D assumes
-that
-they
-always run to completion (if needed, they can spawn threads). Each
-method's basic structure consists of the following:
-</p>
-<ul>
- <li>Code to decode and extract references from the WakeupCondition
-enumeration that caused the object's awakening.</li>
-</ul>
-<ul>
- <li>Code to perform the manipulations associated with the
-WakeupCondition.</li>
-</ul>
-<ul>
- <li>Code to establish this behavior's new WakeupCondition.</li>
-</ul>
-<ul>
- <li>A path to Exit (so that execution returns to the Java&nbsp;3D
-behavior
-scheduler).</li>
-</ul>
-<h3>WakeupCondition Object</h3>
-<p>A <a href="../WakeupCondition.html">WakeupCondition</a> object is
-an
-abstract class specialized to fourteen
-different WakeupCriterion objects and to four combining objects
-containing multiple WakeupCriterion objects.
-</p>
-<p>A Behavior node provides the Java&nbsp;3D behavior scheduler with a
-WakeupCondition object. When that object's WakeupCondition has been
-satisfied, the behavior scheduler hands that same WakeupCondition back
-to the Behavior via an enumeration.
-</p>
-<p>
-</p>
-<h3>WakeupCriterion Object</h3>
-<p>Java&nbsp;3D provides a rich set of wakeup criteria that Behavior
-objects
-can use in specifying a complex WakeupCondition. These wakeup criteria
-can cause Java&nbsp;3D's behavior scheduler to invoke a behavior's <code>processStimulus</code>
-method whenever
-</p>
-<ul>
- <li>The center of an active ViewPlatform enters a specified region.</li>
-</ul>
-<ul>
- <li>The center of an active ViewPlatform exits a specified region.</li>
-</ul>
-<ul>
- <li>A behavior is activated.</li>
-</ul>
-<ul>
- <li>A behavior is deactivated.</li>
-</ul>
-<ul>
- <li>A specified TransformGroup node's transform changes.</li>
-</ul>
-<ul>
- <li>Collision is detected between a specified Shape3D node's Geometry
-object and any other object.</li>
-</ul>
-<ul>
- <li>Movement occurs between a specified Shape3D node's Geometry
-object and any other object with which it collides.</li>
-</ul>
-<ul>
- <li>A specified Shape3D node's Geometry object no longer collides
-with any other object.</li>
-</ul>
-<ul>
- <li>A specified Behavior object posts a specific event.</li>
-</ul>
-<ul>
- <li>A specified AWT event occurs.</li>
-</ul>
-<ul>
- <li>A specified time interval elapses.</li>
-</ul>
-<ul>
- <li>A specified number of frames have been drawn.</li>
-</ul>
-<ul>
- <li>The center of a specified Sensor enters a specified region.</li>
-</ul>
-<ul>
- <li>The center of a specified Sensor exits a specified region.</li>
-</ul>
-<p>A Behavior object constructs a <a href="../WakeupCriterion.html">WakeupCriterion</a>
-by constructing the
-appropriate criterion object. The Behavior object must provide the
-appropriate arguments (usually a reference to some scene graph object
-and possibly a region of interest). Thus, to specify a
-WakeupOnViewPlatformEntry, a behavior would specify the region that
-will cause the behavior to execute if an active ViewPlatform enters it.
-</p>
-<h3>Composing WakeupCriterion
-Objects</h3>
-<p>A Behavior object can combine multiple WakeupCriterion objects into
-a
-more powerful, composite WakeupCondition. Java&nbsp;3D behaviors
-construct a
-composite WakeupCondition in one of the following ways:
-</p>
-<ul>
- <li><a href="../WakeupAnd.html">WakeupAnd</a>: An array of
-WakeupCriterion objects ANDed together.</li>
-</ul>
-<pre> WakeupCriterion &amp;&amp; WakeupCriterion &amp;&amp; ...<br></pre>
-<ul>
- <li><a href="../WakeupOr.html">WakeupOr</a>: An array of
-WakeupCriterion objects ORed together.</li>
-</ul>
-<pre> WakeupCriterion || WakeupCriterion || ...<br></pre>
-<ul>
- <li><a href="../WakeupAndOfOrs.html">WakeupAndOfOrs</a>: An array of
-WakeupOr WakeupCondition objects that
-are then ANDed together.</li>
-</ul>
-<pre> WakeupOr &amp;&amp; WakeupOr &amp;&amp; ...<br></pre>
-<ul>
- <li><a href="../WakeupOrOfAnds.html">WakeupOrOfAnds</a>: An array of
-WakeupAnd WakeupCondition objects
-that are then ORed together.</li>
-</ul>
-<pre> WakeupAnd || WakeupAnd || ...<br></pre>
-<h2>Composing Behaviors</h2>
-<p>Behavior objects can condition themselves to awaken only when
-signaled
-by another Behavior node. The <a href="../WakeupOnBehaviorPost.html">WakeupOnBehaviorPost</a>
-WakeupCriterion
-takes as arguments a reference to a Behavior node and an integer. These
-two arguments allow a behavior to limit its wakeup criterion to a
-specific post by a specific behavior.
-</p>
-<p>The WakeupOnBehaviorPost WakeupCriterion permits behaviors to chain
-their computations, allowing parenthetical computations-one behavior
-opens a door and the second closes the same door, or one behavior
-highlights an object and the second unhighlights the same object.
-</p>
-<p>
-</p>
-<h2>Scheduling</h2>
-<p>As a virtual universe grows large, Java&nbsp;3D must carefully
-husband
-its
-resources to ensure adequate performance. In a 10,000-object virtual
-universe with 400 or so Behavior nodes, a naive implementation of Java
-3D could easily end up consuming the majority of its compute cycles in
-executing the behaviors associated with the 400 Behavior objects before
-it draws a frame. In such a situation, the frame rate could easily drop
-to unacceptable levels.
-</p>
-<p>Behavior objects are usually associated with geometric objects in
-the
-virtual universe. In our example of 400 Behavior objects scattered
-throughout a 10,000-object virtual universe, only a few of these
-associated geometric objects would be visible at a given time. A
-sizable fraction of the Behavior nodes-those associated with nonvisible
-objects-need not be executed. Only those relatively few Behavior
-objects that are associated with visible objects must be executed.
-</p>
-<p>Java&nbsp;3D mitigates the problem of a large number of Behavior
-nodes in
-a
-high-population virtual universe through execution culling-choosing to
-invoke only those behaviors that have high relevance.
-</p>
-<p>Java&nbsp;3D requires each behavior to have a <em>scheduling region</em>
-and to post a wakeup condition. Together a behavior's scheduling region
-and wakeup condition provide Java&nbsp;3D's behavior scheduler with
-sufficient domain knowledge to selectively prune behavior invocations
-and invoke only those behaviors that absolutely need to be executed.
-</p>
-<p>
-</p>
-<h2>How Java&nbsp;3D Performs
-Execution Culling</h2>
-<p>Java&nbsp;3D finds all scheduling regions associated with Behavior
-nodes
-and
-constructs a scheduling/volume tree. It also creates an AND/OR tree
-containing all the Behavior node wakeup criteria. These two data
-structures provide the domain knowledge Java&nbsp;3D needs to prune
-unneeded
-behavior execution (to perform "execution triage").
-</p>
-<p>Java&nbsp;3D must track a behavior's wakeup conditions only if an
-active
-ViewPlatform object's activation volume intersects with that Behavior
-object's scheduling region. If the ViewPlatform object's activation
-volume does not intersect with a behavior's scheduling region,
-Java&nbsp;3D
-can safely ignore that behavior's wakeup criteria.
-</p>
-<p>In essence, the Java&nbsp;3D scheduler performs the following
-checks:
-</p>
-<ul>
- <li>Find all Behavior objects with scheduling regions that intersect
-the active ViewPlatform object's activation volume.</li>
-</ul>
-<ul>
- <li>For each Behavior object within the ViewPlatform's activation
-volume, if that behavior's WakeupCondition is <code>true</code>,
-schedule that Behavior object for execution.</li>
-</ul>
-<p>Java&nbsp;3D's behavior scheduler executes those Behavior objects
-that
-have
-been scheduled by calling the behavior's <code>processStimulus</code>
-method.
-</p>
-<h2>Interpolator Behaviors</h2>
-<p>This section describes Java&nbsp;3D's predefined <a
- href="../Interpolator.html">Interpolator</a> behaviors.
-They are called <em>interpolators</em>
-because they smoothly interpolate between the two extreme values that
-an interpolator can produce. Interpolators perform simple behavioral
-acts, yet they provide broad functionality.
-</p>
-<p>The Java&nbsp;3D API provides interpolators for a number of
-functions:
-manipulating transforms within a TransformGroup, modifying the values
-of a Switch node, and modifying Material attributes such as color and
-transparency.
-</p>
-<p>These predefined Interpolator behaviors share the same mechanism for
-specifying and later for converting a temporal value into an alpha
-value. Interpolators consist of two portions: a generic portion that
-all interpolators share and a domain-specific portion.
-</p>
-<p>The generic portion maps time in milliseconds onto a value in the
-range
-[0.0, 1.0] inclusive. The domain-specific portion maps an alpha value
-in the range [0.0, 1.0] onto a value appropriate to the predefined
-behavior's range of outputs. An alpha value of 0.0 generates an
-interpolator's minimum value, an alpha value of 1.0 generates an
-interpolator's maximum value, and an alpha value somewhere in between
-generates a value proportionally in between the minimum and maximum
-values.
-</p>
-<h3>Mapping Time to Alpha</h3>
-<p>Several parameters control the mapping of time onto an alpha value
-(see
-the javadoc for the <a href="../Alpha.html">Alpha</a> object for a
-description of the API).
-That mapping is deterministic as long as its parameters do not change.
-Thus, two different interpolators with the same parameters will
-generate the same alpha value given the same time value. This means
-that two interpolators that do not communicate can still precisely
-coordinate their activities, even if they reside in different threads
-or even different processors-as long as those processors have
-consistent clocks.
-</p>
-<p><a href="#Figure_1">Figure
-1</a>
-shows the components of an interpolator's time-to-alpha mapping. Time
-is represented on the horizontal axis. Alpha is represented on the
-vertical axis. As we move from left to right, we see the alpha value
-start at 0.0, rise to 1.0, and then decline back to 0.0 on the
-right-hand side.
-</p>
-<p>On the left-hand side, the trigger time defines
-when this interpolator's waveform begins in milliseconds. The region
-directly to the right of the trigger time, labeled Phase Delay, defines
-a time period where the waveform does not change. During phase delays
-alpha is either 0 or 1, depending on which region it precedes.
-</p>
-<p>Phase delays provide an important means for offsetting multiple
-interpolators from one another, especially where the interpolators have
-all the same parameters. The next four regions, labeled <b>&#945;</b>
-increasing, <b>&#945;</b> at 1, <b>&#945;</b> decreasing, and
-<b>&#945;</b> at 0, all specify durations for
-the corresponding values
-of alpha.
-</p>
-<p>Interpolators have a loop count that determines how many times to
-repeat the sequence of alpha increasing, alpha at 1, alpha decreasing,
-and alpha at 0; they also have associated mode flags that enable either
-the increasing or decreasing portions, or both, of the waveform.
-</p>
-<p><a name="Figure_1"></a><img style="width: 500px; height: 141px;"
- alt="Time-to-Alpha Mapping" title="Time-to-Alpha Mapping"
- src="Behaviors1.gif">
-</p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 1</i> &#8211; An Interpolator's Generic
-Time-to-Alpha Mapping Sequence</b></font>
-</ul>
-<p>
-Developers can use the loop count in conjunction with the mode flags to
-generate various kinds of actions. Specifying a loop count of 1 and
-enabling the mode flag for only the alpha-increasing and alpha-at-1
-portion of the waveform, we would get the waveform shown in <a
- href="#Figure_2">Figure
-2</a>.
-</p>
-<p><a name="Figure_2"></a><img style="width: 241px; height: 100px;"
- alt="Alpha Increasing" title="Alpha Increasing" src="Behaviors2.gif">
-</p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 2</i> &#8211; An Interpolator Set to a Loop
-Count of 1 with Mode Flags Set to Enable
-Only the Alpha-Increasing and Alpha-at-1 Portion of the Waveform</b></font>
-</ul>
-<p>
-In <a href="#Figure_2">Figure
-2</a>,
-the alpha value is 0 before the combination of trigger time plus the
-phase delay duration. The alpha value changes from 0 to 1 over a
-specified interval of time, and thereafter the alpha value remains 1
-(subject to the reprogramming of the interpolator's parameters). A
-possible use of a single alpha-increasing value might be to combine it
-with a rotation interpolator to program a door opening.
-</p>
-<p>Similarly, by specifying a loop count of 1 and
-a mode flag that enables only the alpha-decreasing and alpha-at-0
-portion of the waveform, we would get the waveform shown in <a
- href="#Figure_3">Figure
-3</a>.
-</p>
-<p>In <a href="#Figure_3">Figure
-3</a>,
-the alpha value is 1 before the combination of trigger time plus the
-phase delay duration. The alpha value changes from 1 to 0 over a
-specified interval; thereafter the alpha value remains 0 (subject to
-the reprogramming of the interpolator's parameters). A possible use of
-a single <b>&#945;</b>-decreasing value might be to combine it with a
-rotation
-interpolator to program a door closing.
-</p>
-<p><a name="Figure_3"></a><img style="width: 241px; height: 88px;"
- alt="Alpha Decreasing" title="Alpha Decreasing" src="Behaviors3.gif">
-</p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 3</i> &#8211; An Interpolator Set to a Loop
-Count of 1 with Mode Flags Set to Enable
-Only the Alpha-Decreasing and Alpha-at-0 Portion of the Waveform</b></font>
-</ul>
-<p>
-We can combine both of the above waveforms by specifying a loop count
-of 1 and setting the mode flag to enable both the alpha-increasing and
-alpha-at-1 portion of the waveform as well as the alpha-decreasing and
-alpha-at-0 portion of the waveform. This combination would result in
-the waveform shown in <a href="#Figure_4">Figure
-4</a>.
-</p>
-<p><a name="Figure_4"></a><img style="width: 241px; height: 100px;"
- alt="Alpha Increasing &amp; Decreasing"
- title="Alpha Increasing &amp; Decreasing" src="Behaviors4.gif">
-</p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 4</i> &#8211; An Interpolator Set to a Loop
-Count of 1 with Mode Flags
-Set to Enable All Portions of the Waveform</b></font>
-</ul>
-<p>
-In <a href="#Figure_4">Figure
-4</a>,
-the alpha value is 0 before the combination of trigger time plus the
-phase delay duration. The alpha value changes from 0 to 1 over a
-specified period of time, remains at 1 for another specified period of
-time, then changes from 1 to 0 over a third specified period of time;
-thereafter the alpha value remains 0 (subject to the reprogramming of
-the interpolator's parameters). A possible use of an alpha-increasing
-value followed by an alpha-decreasing value might be to combine it with
-a rotation interpolator to program a door swinging open and then
-closing.
-</p>
-<p>By increasing the loop count, we can get
-repetitive behavior, such as a door swinging open and closed some
-number of times. At the extreme, we can specify a loop count of -1
-(representing infinity).
-</p>
-<p>We can construct looped versions of the waveforms shown in <a
- href="#Figure_2">Figure
-2</a>, <a href="#Figure_3">Figure
-3</a>, and <a href="#Figure_4">Figure
-4</a>. <a href="#Figure_5">Figure
-5</a> shows a looping interpolator with mode flags set to enable
-only the alpha-increasing and alpha-at-1 portion of the waveform.
-</p>
-<p><a name="Figure_5"></a><img style="width: 500px; height: 99px;"
- alt="Alpha Increasing Infinite Loop"
- title="Alpha Increasing Infinite Loop" src="Behaviors5.gif">
-</p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 5</i> &#8211; An Interpolator Set to Loop
-Infinitely and Mode Flags Set to Enable
-Only the Alpha-Increasing and Alpha-at-1 Portion of the Waveform</b></font>
-</ul>
-<p>
-In <a href="#Figure_5">Figure
-5</a>, alpha goes from 0 to 1 over a fixed duration of time, stays
-at 1 for another fixed duration of time, and then repeats.
-</p>
-<p>Similarly, <a href="#Figure_6">Figure
-6</a> shows a looping interpolator with mode flags set to enable
-only the alpha-decreasing and alpha-at-0 portion of the waveform.
-</p>
-<p><a name="Figure_6"></a><img style="width: 500px; height: 97px;"
- alt="Alpha Decreasing Infinite Loop"
- title="Alpha Decreasing Infinite Loop" src="Behaviors6.gif">
-</p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 6</i> &#8211; An Interpolator Set to Loop
-Infinitely and Mode Flags Set to Enable
-Only the Alpha-Decreasing and Alpha-at-0 Portion of the Waveform</b></font>
-</ul>
-<p>
-Finally, <a href="#Figure_7">Figure
-7</a> shows a looping interpolator with both the increasing and
-decreasing portions of the waveform enabled.
-</p>
-<p>In all three cases shown by <a href="#Figure_5">Figure
-5</a>, <a href="#Figure_6">Figure
-6</a>, and <a href="#Figure_7">Figure
-7</a>, we can compute the exact value of alpha at any point in time.
-</p>
-<p><a name="Figure_7"></a><img style="width: 500px; height: 99px;"
- alt="Alpha Increasing &amp; Decreasing Infinite Loop"
- title="Alpha Increasing &amp; Decreasing Infinite Loop"
- src="Behaviors7.gif">
-</p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 7</i> &#8211; An Interpolator Set to Loop
-Infinitely and Mode Flags Set
-to Enable All Portions of the Waveform</b></font>
-</ul>
-<p>
-Java&nbsp;3D's preprogrammed behaviors permit other behaviors to change
-their parameters. When such a change occurs, the alpha value changes to
-match the state of the newly parameterized interpolator.
-</p>
-<h3>Acceleration of Alpha</h3>
-<p>Commonly, developers want alpha to change slowly at first and then
-to
-speed up until the change in alpha reaches some appropriate rate. This
-is analogous to accelerating your car up to the speed limit-it does not
-start off immediately at the speed limit. Developers specify this
-"ease-in, ease-out" behavior through two additional parameters, the <code>increasingAlphaRampDuration</code>
-and the <code>decreasing-AlphaRampDuration</code>.
-</p>
-<p>Each of these parameters specifies a period within the increasing or
-decreasing alpha duration region during which the "change in alpha" is
-accelerated (until it reaches its maximum per-unit-of-time step size)
-and then symmetrically decelerated. <a href="#Figure_8">Figure
-8</a> shows three general examples of how the <code>increasingAlphaRampDuration</code>
-method can be used to modify the alpha waveform. A value of 0 for the
-increasing ramp duration implies that <b>&#945;</b>
-is not accelerated; it changes at a constant rate. A value of 0.5 or
-greater (clamped to 0.5) for this increasing ramp duration implies that
-the change in <b>&#945;</b> is accelerated during the first half of the
-period and
-then decelerated during the second half of the period. For a value of <em>n</em>
-that is less than 0.5, alpha is accelerated for duration <em>n</em>,
-held constant for duration (1.0 - 2<em>n</em>), then decelerated for
-duration <em>n</em> of the period.
-</p>
-<p><a name="Figure_8"></a><img style="width: 500px; height: 354px;"
- alt="Alpha acceleration" title="Alpha acceleration"
- src="Behaviors8.gif">
-</p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 8</i> &#8211; How an Alpha-Increasing Waveform
-Changes with Various
-Values of increasing-AlphaRampDuration</b></font>
-</ul>
-</body>
-</html>
diff --git a/src/main/java/org/jogamp/java3d/doc-files/Behaviors1.gif b/src/main/java/org/jogamp/java3d/doc-files/Behaviors1.gif
deleted file mode 100644
index bb288ce..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/Behaviors1.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/Behaviors2.gif b/src/main/java/org/jogamp/java3d/doc-files/Behaviors2.gif
deleted file mode 100644
index 005564f..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/Behaviors2.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/Behaviors3.gif b/src/main/java/org/jogamp/java3d/doc-files/Behaviors3.gif
deleted file mode 100644
index a8beb09..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/Behaviors3.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/Behaviors4.gif b/src/main/java/org/jogamp/java3d/doc-files/Behaviors4.gif
deleted file mode 100644
index 685bcb7..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/Behaviors4.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/Behaviors5.gif b/src/main/java/org/jogamp/java3d/doc-files/Behaviors5.gif
deleted file mode 100644
index 74783fb..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/Behaviors5.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/Behaviors6.gif b/src/main/java/org/jogamp/java3d/doc-files/Behaviors6.gif
deleted file mode 100644
index 8614a4e..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/Behaviors6.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/Behaviors7.gif b/src/main/java/org/jogamp/java3d/doc-files/Behaviors7.gif
deleted file mode 100644
index 0f2ce48..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/Behaviors7.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/Behaviors8.gif b/src/main/java/org/jogamp/java3d/doc-files/Behaviors8.gif
deleted file mode 100644
index d048cfa..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/Behaviors8.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/Concepts.html b/src/main/java/org/jogamp/java3d/doc-files/Concepts.html
deleted file mode 100644
index 7b005af..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/Concepts.html
+++ /dev/null
@@ -1,291 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
- <meta content="text/html; charset=ISO-8859-1"
- http-equiv="content-type">
- <title>Java 3D API - Concepts</title>
-</head>
-<body>
-<h2>Java 3D Concepts</h2>
-<p>The Java 3D API specification serves to define objects, methods, and
-their actions precisely. Describing how to use an API belongs in a
-tutorial or programmer's
-reference manual, and is well beyond the scope of this specification.
-However, a short introduction to the main concepts in Java 3D will
-provide the context for understanding the detailed, but isolated,
-specification found in the class and method descriptions. We introduce
-some of the key Java 3D concepts and illustrate them with some simple
-program fragments.
-</p>
-<p>
-</p>
-<h2>Basic Scene Graph Concepts</h2>
-<p>A scene graph is a "tree" structure that contains data arranged in a
-hierarchical manner. The scene graph consists of parent nodes, child
-nodes, and data objects. The parent nodes, called Group nodes, organize
-and, in some cases, control how Java 3D interprets their descendants.
-Group nodes serve as the glue that holds a scene graph together. Child
-nodes can be either Group nodes or Leaf nodes. Leaf nodes have no
-children. They encode the core semantic elements of a scene graph- for
-example, what to draw (geometry), what to play (audio), how to
-illuminate objects (lights), or what code to execute (behaviors). Leaf
-nodes refer to data objects, called NodeComponent objects.
-NodeComponent objects are not scene graph nodes, but they contain the
-data that Leaf nodes require, such as the geometry to draw or the sound
-sample to play.
-</p>
-<p>A Java 3D application builds and manipulates a scene graph by
-constructing Java 3D objects and then later modifying those objects by
-using their methods. A Java 3D program first constructs a scene graph,
-then, once built, hands that scene graph to Java 3D for processing.
-</p>
-<p>The structure of a scene graph determines the relationships among
-the
-objects in the graph and determines which objects a programmer can
-manipulate as a single entity. Group nodes provide a single point for
-handling or manipulating all the nodes beneath it. A programmer can
-tune a scene graph appropriately by thinking about what manipulations
-an application will need to perform. He or she can make a particular
-manipulation easy or difficult by grouping or regrouping nodes in
-various ways.
-</p>
-<p>
-</p>
-<h3>Constructing a Simple Scene
-Graph</h3>
-<p>The following code constructs a simple scene graph consisting of a
-group node and two leaf
-nodes.<br>
-</p>
-<p><font size="-1"><b><a name="Listing_1">
-<i>Listing 1</i> &#8211; Code for Constructing a Simple Scene Graph
-</a></b></font></p>
-<hr>
-<pre>Shape3D myShape1 = new Shape3D(myGeometry1, myAppearance1);<br>Shape3D myShape2 = new Shape3D(myGeometry2);<br>myShape2.setAppearance(myAppearance2);<br><br>Group myGroup = new Group();<br>myGroup.addChild(myShape1);<br>myGroup.addChild(myShape2);<br></pre>
-<hr>
-<p>It first constructs one leaf node, the first of two Shape3D
-nodes, using a constructor that takes both a Geometry and an Appearance
-NodeComponent object. It then constructs the second Shape3D node, with
-only a Geometry object. Next, since the second Shape3D node was created
-without an Appearance object, it supplies the missing Appearance object
-using the Shape3D node's <code>setAppearance</code> method. At this
-point both leaf nodes have been fully constructed. The code next
-constructs a group node to hold the two leaf nodes. It
-uses the Group node's <code>addChild</code> method to add the two leaf
-nodes as children to the group node, finishing the construction of the
-scene graph. <a href="#Figure_1">Figure
-1</a>
-shows the constructed scene graph, all the nodes, the node component
-objects, and the variables used in constructing the scene graph.
-</p>
-<p><a name="Figure_1"></a><img style="width: 491px; height: 279px;"
- alt="A Simple Scene Graph" title="A Simple Scene Graph"
- src="Concepts1.gif">
-</p>
-<ul>
- <font size="-1"><b><i>Figure 1</i> &#8211; A Simple Scene Graph</b></font>
-</ul>
-<h3>A Place For Scene Graphs</h3>
-Once a scene graph has been constructed, the
-question becomes what to do with it? Java 3D cannot start rendering a
-scene graph until a program "gives" it the scene graph. The program
-does this by inserting the scene graph into the virtual universe.
-<p>Java 3D places restrictions on how a program can insert a scene
-graph
-into a universe.
-</p>
-<p>A Java 3D environment consists of two superstructure objects,
-VirtualUniverse and Locale, and one or more graphs, rooted by a special
-BranchGroup node. <a href="#Figure_2">Figure 2</a> shows these objects
-in context with other scene graph objects.
-</p>
-<p>The VirtualUniverse object defines a universe. A universe allows a
-Java
-3D program to create a separate and distinct arena for defining objects
-and their relationships to one another. Typically, Java 3D programs
-have only one VirtualUniverse object. Programs that have more than one
-VirtualUniverse may share NodeComponent objects but not scene graph
-node objects.
-</p>
-<p>The Locale object specifies a fixed position within the universe.
-That
-fixed position defines an origin for all scene graph nodes beneath it.
-The Locale object allows a programmer to specify that origin very
-precisely and with very high dynamic range. A Locale can accurately
-specify a location anywhere in the known physical universe and at the
-precision of Plank's distance. Typically, Java 3D programs have only
-one Locale object with a default origin of (0, 0, 0). Programs that
-have more than one Locale object will set the location of the
-individual Locale objects so that they provide an appropriate local
-origin for the nodes beneath them. For example, to model the Mars
-landing, a programmer might create one Locale object with an origin at
-Cape Canaveral and another with an origin located at the landing site
-on Mars.
-</p>
-<p><a name="Figure_2"></a><img style="width: 500px; height: 286px;"
- alt="Content Branch, View Branch, Superstructure"
- title="Superstructure" src="Concepts2.gif">
-</p>
-<ul>
- <font size="-1"><b><i>Figure 2</i> &#8211; Content Branch, View Branch, and
-Superstructure</b></font>
-</ul>
-<p>
-The BranchGroup node serves as the root of a <em>branch graph</em>.
-Collectively, the BranchGroup node and all of its children form the
-branch graph. The two kinds of branch graphs are called content
-branches and view branches. A <em>content branch</em> contains only
-content-related leaf nodes, while a <em>view branch</em>
-contains a ViewPlatform leaf node and may contain other content-related
-leaf nodes. Typically, a universe contains more than one branch
-graph-one view branch, and any number of content branches.
-</p>
-<p>Besides serving as the root of a branch graph, the BranchGroup node
-has
-two special properties: It alone may be inserted into a Locale object,
-and it may be compiled. Java 3D treats uncompiled and compiled branch
-graphs identically, though compiled branch graphs will typically render
-more efficiently.
-</p>
-<p>We could not insert the scene graph created by our simple example (<a
- href="#Listing_1">Listing
-1</a>) into a Locale because it does not have a BranchGoup node for
-its root. <a href="#Listing_2">Listing 2</a>
-shows a modified version of our first code example that creates a
-simple content branch graph and the minimum of superstructure objects.
-Of special note, Locales do not have children, and they are not part of
-the scene graph. The method for inserting a branch graph is <code>addBranchGraph</code>,
-whereas <code>addChild</code> is the method for adding children to all
-group nodes.</p>
-<p><font size="-1"><b>
-<i><a name="Listing_2"></a>Listing 2</i> &#8211; Code for Constructing a
-Scene Graph and Some
-Superstructure Objects
-</b></font></p>
-<hr>
-<pre>Shape3D myShape1 = new Shape3D(myGeometry1, myAppearance1);<br>Shape3D myShape2 = new Shape3D(myGeometry2, myAppearance2);<br><br>BranchGroup myBranch = new BranchGroup();<br>myBranch.addChild(myShape1);<br>myBranch.addChild(myShape2);<br>myBranch.compile();<br><br>VirtualUniverse myUniverse = new VirtualUniverse();<br>Locale myLocale = new Locale(myUniverse);<br>myLocale.addBranchGraph(myBranch);<br></pre>
-<hr>
-<h3>SimpleUniverse Utility</h3>
-Most Java 3D programs build an identical set of superstructure and view
-branch objects, so the Java 3D utility packages provide a <code>universe</code>
-package for constructing and manipulating the objects in a view branch.
-The classes in the <code>universe</code> package provide a quick means
-for building a single view (single window) application. <a
- href="#Listing_3">Listing 3</a>
-shows a code fragment for using the SimpleUniverse class. Note that the
-SimpleUniverse constructor takes a Canvas3D as an argument, in this
-case referred to by the variable <code>myCanvas</code>.
-<p><font size="-1"><b><i><a name="Listing_3"></a>Listing 3</i> &#8211; Code
-for Constructing a Scene Graph Using the Universe
-Package
-</b></font></p>
-<hr>
-<pre>import com.sun.j3d.utils.universe.*;<br><br>Shape3D myShape1 = new Shape3D(myGeometry1, myAppearance1);<br>Shape3D myShape2 = new Shape3D(myGeometry2, myAppearance2);<br><br>BranchGroup myBranch = new BranchGroup();<br>myBranch.addChild(myShape1);<br>myBranch.addChild(myShape2);<br>myBranch.compile();<br><br>SimpleUniverse myUniv = new SimpleUniverse(myCanvas);<br>myUniv.addBranchGraph(myBranch);<br></pre>
-<hr>
-<h3>Processing a Scene Graph</h3>
-When given a scene graph, Java 3D processes that scene graph as
-efficiently as possible. How a Java 3D implementation processes a scene
-graph can vary, as long as the implementation conforms to the semantics
-of the API. In general, a Java 3D implementation will render all
-visible objects, play all enabled sounds, execute all triggered
-behaviors, process any identified input devices, and check for and
-generate appropriate collision events.
-<p>The order that a particular Java 3D implementation renders objects
-onto
-the display is carefully not defined. One implementation might render
-the first Shape3D object and then the second. Another might first
-render the second Shape3D node before it renders the first one. Yet
-another implementation may render both Shape3D nodes in parallel.
-</p>
-<p>
-</p>
-<h2>Features of Java 3D</h2>
-Java 3D allows a programmer to specify a broad range of information. It
-allows control over the shape of objects, their color, and
-transparency. It allows control over background effects, lighting, and
-environmental effects such as fog. It allows control over the placement
-of all objects (even nonvisible objects such as lights and behaviors)
-in the scene graph and over their orientation and scale. It allows
-control over how those objects move, rotate, stretch, shrink, or morph
-over time. It allows control over what code should execute, what sounds
-should play, and how they should sound and change over time.
-<p>Java 3D provides different techniques for controlling the effect of
-various features. Some techniques act fairly locally, such as getting
-the color of a vertex. Other techniques have broader influence, such as
-changing the color or appearance of an entire object. Still other
-techniques apply to a broad number of objects. In the first two cases,
-the programmer can modify a particular object or an object associated
-with the affected object. In the latter case, Java 3D provides a means
-for specifying more than one object spatially.
-</p>
-<p>
-</p>
-<h3>Bounds</h3>
-Bounds objects allow a programmer to define a volume in space. There
-are three ways to specify this volume: as a box, a sphere, or a set of
-planes enclosing a space.
-<p>Bounds objects specify a volume in which particular operations
-apply.
-Environmental effects such as lighting, fog, alternate appearance, and
-model clipping planes use bounds objects to specify their region of
-influence. Any object that falls within the space defined by the bounds
-object has the particular environmental effect applied. The proper use
-of bounds objects can ensure that these environmental effects are
-applied only to those objects in a particular volume, such as a light
-applying only to the objects within a single room.
-</p>
-<p>Bounds objects are also used to specify a region of action.
-Behaviors
-and sounds execute or play only if they are close enough to the viewer.
-The use of behavior and sound bounds objects allows Java 3D to cull
-away those behaviors and sounds that are too far away to affect the
-viewer (listener). By using bounds properly, a programmer can ensure
-that only the relevant behaviors and sounds execute or play.
-</p>
-<p>Finally, bounds objects are used to specify a region of application
-for
-per-view operations such as background, clip, and soundscape selection.
-For example, the background node whose region of application is closest
-to the viewer is selected for a given view.
-</p>
-<p>
-</p>
-<h3>Nodes</h3>
-All scene graph nodes have an implicit location in space of (0, 0, 0).
-For objects that exist in space, this implicit location provides a
-local coordinate system for that object, a fixed reference point. Even
-abstract objects that may not seem to have a well-defined location,
-such as behaviors and ambient lights, have this implicit location. An
-object's location provides an origin for its local coordinate system
-and, just as importantly, an origin for any bounding volume information
-associated with that object.
-<h3>Live and/or Compiled</h3>
-All scene graph objects, including nodes and node component objects,
-are either part of an active universe or not. An object is said to be <em>live</em>
-if it is part of an active universe. Additionally, branch graphs are
-either <em>compiled</em>
-or not. When a node is either live or compiled, Java 3D enforces access
-restrictions to nodes and node component objects. Java 3D allows only
-those operations that are enabled by the program before a node or node
-component becomes live or is compiled. It is best to set capabilities
-when you build your content. <a href="#Listing_4">Listing 4</a> shows
-an example where we create a TransformGroup node and
-enable it for writing.
-<p><font size="-1"><b><i><a name="Listing_4"></a>Listing 4</i> &#8211;
-Capabilities Example
-</b></font></p>
-<hr>
-<pre>TransformGroup myTrans = new TransformGroup();<br>myTrans.setCapability(Transform.ALLOW_TRANSFORM_WRITE);<br></pre>
-<hr>
-<p>By setting the capability to write the transform, Java 3D will allow
-the following code to execute:
-</p>
-<pre>myTrans.setTransform3D(myT3D);<br></pre>
-<p>It is important to ensure that all needed capabilities are set and
-that
-unnecessary capabilities are not set. The process of compiling a branch
-graph examines the capability bits and uses that information to reduce
-the amount of computation needed to run a program.
-</p>
-</body>
-</html>
diff --git a/src/main/java/org/jogamp/java3d/doc-files/Concepts1.gif b/src/main/java/org/jogamp/java3d/doc-files/Concepts1.gif
deleted file mode 100644
index 8aa0dbc..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/Concepts1.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/Concepts2.gif b/src/main/java/org/jogamp/java3d/doc-files/Concepts2.gif
deleted file mode 100644
index f21e085..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/Concepts2.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/DAG.gif b/src/main/java/org/jogamp/java3d/doc-files/DAG.gif
deleted file mode 100644
index 8479136..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/DAG.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/HelloUniverse.html b/src/main/java/org/jogamp/java3d/doc-files/HelloUniverse.html
deleted file mode 100644
index 5e37bd6..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/HelloUniverse.html
+++ /dev/null
@@ -1,21 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
- <meta content="text/html; charset=ISO-8859-1"
- http-equiv="content-type">
- <title>HelloUniverse</title>
-</head>
-<body>
-<h2>HelloUniverse: A Sample Java
-3D Program</h2>
-<p>Here are code fragments from a simple program, <code>HelloUniverse.java</code>,
-that creates a cube and a RotationInterpolator behavior object that
-rotates the cube at a constant rate of pi/2 radians per second. The
-HelloUniverse class creates the branch graph
-that includes the cube and the RotationInterpolator behavior. It then
-adds this branch graph to the Locale object generated by the
-SimpleUniverse utility.
-</p>
-<pre><hr><br>public class HelloUniverse ... {<br> public BranchGroup createSceneGraph() {<br><i> // Create the root of the branch graph<br></i> BranchGroup objRoot = new BranchGroup();<br><br><i> // Create the TransformGroup node and initialize it to the<br> // identity. Enable the TRANSFORM_WRITE capability so that<br> // our behavior code can modify it at run time. Add it to<br> // the root of the subgraph.<br></i> TransformGroup objTrans = new TransformGroup();<br> objTrans.setCapability(<br> TransformGroup.ALLOW_TRANSFORM_WRITE);<br> objRoot.addChild(objTrans);<br><br><i> // Create a simple Shape3D node; add it to the scene graph.<br></i> objTrans.addChild(new ColorCube(0.4));<br><br><i> // Create a new Behavior object that will perform the<br> // desired operation on the specified transform and add<br> // it into the scene graph.<br></i> Transform3D yAxis = new Transform3D();<br> Alpha rotationAlpha = new Alpha(-1, 4000);<br> RotationInterpolator rotator = new RotationInterpolator(<br> rotationAlpha, objTrans, yAxis,<br> 0.0f, (float) Math.PI*2.0f);<br> BoundingSphere bounds =<br> new BoundingSphere(new Point3d(0.0,0.0,0.0), 100.0);<br> rotator.setSchedulingBounds(bounds);<br> objRoot.addChild(rotator);<br><br><i> // Have Java 3D perform optimizations on this scene graph.</i><br> objRoot.compile();<br><br> return objRoot;<br> }<br><br> public HelloUniverse() {<br><i> &lt;set layout of container, construct canvas3d, add canvas3d&gt;<br><br> // Create the scene; attach it to the virtual universe<br></i> BranchGroup scene = createSceneGraph();<br> SimpleUniverse u = new SimpleUniverse(canvas3d);<br> u.getViewingPlatform().setNominalViewingTransform();<br> u.addBranchGraph(scene);<br> }<br>}</pre>
-</body>
-</html>
diff --git a/src/main/java/org/jogamp/java3d/doc-files/Immediate.html b/src/main/java/org/jogamp/java3d/doc-files/Immediate.html
deleted file mode 100644
index 101fe22..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/Immediate.html
+++ /dev/null
@@ -1,114 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
- <meta content="text/html; charset=ISO-8859-1"
- http-equiv="content-type">
- <title>Java 3D API - Immediate-Mode Rendering</title>
-</head>
-<body>
-<h2>Immediate-Mode Rendering</h2>
-<p>Java&nbsp;3D is fundamentally a scene graph-based API. Most of
-the constructs in the API are biased toward retained mode and
-compiled-retained mode rendering. However, there are some applications
-that want both the control and the flexibility that immediate-mode
-rendering offers.
-</p>
-<p>Immediate-mode applications can either use or ignore Java&nbsp;3D's
-scene
-graph structure. By using immediate mode, end-user applications have
-more freedom, but this freedom comes at the expense of performance. In
-immediate mode, Java&nbsp;3D has no high-level information concerning
-graphical objects or their composition. Because it has minimal global
-knowledge, Java&nbsp;3D can perform only localized optimizations on
-behalf
-of the application programmer.
-</p>
-<p>
-</p>
-<h2>Two Styles of Immediate-Mode
-Rendering</h2>
-Use of Java&nbsp;3D's immediate mode falls into one of two categories:
-pure
-immediate-mode rendering and mixed-mode rendering in which immediate
-mode and retained or compiled-retained mode interoperate and render to
-the same canvas. The Java&nbsp;3D renderer is idle in pure immediate
-mode,
-distinguishing it from mixed-mode rendering.
-<h3>Pure Immediate-Mode
-Rendering</h3>
-Pure immediate-mode rendering provides for those applications and
-applets that do not want Java&nbsp;3D to do any automatic rendering of
-the
-scene graph. Such applications may not even wish to build a scene graph
-to represent their graphical data. However, they use Java&nbsp;3D's
-attribute objects to set graphics state and Java&nbsp;3D's geometric
-objects
-to render geometry.
-<hr noshade="noshade"><b>Note:</b> Scene antialiasing is not supported
-in pure immediate mode.
-<hr noshade="noshade">A pure immediate mode application must create a
-minimal set of Java&nbsp;3D
-objects before rendering. In addition to a Canvas3D object, the
-application must create a View object, with its associated PhysicalBody
-and PhysicalEnvironment objects, and the following scene graph
-elements: a VirtualUniverse object, a high-resolution Locale object, a
-BranchGroup node object, a TransformGroup node object with associated
-transform, and, finally, a ViewPlatform leaf node object that defines
-the position and orientation within the virtual universe that generates
-the view (see <a href="#Figure_1">Figure
-1</a>).
-<p><a name="Figure_1"></a><img style="width: 500px; height: 359px;"
- alt="Minimal Immediate-Mode Structure"
- title="Minimal Immediate-Mode Structure" src="Immediate1.gif"></p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 1</i> &#8211; Minimal Immediate-Mode Structure</b></font>
-</ul>
-<p>
-Java&nbsp;3D provides utility functions that create much of this
-structure
-on behalf of a pure immediate-mode application, making it less
-noticeable from the application's perspective-but the structure must
-exist.
-</p>
-<p>All rendering is done completely under user control. It is necessary
-for the user to clear the 3D canvas, render all geometry, and swap the
-buffers. Additionally, rendering the right and left eye for stereo
-viewing becomes the sole responsibility of the application.
-</p>
-<p>In pure immediate mode, the user must stop the Java&nbsp;3D
-renderer, via
-the Canvas3D object <code>stopRenderer()</code>
-method, prior to adding the Canvas3D object to an active View object
-(that is, one that is attached to a live ViewPlatform object).
-</p>
-<p>
-</p>
-<h3>Mixed-Mode Rendering</h3>
-Mixing immediate mode and retained or compiled-retained mode requires
-more structure than pure immediate mode. In mixed mode, the
-Java&nbsp;3D
-renderer is running continuously, rendering the scene graph into the
-canvas.
-<p>The basic Java&nbsp;3D <em>stereo</em> rendering loop, executed for
-each
-Canvas3D, is as follows:
-</p>
-<pre><hr><br>clear canvas (both eyes)<br></pre>
-<pre>call preRender() <strong><kbd>// user-supplied method<br></kbd></strong>set left eye view<br>render opaque scene graph objects<br>call renderField(FIELD_LEFT) <strong><kbd>// user-supplied method<br></kbd></strong>render transparent scene graph objects<br>set right eye view<br>render opaque scene graph objects again<br>call renderField(FIELD_RIGHT) <strong><kbd>// user-supplied method<br></kbd></strong>render transparent scene graph objects again<br>call postRender() <strong><kbd>// user-supplied method<br></kbd></strong>synchronize and swap buffers<br></pre>
-<pre>call postSwap() <strong><kbd>// user-supplied method<br></kbd></strong><br><hr></pre>
-The basic Java&nbsp;3D <em>monoscopic</em> rendering loop is as
-follows:
-<pre><hr><br>clear canvas<br></pre>
-<pre>call preRender() <strong><kbd>// user-supplied method<br></kbd></strong>set view<br>render opaque scene graph objects<br>call renderField(FIELD_ALL) <strong><kbd>// user-supplied method<br></kbd></strong>render transparent scene graph objects<br>call postRender() <strong><kbd>// user-supplied method<br></kbd></strong>synchronize and swap buffers<br></pre>
-<pre>call postSwap() <strong><kbd>// user-supplied method<br></kbd></strong><br><hr></pre>
-In both cases, the entire loop, beginning with clearing the canvas and
-ending with swapping the buffers, defines a frame. The application is
-given the opportunity to render immediate-mode geometry at any of the
-clearly identified spots in the rendering loop. A user specifies his or
-her own rendering methods by extending the Canvas3D class and
-overriding the <code>preRender</code>, <code>postRender</code>, <code>postSwap</code>,
-and/or <code>renderField</code> methods.
-</body>
-</html>
diff --git a/src/main/java/org/jogamp/java3d/doc-files/Immediate1.gif b/src/main/java/org/jogamp/java3d/doc-files/Immediate1.gif
deleted file mode 100644
index 2d549b1..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/Immediate1.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/Rendering.html b/src/main/java/org/jogamp/java3d/doc-files/Rendering.html
deleted file mode 100644
index 7415ce8..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/Rendering.html
+++ /dev/null
@@ -1,148 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
- <meta content="text/html; charset=ISO-8859-1"
- http-equiv="content-type">
- <title>Java 3D API - Execution and Rendering Model</title>
-</head>
-<body>
-<h2>Execution and Rendering Model</h2>
-<p>Java&nbsp;3D's execution and rendering model assumes the
-existence of a <a href="../VirtualUniverse.html">VirtualUniverse</a>
-object and an attached scene graph. This
-scene graph can be minimal and not noticeable from an application's
-perspective when using immediate-mode rendering, but it must exist.
-</p>
-<p>Java&nbsp;3D's execution model intertwines with its rendering modes
-and
-with
-behaviors and their scheduling. This chapter first describes the three
-rendering modes, then describes how an application starts up a
-Java&nbsp;3D
-environment, and finally it discusses how the various rendering modes
-work within this framework.
-</p>
-<p>
-</p>
-<h2>Three Major Rendering Modes</h2>
-<p>Java&nbsp;3D supports three different modes for rendering scenes:
-immediate
-mode, retained mode, and compiled-retained mode. These three levels of
-API support represent a potentially large variation in graphics
-processing speed and in on-the-fly restructuring.
-</p>
-<p></p>
-<h3>Immediate Mode</h3>
-<p>Immediate mode allows maximum flexibility at some cost in rendering
-speed. The application programmer can either use or ignore the scene
-graph structure inherent in Java&nbsp;3D's design. The programmer can
-choose
-to draw geometry directly or to define a scene graph. Immediate mode
-can be either used independently or mixed with retained and/or
-compiled-retained mode rendering. The immediate-mode API is described
-in the "<a href="Immediate.html">Immediate-Mode Rendering</a>" section.</p>
-<p>
-</p>
-<h3>Retained Mode</h3>
-<p>Retained mode allows a great deal of the flexibility provided by
-immediate mode while also providing a substantial increase in rendering
-speed. All objects defined in the scene graph are accessible and
-manipulable. The scene graph itself is fully manipulable. The
-application programmer can rapidly construct the scene graph, create
-and delete nodes, and instantly "see" the effect of edits. Retained
-mode also allows maximal access to objects through a general pick
-capability.
-</p>
-<p>Java&nbsp;3D's retained mode allows a programmer to construct
-objects,
-insert objects into a database, compose objects, and add behaviors to
-objects.
-</p>
-<p>In retained mode, Java&nbsp;3D knows that the programmer has defined
-objects, knows how the programmer has combined those objects into
-compound objects or scene graphs, and knows what behaviors or actions
-the programmer has attached to objects in the database. This knowledge
-allows Java&nbsp;3D to perform many optimizations. It can construct
-specialized data structures that hold an object's geometry in a manner
-that enhances the speed at which the Java&nbsp;3D system can render it.
-It
-can compile object behaviors so that they run at maximum speed when
-invoked. It can flatten transformation manipulations and state changes
-where possible in the scene graph.
-</p>
-<p>
-</p>
-<h3>Compiled-Retained Mode</h3>
-<p>Compiled-retained mode allows the Java&nbsp;3D API to perform an
-arbitrarily
-complex series of optimizations including, but not restricted to,
-geometry compression, scene graph flattening, geometry grouping, and
-state change clustering.
-</p>
-<p>Compiled-retained mode provides hooks for end-user manipulation and
-picking. Pick operations return the closest object (in scene graph
-space) associated with the picked geometry.
-</p>
-<p>Java&nbsp;3D's compiled-retained mode ensures effective graphics
-rendering
-speed in yet one more way. A programmer can request that Java&nbsp;3D
-compile an object or a scene graph. Once it is compiled, the programmer
-has minimal access to the internal structure of the object or scene
-graph. Capability flags provide access to specified components that the
-application program may need to modify on a continuing basis.
-</p>
-<p>A compiled object or scene graph consists of whatever internal
-structures Java&nbsp;3D wishes to create to ensure that objects or
-scene
-graphs render at maximal rates. Because Java&nbsp;3D knows that the
-majority
-of the compiled object's or scene graph's components will not change,
-it can perform an extraordinary number of optimizations, including the
-fusing of multiple objects into one conceptual object, turning an
-object into compressed geometry or even breaking an object up into
-like-kind components and reassembling the like-kind components into new
-"conceptual objects."
-</p>
-<p>
-</p>
-<h2>Instantiating the Render Loop</h2>
-<p>From an application's perspective, Java&nbsp;3D's render loop runs
-continuously. Whenever an application adds a scene branch to the
-virtual world, that scene branch is instantly visible. This high-level
-view of the render loop permits concurrent implementations of
-Java&nbsp;3D
-as well as serial implementations. The remainder of this section
-describes the Java&nbsp;3D render loop bootstrap process from a
-serialized
-perspective. Differences that would appear in concurrent
-implementations are noted as well.
-</p>
-<p></p>
-<h3>An Application-Level
-Perspective</h3>
-<p>First the application must construct its scene graphs. It does this
-by
-constructing scene graph nodes and component objects and linking them
-into self-contained trees with a BranchGroup node as a root. The
-application next must obtain a reference to any constituent nodes or
-objects within that branch that it may wish to manipulate. It sets the
-capabilities of all the objects to match their anticipated use and only
-then compiles the branch using the BranchGroup's <code>compile</code>
-method. Whether it compiles the branch, the application can add it to
-the virtual universe by adding the BranchGroup to a Locale object. The
-application repeats this process for each branch it wishes to create.
-Note that for concurrent Java&nbsp;3D implementations, whenever an
-application adds a branch to the active virtual universe, that branch
-becomes visible.
-</p>
-<p></p>
-<h3>Retained and
-Compiled-Retained Rendering Modes</h3>
-<p>This initialization process is identical for retained and
-compiled-retained modes. In both modes, the application builds a scene
-graph. In compiled-retained mode, the application compiles the scene
-graph. Then the application inserts the (possibly compiled) scene graph
-into the virtual universe.
-</p>
-</body>
-</html>
diff --git a/src/main/java/org/jogamp/java3d/doc-files/SceneGraphOverview.html b/src/main/java/org/jogamp/java3d/doc-files/SceneGraphOverview.html
deleted file mode 100644
index f1616df..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/SceneGraphOverview.html
+++ /dev/null
@@ -1,226 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
- <meta content="text/html; charset=ISO-8859-1"
- http-equiv="content-type">
- <title>Java 3D API - Scene Graph Overview</title>
-</head>
-<body>
-<h2>Scene Graph Basics</h2>
-<p>A scene graph consists of Java 3D
-objects, called <em>nodes</em>,
-arranged in a tree structure. The user creates one or more scene
-subgraphs and attaches them to a virtual universe. The individual
-connections between Java 3D nodes always represent a directed
-relationship: parent to child. Java 3D restricts scene graphs in one
-major way: Scene graphs may not contain cycles. Thus, a Java 3D scene
-graph is a directed acyclic graph (DAG). See <a href="#Figure_1">Figure
-1</a>.
-</p>
-<p>Java 3D refines the <a href="../Node.html">Node</a> object class
-into two subclasses: <a href="../Group.html">Group</a>
-and
-<a href="../Leaf.html">Leaf</a> node objects. Group node objects group
-together one or more child
-nodes. A group node can point to zero or more children but can have
-only one parent. The SharedGroup node cannot have any parents (although
-it allows sharing portions of a scene graph, as described in "<a
- href="SceneGraphSharing.html">Reusing Scene Graphs</a>").
-Leaf node objects contain the actual definitions of shapes (geometry),
-lights, fog, sounds, and so forth. A leaf node has no children and only
-one parent. The semantics of the various group and leaf nodes are
-described in subsequent chapters. </p>
-<h2>Scene Graph Structure</h2>
-<p>A scene graph organizes and controls the rendering
-of its constituent objects. The Java 3D renderer draws a scene graph in
-a consistent way that allows for concurrence. The Java 3D renderer can
-draw one object independently of other objects. Java 3D can allow such
-independence because its scene graphs have a particular form and cannot
-share state among branches of a tree.
-</p>
-<h3>Spatial Separation</h3>
-<p>The hierarchy of the scene graph encourages a natural spatial
-grouping
-on the geometric objects found at the leaves of the graph. Internal
-nodes act to group their children together. A group node also defines a
-spatial bound that contains all the geometry defined by its
-descendants. Spatial grouping allows for efficient implementation of
-operations such as proximity detection, collision detection, view
-frustum culling, and occlusion culling.
-</p>
-<p><a name="Figure_1"></a><img style="width: 500px; height: 341px;"
- alt="Directed Acyclic Graph" title="Directed Acyclic Graph"
- src="DAG.gif"></p>
-<p> </p>
-<ul>
- <font size="-1"><b><i>Figure 1</i> &#8211; A Java
-3D Scene Graph Is a DAG
-(Directed Acyclic Graph)</b></font>
-</ul>
-<p> </p>
-<h3>State Inheritance</h3>
-<p>A leaf node's state is defined by the nodes in a direct path between
-the scene graph's root and the leaf. Because a leaf's graphics context
-relies only on a linear path between the root and that node, the Java
-3D renderer can decide to traverse the scene graph in whatever order it
-wishes. It can traverse the scene graph from left to right and top to
-bottom, in level order from right to left, or even in parallel. The
-only exceptions to this rule are spatially bounded attributes such as
-lights and fog.
-</p>
-<p>This characteristic is in marked contrast to many older scene
-graph-based APIs (including PHIGS and SGI's Inventor) where, if a node
-above or to the left of a node changes the graphics state, the change
-affects the graphics state of all nodes below it or to its right. </p>
-<p>The most common node object, along the path from the root to the
-leaf,
-that changes the graphics state is the TransformGroup object. The
-TransformGroup object can change the position, orientation, and scale
-of the objects below it. </p>
-<p>Most graphics state attributes are set by a Shape3D leaf node
-through
-its constituent Appearance object, thus allowing parallel rendering.
-The Shape3D node also has a constituent Geometry object that specifies
-its geometry-this permits different shape objects to share common
-geometry without sharing material attributes (or vice versa). </p>
-<p> </p>
-<h3>Rendering</h3>
-<p>The Java 3D renderer incorporates all graphics state changes made in
-a
-direct path from a scene graph root to a leaf object in the drawing of
-that leaf object. Java 3D provides this semantic for both retained and
-compiled-retained modes.
-</p>
-<p> </p>
-<h2>Scene Graph Objects</h2>
-<p>A Java 3D scene graph consists of a collection of Java 3D node
-objects
-connected in a tree structure. These node objects reference other scene
-graph objects called <em>node component objects</em>.
-All scene graph node and component objects are subclasses of a common
-<a href="../SceneGraphObject.html">SceneGraphObject</a> class. The
-SceneGraphObject class is an abstract class
-that defines methods that are common among nodes and component objects.
-</p>
-<p>Scene graph objects are constructed by creating a new instance of
-the
-desired class and are accessed and manipulated using the object's <code>set</code>
-and <code>get</code>
-methods. Once a scene graph object is created and connected to other
-scene graph objects to form a subgraph, the entire subgraph can be
-attached to a virtual universe---via a high-resolution <a
- href="../Locale.html">Locale</a>
-object-making the object <em>live</em>. Prior to attaching a subgraph
-to a virtual
-universe, the entire subgraph can be <em>compiled</em> into an
-optimized, internal format (see the
-<code><a href="../BranchGroup.html#compile%28%29">BranchGroup.compile()</a></code>
-method). </p>
-<p>An important characteristic of all scene graph objects is that
-they can
-be accessed or modified only during the creation of a scene graph,
-except where explicitly allowed. Access to most <code>set</code> and <code>get</code>
-methods of objects that are part of a live or compiled scene graph is
-restricted. Such restrictions provide the scene graph compiler with
-usage information it can use in optimally compiling or rendering a
-scene graph. Each object has a set of capability bits that enable
-certain functionality when the object is live or compiled. By default,
-all capability bits are disabled (cleared). Only those <code>set</code>
-and <code>get</code>
-methods corresponding to capability bits that are explicitly enabled
-(set) prior to the object being compiled or made live are legal.<br>
-</p>
-<p> </p>
-<h2>Scene Graph Superstructure
-Objects</h2>
-Java 3D defines two scene graph superstructure objects,
-<a href="../VirtualUniverse.html">VirtualUniverse</a>
-and <a href="../Locale.html">Locale</a>, which are used to contain
-collections of subgraphs that
-comprise the scene graph. These objects are described in more detail in
-"<a href="VirtualUniverse.html">Scene Graph Superstructure</a>."
-<p> </p>
-<h3>VirtualUniverse Object</h3>
-A <a href="../VirtualUniverse.html">VirtualUniverse</a> object
-consists of a list of Locale objects that
-contain a collection of scene graph nodes that exist in the universe.
-Typically, an application will need only one VirtualUniverse, even for
-very large virtual databases. Operations on a VirtualUniverse include
-enumerating the Locale objects contained within the universe.
-<p> </p>
-<h3>Locale Object</h3>
-The <a href="../Locale.html">Locale</a> object acts as a container for
-a collection of subgraphs of
-the scene graph that are rooted by a BranchGroup node. A Locale also
-defines a location within the virtual universe using high-resolution
-coordinates (HiResCoord) to specify its position. The HiResCoord serves
-as the origin for all scene graph objects contained within the Locale.
-<p>A Locale has no parent in the scene graph but is implicitly
-attached to
-a virtual universe when it is constructed. A Locale may reference an
-arbitrary number of BranchGroup nodes but has no explicit children. </p>
-<p>The coordinates of all scene graph objects are relative to the
-HiResCoord of the Locale in which they are contained. Operations on a
-Locale include setting or getting the HiResCoord of the Locale, adding
-a subgraph, and removing a subgraph. </p>
-<p> </p>
-<h2>Scene Graph Viewing Objects</h2>
-Java 3D defines five scene graph viewing objects that are not part of
-the scene graph per se but serve to define the viewing parameters and
-to provide hooks into the physical world. These objects are <a
- href="../Canvas3D.html">Canvas3D</a>,
-<a href="../Screen3D.html">Screen3D</a>, <a href="../View.html">View</a>,
-<a href="../PhysicalBody.html">PhysicalBody</a>, and <a
- href="../PhysicalEnvironment.html">PhysicalEnvironment</a>. They are
-described in more detail in the "<a href="ViewModel.html">View Model</a>"
-document.<br>
-<p> </p>
-<h3>Canvas3D Object</h3>
-The <a href="../Canvas3D.html">Canvas3D</a> object encapsulates all of
-the parameters associated with
-the window being rendered into.
-When a Canvas3D object is attached to a View object, the Java 3D
-traverser renders the specified view onto the canvas. Multiple Canvas3D
-objects can point to the same View object.
-<p> </p>
-<h3>Screen3D Object</h3>
-The <a href="../Screen3D.html">Screen3D</a> object encapsulates all of
-the
-parameters associated with the physical screen containing the canvas,
-such as the width and height of the screen in pixels, the physical
-dimensions of the screen, and various physical calibration values.
-<p> </p>
-<h3>View Object</h3>
-The <a href="../View.html">View</a> object specifies information
-needed to render the scene graph.
-<a href="#Figure_2">Figure
-2</a> shows a View object attached to a simple scene graph for
-viewing the scene.
-<p>The View object is the central Java 3D object for coordinating all
-aspects of viewing.
-All viewing parameters in Java 3D are directly contained either within
-the View object or within objects pointed to by a View object. Java 3D
-supports multiple simultaneously active View objects, each of which can
-render to one or more canvases. </p>
-<p> </p>
-<h3>PhysicalBody Object</h3>
-The PhysicalBody object encapsulates all of the
-parameters associated with the physical body, such as head position,
-right and left eye position, and so forth.
-<p> </p>
-<h3>PhysicalEnvironment Object</h3>
-<p>The PhysicalEnvironment object encapsulates all of the parameters
-associated with the physical environment, such as calibration
-information for the tracker base for the head or hand tracker.<br>
-</p>
-<p><a name="Figure_2"></a><br>
-</p>
-<p><img style="width: 489px; height: 339px;" alt="Viewing a Scene Graph"
- title="Viewing a Scene Graph" src="ViewBranch.gif">
-</p>
-<p> </p>
-<ul>
- <font size="-1"><b><i>Figure 2</i> &#8211; Viewing a Scene Graph</b></font>
-</ul>
-</body>
-</html>
diff --git a/src/main/java/org/jogamp/java3d/doc-files/SceneGraphSharing.html b/src/main/java/org/jogamp/java3d/doc-files/SceneGraphSharing.html
deleted file mode 100644
index ff80cb4..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/SceneGraphSharing.html
+++ /dev/null
@@ -1,250 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
- <meta content="text/html; charset=ISO-8859-1"
- http-equiv="content-type">
- <title>Java 3D API - Reusing Scene Graphs</title>
-</head>
-<body>
-<h2>Reusing Scene Graphs</h2>
-<p>
-Java&nbsp;3D provides application programmers
-with two different means for reusing scene graphs. First, multiple
-scene graphs can share a common subgraph. Second, the node hierarchy of
-a common subgraph can be cloned, while still sharing large component
-objects such as geometry and texture objects. In the first case,
-changes in the shared subgraph affect all scene graphs that refer to
-the shared subgraph. In the second case, each instance is unique-a
-change in one instance does not affect any other instance.
-</p>
-<h2>Sharing Subgraphs</h2>
-<p>An application that wishes to share a subgraph from multiple places
-in
-a scene graph must do so through the use of the <a href="../Link.html">Link</a>
-leaf node and an
-associated <a href="../SharedGroup.html">SharedGroup</a> node. The
-SharedGroup node serves as the root of
-the shared subgraph. The Link leaf node refers to the SharedGroup node.
-It does not incorporate the shared scene graph directly into its scene
-graph.
-</p>
-<p>A SharedGroup node allows multiple Link leaf nodes to share its
-subgraph as shown in <a href="#Figure_1">Figure
-1</a> below.<br>
-</p>
-<p><a name="Figure_1"></a><img style="width: 500px; height: 476px;"
- alt="Sharing a Subgraph" title="Sharing a Subgraph"
- src="SceneGraphSharing1.gif">
-</p>
-<ul>
- <font size="-1"><b><i>Figure 1</i> &#8211; Sharing a Subgraph</b></font>
-</ul>
-<h2>Cloning Subgraphs</h2>
-<p>An application developer may wish to reuse a common subgraph without
-completely sharing that subgraph. For example, the developer may wish
-to create a parking lot scene consisting of multiple cars, each with a
-different color. The developer might define three basic types of cars,
-such as convertible, truck, and sedan. To create the parking lot scene,
-the application will instantiate each type of car several times. Then
-the application can change the color of the various instances to create
-more variety in the scene. Unlike shared subgraphs, each instance is a
-separate copy of the scene graph definition: Changes to one instance do
-not affect any other instance.
-</p>
-<p>Java&nbsp;3D provides the <a href="../Node.html#cloneTree%28%29"><code>cloneTree</code></a>
-method for this
-purpose. The <code>cloneTree</code>
-method allows the programmer to change some attributes (NodeComponent
-objects) in a scene graph, while at the same time sharing the majority
-of the scene graph data-the geometry.
-</p>
-<h3>References to Node Component
-Objects</h3>
-<p>When <code>cloneTree</code> reaches a leaf node,
-there are two possible actions for handling the leaf node's
-NodeComponent objects (such as Material, Texture, and so forth). First,
-the cloned leaf node can reference the original leaf node's
-NodeComponent object-the NodeComponent object itself is not duplicated.
-Since the cloned leaf node shares the NodeComponent object with the
-original leaf node, changing the data in the NodeComponent object will
-effect a change in both nodes. This mode would also be used for objects
-that are read-only at run time.
-</p>
-<p>Alternatively, the NodeComponent object can be duplicated, in which
-case the new leaf node would reference the duplicated object. This mode
-allows data referenced by the newly created leaf node to be modified
-without that modification affecting the original leaf node.
-</p>
-<p><a href="#Figure_2">Figure
-2</a>
-shows two instances of NodeComponent objects that are shared and one
-NodeComponent element that is duplicated for the cloned subgraph.
-</p>
-<p><a name="Figure_2"></a><img style="width: 499px; height: 287px;"
- alt="Referenced and Duplicated NodeComponent Objects"
- title="Referenced / Duplicated NodeComponens"
- src="SceneGraphSharing2.gif">
-</p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 2</i> &#8211; Referenced and Duplicated
-NodeComponent Objects</b></font>
-</ul>
-<h3>References to Other Scene
-Graph Nodes</h3>
-Leaf nodes that contain references to other nodes
-(for example, Light nodes reference a Group node) can create a problem
-for the <code>cloneTree</code> method. After the <code>cloneTree</code>
-operation is performed, the reference in the cloned leaf node will
-still refer to the node in the original subgraph-a situation that is
-most likely incorrect (see <a href="#Figure_3">Figure
-3</a>).
-<p>To handle these ambiguities, a callback mechanism is provided.
-</p>
-<p><a name="Figure_3"></a><img style="width: 499px; height: 240px;"
- alt="References to Other Scene Graph Nodes"
- title="References to Other Nodes" src="SceneGraphSharing3.gif">
-</p>
-<ul>
- <font size="-1"><b><i>Figure 3</i> &#8211; References to Other Scene Graph
-Nodes</b></font>
-</ul>
-<p>
-A leaf node that needs to update referenced nodes upon being duplicated
-by a call to <code>cloneTree</code> must implement the <code>updateNodeReferences</code>
-method. By using this method, the cloned leaf node can determine if any
-nodes referenced by it have been duplicated and, if so, update the
-appropriate references to their cloned counterparts.
-</p>
-<p>Suppose, for instance, that the leaf node Lf1 in <a href="#Figure_3">Figure
-3</a> implemented the <code>updateNodeReferences</code> method. Once
-all nodes had been duplicated, the <code>clone-Tree</code> method
-would then call each cloned leaf's node <code>updateNodeReferences</code>
-method. When cloned leaf node Lf2's method was called, Lf2 could ask if
-the node N1 had been duplicated during the <code>cloneTree</code>
-operation. If the node had been duplicated, leaf Lf2 could then update
-its internal state with the cloned node, N2 (see <a href="#Figure_4">Figure
-4</a>).
-</p>
-<p><a name="Figure_4"></a><img style="width: 499px; height: 190px;"
- alt="Updated Subgraph after updateNodeReferences Call"
- title="Subgraph after updateNodeReferences"
- src="SceneGraphSharing4.gif">
-</p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 4</i> &#8211; Updated Subgraph after
-updateNodeReferences Call</b></font>
-</ul>
-<p>
-All predefined Java&nbsp;3D nodes will automatically have their <code>updateNodeReferences</code>
-method defined. Only subclassed nodes that reference other nodes need
-to have this method overridden by the user.
-</p>
-<h3>Dangling References</h3>
-Because <code>cloneTree</code> is able to start
-the cloning operation from any node, there is a potential for creating
-dangling references. A dangling reference can occur only when a leaf
-node that contains a reference to another scene graph node is cloned.
-If the referenced node is not cloned, a dangling reference situation
-exists: There are now two leaf nodes that access the same node (<a
- href="#Figure_5">Figure
-5</a>). A dangling reference is discovered when a leaf node's <code>updateNodeReferences</code>
-method calls the <code>getNewNodeReference</code> method and the
-cloned subgraph does not contain a counterpart to the node being looked
-up.
-<p><a name="Figure_5"></a><img style="width: 499px; height: 232px;"
- alt="Dangling Reference" title="Dangling Reference"
- src="SceneGraphSharing5.gif"></p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 5</i> &#8211; Dangling Reference: Bold Nodes
-Are Being Cloned</b></font>
-</ul>
-<p>
-When a dangling reference is discovered, <code>cloneTree</code> can
-handle it in one of two ways. If <code>cloneTree</code> is called
-without the <code>allowDanglingReferences</code> parameter set to <code>true</code>,
-a dangling reference will result in a <code>DanglingReferenceException</code>
-being thrown. The user can catch this exception if desired. If <code>cloneTree</code>
-is called with the <code>allowDanglingReferences</code> parameter set
-to <code>true</code>, the <code>update-NodeReferences</code> method
-will return a reference to the same object passed into the <code>getNewNodeReference</code>
-method. This will result in the <code>cloneTree</code> operation
-completing with dangling references, as in <a href="#Figure_5">Figure
-5</a>.
-</p>
-<h3>Subclassing Nodes</h3>
-All Java&nbsp;3D predefined nodes (for example, Interpolators and LOD
-nodes)
-automatically handle all node reference and duplication operations.
-When a user subclasses a Leaf object or a NodeComponent object, certain
-methods must be provided in order to ensure the proper operation of <code>cloneTree</code>.
-<p>Leaf node subclasses (for example, Behaviors) that contain any user
-node-specific data that needs to be duplicated during a <code>cloneTree</code>
-operation must define the following two methods:
-</p>
-<pre><b>Node cloneNode(boolean forceDuplicate);<br>void duplicateNode(Node n, boolean forceDuplicate)<br></b></pre>
-The <code>cloneNode</code> method consists of three lines:
-<pre><hr><br><code>UserSubClass usc = new UserSubClass();<br>usc.duplicateNode(this, forceDuplicate);</code><br>return usc;<br><br><hr></pre>
-The <code>duplicateNode</code> method must first call <code>super.duplicateNode</code>
-before duplicating any necessary user-specific data or setting any
-user-specific state.
-<p>NodeComponent subclasses that contain any user node-specific data
-must define the following two methods:
-</p>
-<pre><b>NodeComponent cloneNodeComponent();<br>void duplicateNodeComponent(NodeComponent nc, boolean forceDuplicate);<br></b></pre>
-The <code>cloneNodeComponent</code> method consists of three lines:
-<pre><hr><br><code>UserNodeComponent unc = new UserNodeComponent();<br>unc.duplicateNodeComponent(this, forceDuplicate);</code><br>return un;<br><br><hr></pre>
-The <code>duplicateNodeComponent</code> must first call <code>super.duplicateNodeComponent</code>
-and then can duplicate any user-specific data or set any user-specific
-state as necessary.
-<h3>NodeReferenceTable Object</h3>
-The NodeReferenceTable object is used by a leaf node's <code>updateNodeReferences</code>
-method called by the <code>cloneTree</code>
-operation. The NodeReferenceTable maps nodes from the original subgraph
-to the new nodes in the cloned subgraph. This information can than be
-used to update any cloned leaf node references to reference nodes in
-the cloned subgraph. This object can be created only by Java&nbsp;3D.
-<h3>Example: User Behavior Node</h3>
-The following is an example of a user-defined Behavior object to show
-properly how to define a node to be compatible with the <code>cloneTree</code>
-operation.
-<hr>
-<pre>class RotationBehavior extends Behavior {<br> TransformGroup objectTransform;<br> WakeupOnElapsedFrames w;<br></pre>
-<pre> Matrix4d rotMat = new Matrix4d();<br> Matrix4d objectMat = new Matrix4d();<br> Transform3D t = new Transform3D();<br></pre>
-<pre><i> // Override Behavior's initialize method to set up wakeup<br> // criteria<br></i></pre>
-<pre> public void initialize() {<br></pre>
-<pre><i> // Establish initial wakeup criteria<br></i></pre>
-<pre> wakeupOn(w);<br> }<br></pre>
-<pre><i> // Override Behavior's stimulus method to handle the event<br></i></pre>
-<pre> public void processStimulus(Enumeration criteria) {<br></pre>
-<pre><i> // Rotate by another PI/120.0 radians<br></i></pre>
-<pre> objectMat.mul(objectMat, rotMat);<br> t.set(objectMat);<br> objectTransform.setTransform(t);<br></pre>
-<pre><i> // Set wakeup criteria for next time<br></i></pre>
-<pre> wakeupOn(w);<br> }<br></pre>
-<pre><i> // Constructor for rotation behavior.<br></i></pre>
-<pre> public RotationBehavior(TransformGroup tg, int numFrames) {<br> w = new WakeupOnElapsedFrames(numFrames);<br> objectTransform = tg;<br></pre>
-<pre><i> objectMat.setIdentity();<br></i></pre>
-<pre><i> // Create a rotation matrix that rotates PI/120.0<br> // radians per frame<br> rotMat.rotX(Math.PI/120.0);<br></i></pre>
-<pre><i> // Note: When this object is duplicated via cloneTree,<br> // the cloned RotationBehavior node needs to point to<br> // the TransformGroup in the just-cloned tree. <br> }<br></i></pre>
-<pre><i> // Sets a new TransformGroup.<br></i></pre>
-<pre> public void setTransformGroup(TransformGroup tg) {<br> objectTransform = tg;<br></pre>
-<pre><i> }<br></i></pre>
-<pre><i> // The next two methods are needed for cloneTree to operate<br> // correctly.<br> // cloneNode is needed to provide a new instance of the user<br> // derived subclass.<br></i></pre>
-<pre> public Node cloneNode(boolean forceDuplicate) {<br></pre>
-<pre><i> // Get all data from current node needed for<br> // the constructor<br> int numFrames = w.getElapsedFrameCount();<br></i></pre>
-<pre> RotationBehavior r =<br> new RotationBehavior(objectTransform, numFrames);<br> r.duplicateNode(this, forceDuplicate);<br> return r;<br> }<br></pre>
-<pre><i> // duplicateNode is needed to duplicate all super class<br> // data as well as all user data.<br></i></pre>
-<pre> public void duplicateNode(Node originalNode, boolean <br> forceDuplicate) {<br> super.duplicateNode(originalNode, forceDuplicate);<br></pre>
-<pre><i> // Nothing to do here - all unique data was handled<br> // in the constructor in the cloneNode routine.<br> }<br></i></pre>
-<pre><i> // Callback for when this leaf is cloned. For this object<br> // we want to find the cloned TransformGroup node that this<br> // clone Leaf node should reference.<br></i></pre>
-<pre> public void updateNodeReferences(NodeReferenceTable t) {<br></pre>
-<pre><i> super.updateNodeReferences(t);<br></i></pre>
-<pre><i> // Update node's TransformGroup to proper reference<br></i></pre>
-<pre> TransformGroup newTg =<br> (TransformGroup)t.getNewObjectReference(<br> objectTransform);<br> setTransformGroup(newTg);<br> }<br>}<br></pre>
-</body>
-</html>
diff --git a/src/main/java/org/jogamp/java3d/doc-files/SceneGraphSharing1.gif b/src/main/java/org/jogamp/java3d/doc-files/SceneGraphSharing1.gif
deleted file mode 100644
index f6ca47c..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/SceneGraphSharing1.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/SceneGraphSharing2.gif b/src/main/java/org/jogamp/java3d/doc-files/SceneGraphSharing2.gif
deleted file mode 100644
index c062c81..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/SceneGraphSharing2.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/SceneGraphSharing3.gif b/src/main/java/org/jogamp/java3d/doc-files/SceneGraphSharing3.gif
deleted file mode 100644
index 325cab1..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/SceneGraphSharing3.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/SceneGraphSharing4.gif b/src/main/java/org/jogamp/java3d/doc-files/SceneGraphSharing4.gif
deleted file mode 100644
index 78aeaab..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/SceneGraphSharing4.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/SceneGraphSharing5.gif b/src/main/java/org/jogamp/java3d/doc-files/SceneGraphSharing5.gif
deleted file mode 100644
index 2ff6547..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/SceneGraphSharing5.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/ViewBranch.gif b/src/main/java/org/jogamp/java3d/doc-files/ViewBranch.gif
deleted file mode 100644
index 75cc40d..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/ViewBranch.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/ViewModel.html b/src/main/java/org/jogamp/java3d/doc-files/ViewModel.html
deleted file mode 100644
index 3cc9ece..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/ViewModel.html
+++ /dev/null
@@ -1,1064 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
- <meta content="text/html; charset=ISO-8859-1"
- http-equiv="content-type">
- <title>Java 3D API - View Model</title>
-</head>
-<body>
-<h2>View Model</h2>
-<p>Java&nbsp;3D introduces a new view model that takes Java's
-vision of "write once, run anywhere" and generalizes it to include
-display devices and six-degrees-of-freedom input peripherals such as
-head trackers. This "write once, view everywhere" nature of the new
-view model means that an application or applet written using the Java
-3D view model can render images to a broad range of display devices,
-including standard computer displays, multiple-projection display
-rooms, and head-mounted displays, without modification of the scene
-graph. It also means that the same application, once again without
-modification, can render stereoscopic views and can take advantage of
-the input from a head tracker to control the rendered view.
-</p>
-<p>Java&nbsp;3D's view model achieves this versatility by cleanly
-separating
-the virtual and the physical world. This model distinguishes between
-how an application positions, orients, and scales a ViewPlatform object
-(a viewpoint) within the virtual world and how the Java&nbsp;3D
-renderer
-constructs the final view from that viewpoint's position and
-orientation. The application controls the ViewPlatform's position and
-orientation; the renderer computes what view to render using this
-position and orientation, a description of the end-user's physical
-environment, and the user's position and orientation within the
-physical environment.
-</p>
-<p>This document first explains why Java&nbsp;3D chose a different view
-model
-and some of the philosophy behind that choice. It next describes how
-that model operates in the simple case of a standard computer screen
-without head tracking&#8212;the most common case. Finally, it presents
-advanced material that was originally published in Appendix C of the
-API specification guide.
-</p>
-<p>
-</p>
-<h2>Why a New Model?</h2>
-<p>Camera-based view models, as found in low-level APIs, give
-developers
-control over all rendering parameters. This makes sense when dealing
-with custom applications, less sense when dealing with systems that
-wish to have broader applicability: systems such as viewers or browsers
-that load and display whole worlds as a single unit or systems where
-the end users view, navigate, display, and even interact with the
-virtual world.
-</p>
-<p>Camera-based view models emulate a camera in the virtual world, not
-a
-human in a virtual world. Developers must continuously reposition a
-camera to emulate "a human in the virtual world."
-</p>
-<p>The Java&nbsp;3D view model incorporates head tracking directly, if
-present,
-with no additional effort from the developer, thus providing end users
-with the illusion that they actually exist inside a virtual world.
-</p>
-<p>The Java&nbsp;3D view model, when operating in a non-head-tracked
-environment and rendering to a single, standard display, acts very much
-like a traditional camera-based view model, with the added
-functionality of being able to generate stereo views transparently.
-</p>
-<p>
-</p>
-<h3>The Physical Environment
-Influences the View</h3>
-<p>Letting the application control all viewing parameters is not
-reasonable in systems in which the physical environment dictates some
-of the view parameters.
-</p>
-<p>One example of this is a head-mounted display (HMD), where the
-optics
-of the head-mounted display directly determine the field of view that
-the application should use. Different HMDs have different optics,
-making it unreasonable for application developers to hard-wire such
-parameters or to allow end users to vary that parameter at will.
-</p>
-<p>Another example is a system that automatically computes view
-parameters
-as a function of the user's current head position. The specification of
-a world and a predefined flight path through that world may not exactly
-specify an end-user's view. HMD users would expect to look and thus see
-to their left or right even when following a fixed path through the
-environment-imagine an amusement park ride with vehicles that follow
-fixed paths to present content to their visitors, but visitors can
-continue to move their heads while on those rides.
-</p>
-<p>Depending on the physical details of the end-user's environment, the
-values of the viewing parameters, particularly the viewing and
-projection matrices, will vary widely. The factors that influence the
-viewing and projection matrices include the size of the physical
-display, how the display is mounted (on the user's head or on a table),
-whether the computer knows the user's head location in three space, the
-head mount's actual field of view, the display's pixels per inch, and
-other such parameters. For more information, see "<a
- href="#View_Model_Details">View Model Details</a>."
-</p>
-<p>
-</p>
-<h2>Separation of Physical and
-Virtual</h2>
-<p>The Java&nbsp;3D view model separates the virtual environment, where
-the
-application programmer has placed objects in relation to one another,
-from the physical environment, where the user exists, sees computer
-displays, and manipulates input devices.
-</p>
-<p>Java&nbsp;3D also defines a fundamental correspondence between the
-user's
-physical world and the virtual world of the graphic application. This
-physical-to-virtual-world correspondence defines a single common space,
-a space where an action taken by an end user affects objects within the
-virtual world and where any activity by objects in the virtual world
-affects the end user's view.
-</p>
-<p>
-</p>
-<h3>The Virtual World</h3>
-<p>The virtual world is a common space in which virtual objects exist.
-The
-virtual world coordinate system exists relative to a high-resolution
-Locale-each Locale object defines the origin of virtual world
-coordinates for all of the objects attached to that Locale. The Locale
-that contains the currently active ViewPlatform object defines the
-virtual world coordinates that are used for rendering. Java3D
-eventually transforms all coordinates associated with scene graph
-elements into this common virtual world space.
-</p>
-<h3>The Physical World</h3>
-<p>The physical world is just that-the real, physical world. This is
-the
-space in which the physical user exists and within which he or she
-moves his or her head and hands. This is the space in which any
-physical trackers define their local coordinates and in which several
-calibration coordinate systems are described.
-</p>
-<p>The physical world is a space, not a common coordinate system
-between
-different execution instances of Java&nbsp;3D. So while two different
-computers at two different physical locations on the globe may be
-running at the same time, there is no mechanism directly within
-Java&nbsp;3D
-to relate their local physical world coordinate systems with each
-other. Because of calibration issues, the local tracker (if any)
-defines the local physical world coordinate system known to a
-particular instance of Java&nbsp;3D.
-</p>
-<p>
-</p>
-<h2>The Objects That Define the
-View</h2>
-<p>Java&nbsp;3D distributes its view model parameters across several
-objects,
-specifically, the View object and its associated component objects, the
-PhysicalBody object, the PhysicalEnvironment object, the Canvas3D
-object, and the Screen3D object. <a href="#Figure_1">Figure
-1</a> shows graphically the central role of the View object and the
-subsidiary role of its component objects.
-</p>
-<p><a name="Figure_1"></a><img style="width: 500px; height: 355px;"
- alt="View Object + Other Components"
- title="View Object + Other Components" src="ViewModel1.gif"></p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 1</i> &#8211; View Object, Its Component
-Objects, and Their
-Interconnection</b></font>
-</ul>
-<p>
-The view-related objects shown in <a href="#Figure_1">Figure
-1</a>
-and their roles are as follows. For each of these objects, the portion
-of the API that relates to modifying the virtual world and the portion
-of the API that is relevant to non-head-tracked standard display
-configurations are derived in this chapter. The remainder of the
-details are described in "<a href="#View_Model_Details">View Model
-Details</a>."
-</p>
-<ul>
- <li><a href="../ViewPlatform.html"><em>ViewPlatform</em></a>: A leaf
-node that locates a view within a
-scene graph. The ViewPlatform's parents specify its location,
-orientation, and scale within the virtual universe. See "<a
- href="#ViewPlatform_Place">ViewPlatform: A Place in the Virtual World</a>,"
-for more
-information. </li>
-</ul>
-<ul>
- <li><a href="../View.html"><em>View</em></a>: The main view object.
-It contains many pieces of
-view state.</li>
-</ul>
-<ul>
- <li><a href="../Canvas3D.html"><em>Canvas3D</em></a>: The 3D version
-of the Abstract Windowing
-Toolkit
-(AWT) Canvas object. It represents a window in which Java&nbsp;3D will
-draw
-images. It contains a reference to a Screen3D object and information
-describing the Canvas3D's size, shape, and location within the Screen3D
-object.</li>
-</ul>
-<ul>
- <li><a href="../Screen3D.html"><em>Screen3D</em></a>: An object that
-contains information describing
-the display screen's physical properties. Java&nbsp;3D places
-display-screen
-information in a separate object to prevent the duplication of screen
-information within every Canvas3D object that shares a common screen.</li>
-</ul>
-<ul>
- <li><a href="../PhysicalBody.html">PhysicalBody</a>: An object that
-contains calibration information
-describing the user's physical body.</li>
-</ul>
-<ul>
- <li><a href="../PhysicalEnvironment.html">PhysicalEnvironment</a>: An
-object that contains calibration
-information describing the physical world, mainly information that
-describes the environment's six-degrees-of freedom tracking hardware,
-if present.</li>
-</ul>
-<p>Together, these objects describe the geometry of viewing rather than
-explicitly providing a viewing or projection matrix. The Java&nbsp;3D
-renderer uses this information to construct the appropriate viewing and
-projection matrices. The geometric focus of these view objects provides
-more flexibility in generating views-a flexibility needed to support
-alternative display configurations.
-</p>
-<h2><a name="ViewPlatform_Place"></a>ViewPlatform: A Place in the
-Virtual World</h2>
-<p>A ViewPlatform leaf node defines a coordinate system, and thus a
-reference frame with its associated origin or reference point, within
-the virtual world. The ViewPlatform serves as a point of attachment for
-View objects and as a base for determining a renderer's view.
-</p>
-<p><a href="#Figure_2">Figure
-2</a>
-shows a portion of a scene graph containing a ViewPlatform node. The
-nodes directly above a ViewPlatform determine where that ViewPlatform
-is located and how it is oriented within the virtual world. By
-modifying the Transform3D object associated with a TransformGroup node
-anywhere directly above a ViewPlatform, an application or behavior can
-move that ViewPlatform anywhere within the virtual world. A simple
-application might define one TransformGroup node directly above a
-ViewPlatform, as shown in <a href="#Figure_2">Figure
-2</a>.
-</p>
-<p>A VirtualUniverse may have many different ViewPlatforms, but a
-particular View object can attach itself only to a single ViewPlatform.
-Thus, each rendering onto a Canvas3D is done from the point of view of
-a single ViewPlatform.
-</p>
-<p><a name="Figure_2"></a><img style="width: 500px; height: 359px;"
- alt="View Platform Branch Graph" title="View Platform Branch Graph"
- src="ViewModel2.gif">
-</p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 2</i> &#8211; A Portion of a Scene Graph
-Containing a ViewPlatform Object</b></font>
-</ul>
-<p>
-</p>
-<h3>Moving through the Virtual
-World</h3>
-<p>An application navigates within the virtual world by modifying a
-ViewPlatform's parent TransformGroup. Examples of applications that
-modify a ViewPlatform's location and orientation include browsers,
-object viewers that provide navigational controls, applications that do
-architectural walkthroughs, and even search-and-destroy games.
-</p>
-<p>Controlling the ViewPlatform object can produce very interesting and
-useful results. Our first simple scene graph (see <a
- href="intro.html#Figure_1">"Introduction," Figure 1</a>)
-defines a scene graph for a simple application that draws an object in
-the center of a window and rotates that object about its center point.
-In that figure, the Behavior object modifies the TransformGroup
-directly above the Shape3D node.
-</p>
-<p>An alternative application scene graph, shown in <a href="#Figure_3">Figure
-3</a>,
-leaves the central object alone and moves the ViewPlatform around the
-world. If the shape node contains a model of the earth, this
-application could generate a view similar to that seen by astronauts as
-they orbit the earth.
-</p>
-<p>Had we populated this world with more objects, this scene graph
-would allow navigation through the world via the Behavior node.
-</p>
-<p><a name="Figure_3"></a><img style="width: 500px; height: 289px;"
- alt="Simple Scene Graph with View Control"
- title="Simple Scene Graph with View Control" src="ViewModel3.gif">
-</p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 3</i> &#8211; A Simple Scene Graph with View
-Control</b></font>
-</ul>
-<p>
-Applications and behaviors manipulate a <a
- href="../TransformGroup.html">TransformGroup</a> through its
-access methods. These methods allow an application to retrieve and
-set the Group node's Transform3D object. Transform3D Node methods
-include <code>getTransform</code> and <code>setTransform</code>.
-</p>
-<p>
-</p>
-<h3>Dropping in on a Favorite
-Place</h3>
-<p>A scene graph may contain multiple <a href="../ViewPlatform.html">ViewPlatform</a>
-objects. If a user detaches a <a href="../View.html">View</a> object
-from a ViewPlatform and then
-reattaches that View to a different ViewPlatform, the image on the
-display will now be rendered from the point of view of the new
-ViewPlatform.</p>
-<h3>Associating Geometry with a
-ViewPlatform</h3>
-<p>Java&nbsp;3D does not have any built-in semantics for displaying a
-visible
-manifestation of a ViewPlatform within the virtual world (an <em>avatar</em>).
-However, a developer can construct and manipulate an avatar using
-standard Java&nbsp;3D constructs.
-</p>
-<p>A developer can construct a small scene graph consisting of a
-TransformGroup node, a behavior leaf node, and a shape node and insert
-it directly under the BranchGroup node associated with the ViewPlatform
-object. The shape node would contain a geometric model of the avatar's
-head. The behavior node would change the TransformGroup's transform
-periodically to the value stored in a View object's <code>UserHeadToVworld</code><strong>
-</strong>parameter (see "<a href="#View_Model_Details">View Model
-Details</a>").
-The avatar's virtual head, represented by the shape node, will now move
-around in lock-step with the ViewPlatform's TransformGroup<em> and </em>any
-relative position and orientation changes of the user's actual physical
-head (if a system has a head tracker).
-</p>
-<p>
-</p>
-<h2><a name="Generating_View"></a>Generating a View</h2>
-<p>Java&nbsp;3D generates viewing matrices in one of a few different
-ways,
-depending on whether the end user has a head-mounted or a room-mounted
-display environment and whether head tracking is enabled. This section
-describes the computation for a non-head-tracked, room-mounted
-display-a standard computer display. Other environments are described
-in "<a href="#View_Model_Details">View Model Details</a>."
-</p>
-<p>In the absence of head tracking, the ViewPlatform's origin specifies
-the virtual eye's location and orientation within the virtual world.
-However, the eye location provides only part of the information needed
-to render an image. The renderer also needs a projection matrix. In the
-default mode, Java&nbsp;3D uses the projection policy, the specified
-field-of-view information, and the front and back clipping distances to
-construct a viewing frustum.
-</p>
-<p>
-</p>
-<h3>Composing Model and Viewing
-Transformations</h3>
-<p><a href="#Figure_4">Figure
-4</a>
-shows a simple scene graph. To draw the object labeled "S,"
-Java&nbsp;3D
-internally constructs the appropriate model, view platform, eye, and
-projection matrices. Conceptually, the model transformation for a
-particular object is computed by concatenating all the matrices in a
-direct path between the object and the VirtualUniverse. The view matrix
-is then computed-again, conceptually-by concatenating all the matrices
-between the VirtualUniverse object and the ViewPlatform attached to the
-current View object. The eye and projection matrices are constructed
-from the View object and its associated component objects.
-</p>
-<p><a name="Figure_4"></a><img style="width: 500px; height: 332px;"
- alt="Object and ViewPlatform Transform"
- title="Object and ViewPlatform Transform" src="ViewModel4.gif"></p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 4</i> &#8211; Object and ViewPlatform
-Transformations</b></font>
-</ul>
-<p>In our scene graph, what we would normally consider the
-model transformation would consist of the following three
-transformations: <strong>LT</strong>1<strong>T</strong>2. By
-multiplying <strong>LT</strong>1<strong>T</strong>2
-by a vertex in the shape object, we would transform that vertex into
-the virtual universe's coordinate system. What we would normally
-consider the view platform transformation would be (<strong>LT</strong>v1)-1
-or <strong>T</strong>v1<sup>-1</sup><strong>L</strong>-1.
-This presents a problem since coordinates in the virtual universe are
-256-bit fixed-point values, which cannot be used to represent
-transformed points efficiently.
-</p>
-<p>Fortunately, however, there is a solution to this problem. Composing
-the model and view platform transformations gives us
-</p>
-<dl>
- <dt><br>
- </dt>
- <dd> <strong>T</strong>v1<sup>-1</sup><strong>L</strong>-1<strong>LT</strong>1<strong>T</strong>2
-= <strong>T</strong>v1<sup>-1</sup><strong>IT</strong>1<strong>T</strong>2
-= <strong>T</strong>v1<sup>-1</sup><strong>T</strong>1<strong>T</strong>2,
- </dd>
-</dl>
-<p>the matrix that takes vertices in an object's local coordinate
-system
-and places them in the ViewPlatform's coordinate system. Note that the
-high-resolution Locale transformations cancel each other out, which
-removes the need to actually transform points into high-resolution
-VirtualUniverse coordinates. The general formula of the matrix that
-transforms object coordinates to ViewPlatform coordinates is <strong>T</strong>vn<sup>-1</sup>...<strong>T</strong>v2<sup>-1</sup><strong>T</strong>v1<sup>-1</sup><strong>T</strong>1<strong>T</strong>2...<strong>T</strong>m.
-</p>
-<p>As mentioned earlier, the View object contains the remainder of the
-view information, specifically, the eye matrix, <strong>E</strong>,
-that takes points in the View-Platform's local coordinate system and
-translates them into the user's eye coordinate system, and the
-projection matrix, <strong>P</strong>, that projects objects in the
-eye's coordinate system into clipping coordinates. The final
-concatenation of matrices for rendering our shape object "S" on the
-specified Canvas3D is <strong>PET</strong>v1<sup>-1</sup><strong>T</strong>1<strong>T</strong>2.
-In general this is <strong>PET</strong>vn<sup>-1</sup>...<strong>T</strong>v2<sup>-1</sup><strong>T</strong>v1<sup>-1</sup><strong>T</strong>1<strong>T</strong>2...<strong>T</strong>m.
-</p>
-<p>The details of how Java&nbsp;3D constructs the matrices <strong>E</strong>
-and <strong>P</strong> in different end-user configurations are
-described in "<a href="#View_Model_Details">View Model Details</a>."
-</p>
-<p>
-</p>
-<h3>Multiple Locales</h3>
-<p>Java&nbsp;3D supports multiple high-resolution Locales. In some
-cases,
-these
-Locales are close enough to each other that they can "see" each other,
-meaning that objects can be rendered even though they are not in the
-same Locale as the ViewPlatform object that is attached to the View.
-Java&nbsp;3D automatically handles this case without the application
-having
-to do anything. As in the previous example, where the ViewPlatform and
-the object being rendered are attached to the same Locale, Java&nbsp;3D
-internally constructs the appropriate matrices for cases in which the
-ViewPlatform and the object being rendered are <em>not</em> attached
-to the same Locale.
-</p>
-<p>Let's take two Locales, L1 and L2, with the View attached to a
-ViewPlatform in L1. According to our general formula, the modeling
-transformation-the transformation that takes points in object
-coordinates and transforms them into VirtualUniverse coordinates-is <strong>LT</strong>1<strong>T</strong>2...<strong>T</strong>m.
-In our specific example, a point in Locale L2 would be transformed into
-VirtualUniverse coordinates by <strong>L</strong>2<strong>T</strong>1<strong>T</strong>2...<strong>T</strong>m.
-The view platform transformation would be (<strong>L</strong>1<strong>T</strong>v1<strong>T</strong>v1...<strong>T</strong>vn)-1
-or <strong>T</strong>vn<sup>-1</sup>...<strong>T</strong>v2<sup>-1</sup><strong>T</strong>v1<sup>-1</sup><strong>L</strong>1<sup>-1</sup>.
-Composing these two matrices gives us
-</p>
-<dl>
- <dt><br>
- </dt>
- <dd> <strong>T</strong>vn<sup>-1</sup>...<strong>T</strong>v2<sup>-1</sup><strong>T</strong>v1<sup>-1</sup><strong>L</strong>1<sup>-1</sup><strong>L</strong>2<strong>T</strong>1<strong>T</strong>2...<strong>T</strong>m.
- </dd>
-</dl>
-<p>Thus, to render objects in another Locale, it is sufficient to
-compute <strong>L</strong>1<sup>-1</sup><strong>L</strong>2
-and use that as the starting matrix when composing the model
-transformations. Given that a Locale is represented by a single
-high-resolution coordinate position, the transformation <strong>L</strong>1<sup>-1</sup><strong>L</strong>2
-is a simple translation by <strong>L</strong>2 - <strong>L</strong>1.
-Again, it is not actually necessary to transform points into
-high-resolution VirtualUniverse coordinates.
-</p>
-<p>In general, Locales that are close enough that the difference in
-their
-high-resolution coordinates can be represented in double precision by a
-noninfinite value are close enough to be rendered. In practice, more
-sophisticated culling techniques can be used to render only those
-Locales that really are "close enough."
-</p>
-<p>
-</p>
-<h2>A Minimal Environment</h2>
-<p>An application must create a minimal set of Java&nbsp;3D objects
-before
-Java
-3D can render to a display device. In addition to a Canvas3D object,
-the application must create a View object, with its associated
-PhysicalBody and PhysicalEnvironment objects, and the following scene
-graph elements:
-</p>
-<ul>
- <li>A VirtualUniverse object</li>
-</ul>
-<ul>
- <li>A high-resolution Locale object</li>
-</ul>
-<ul>
- <li>A BranchGroup node object</li>
-</ul>
-<ul>
- <li>A TransformGroup node object with associated transform</li>
-</ul>
-<ul>
- <li>A ViewPlatform leaf node object that defines the position and
-orientation within the virtual universe for generating views</li>
-</ul>
-<hr>
-<h2><a name="View_Model_Details"></a>View Model Details</h2>
-<p>An application programmer writing a 3D
-graphics program that will deploy on a variety of platforms must
-anticipate the likely end-user environments and must carefully
-construct the view transformations to match those characteristics using
-a low-level API. This appendix addresses many of the issues an
-application must face and describes the sophisticated features that
-Java&nbsp;3D's advanced view model provides.
-</p>
-<p>
-</p>
-<h2>An Overview of the
-Java&nbsp;3D
-View Model</h2>
-Both camera-based and Java&nbsp;3D-based view models allow a programmer
-to
-specify the shape of a view frustum and, under program control, to
-place, move, and reorient that frustum within the virtual environment.
-However, how they do this varies enormously. Unlike the camera-based
-system, the Java&nbsp;3D view model allows slaving the view frustum's
-position and orientation to that of a six-degrees-of-freedom tracking
-device. By slaving the frustum to the tracker, Java&nbsp;3D can
-automatically modify the view frustum so that the generated images
-match the end-user's viewpoint exactly.
-<p>Java&nbsp;3D must handle two rather different head-tracking
-situations.
-In one case, we rigidly attach a tracker's <em>base</em>,
-and thus its coordinate frame, to the display environment. This
-corresponds to placing a tracker base in a fixed position and
-orientation relative to a projection screen within a room, to a
-computer display on a desk, or to the walls of a multiple-wall
-projection display. In the second head-tracking situation, we rigidly
-attach a tracker's <em>sensor</em>, not its base, to the display
-device. This corresponds to rigidly attaching one of that tracker's
-sensors to a head-mounted display and placing the tracker base
-somewhere within the physical environment.
-</p>
-<p>
-</p>
-<h2>Physical Environments and
-Their Effects</h2>
-Imagine an application where the end user sits on a magic carpet. The
-application flies the user through the virtual environment by
-controlling the carpet's location and orientation within the virtual
-world. At first glance, it might seem that the application also
-controls what the end user will see-and it does, but only
-superficially.
-<p>The following two examples show how end-user environments can
-significantly affect how an application must construct viewing
-transformations.
-</p>
-<p>
-</p>
-<h3>A Head-Mounted Example</h3>
-Imagine that the end user sees the magic carpet and the virtual world
-with a head-mounted display and head tracker. As the application flies
-the carpet through the virtual world, the user may turn to look to the
-left, to the right, or even toward the rear of the carpet. Because the
-head tracker keeps the renderer informed of the user's gaze direction,
-it might not need to draw the scene directly in front of the magic
-carpet. The view that the renderer draws on the head-mount's display
-must match what the end user would see if the experience had occurred
-in the real world.
-<h3>A Room-Mounted Example</h3>
-Imagine a slightly different scenario where the end user sits in a
-darkened room in front of a large projection screen. The application
-still controls the carpet's flight path; however, the position and
-orientation of the user's head barely influences the image drawn on the
-projection screen. If a user looks left or right, then he or she sees
-only the darkened room. The screen does not move. It's as if the screen
-represents the magic carpet's "front window" and the darkened room
-represents the "dark interior" of the carpet.
-<p>By adding a left and right screen, we give the magic carpet rider a
-more complete view of the virtual world surrounding the carpet. Now our
-end user sees the view to the left or right of the magic carpet by
-turning left or right.
-</p>
-<p>
-</p>
-<h3>Impact of Head Position and
-Orientation on the Camera</h3>
-In the head-mounted example, the user's head position and orientation
-significantly affects a camera model's camera position and orientation
-but hardly has any effect on the projection matrix. In the room-mounted
-example, the user's head position and orientation contributes little to
-a camera model's camera position and orientation; however, it does
-affect the projection matrix.
-<p>From a camera-based perspective, the application developer must
-construct the camera's position and orientation by combining the
-virtual-world component (the position and orientation of the magic
-carpet) and the physical-world component (the user's instantaneous head
-position and orientation).
-</p>
-<p>Java&nbsp;3D's view model incorporates the appropriate abstractions
-to
-compensate automatically for such variability in end-user hardware
-environments.
-</p>
-<p>
-</p>
-<h2>The Coordinate Systems</h2>
-The basic view model consists of eight or nine coordinate systems,
-depending on whether the end-user environment consists of a
-room-mounted display or a head-mounted display. First, we define the
-coordinate systems used in a room-mounted display environment. Next, we
-define the added coordinate system introduced when using a head-mounted
-display system.
-<h3>Room-Mounted Coordinate
-Systems</h3>
-The room-mounted coordinate system is divided into the virtual
-coordinate system and the physical coordinate system. <a
- href="#Figure_5">Figure
-5</a>
-shows these coordinate systems graphically. The coordinate systems
-within the grayed area exist in the virtual world; those outside exist
-in the physical world. Note that the coexistence coordinate system
-exists in both worlds.
-<h4>The Virtual Coordinate
-Systems</h4>
-<h5> The Virtual World Coordinate System</h5>
-The virtual world coordinate system encapsulates
-the unified coordinate system for all scene graph objects in the
-virtual environment. For a given View, the virtual world coordinate
-system is defined by the Locale object that contains the ViewPlatform
-object attached to the View. It is a right-handed coordinate system
-with +<em>x</em> to the right, +<em>y</em> up, and +<em>z</em> toward
-the viewer.
-<h5> The ViewPlatform Coordinate System</h5>
-The ViewPlatform coordinate system is the local coordinate system of
-the ViewPlatform leaf node to which the View is attached.
-<p><a name="Figure_5"></a><img style="width: 500px; height: 181px;"
- alt="Display Rigidly Attached to Tracker Base"
- title="Display Rigidly Attached to Tracker Base" src="ViewModel5.gif"></p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 5</i> &#8211; Display Rigidly Attached to the
-Tracker Base</b></font>
-</ul>
-<p>
-</p>
-<h5> The Coexistence Coordinate System</h5>
-A primary implicit goal of any view model is to map a specified local
-portion of the physical world onto a specified portion of the virtual
-world. Once established, one can legitimately ask where the user's head
-or hand is located within the virtual world or where a virtual object
-is located in the local physical world. In this way the physical user
-can interact with objects inhabiting the virtual world, and vice versa.
-To establish this mapping, Java&nbsp;3D defines a special coordinate
-system,
-called coexistence coordinates, that is defined to exist in both the
-physical world and the virtual world.
-<p>The coexistence coordinate system exists half in the virtual world
-and
-half in the physical world. The two transforms that go from the
-coexistence coordinate system to the virtual world coordinate system
-and back again contain all the information needed to expand or shrink
-the virtual world relative to the physical world. It also contains the
-information needed to position and orient the virtual world relative to
-the physical world.
-</p>
-<p>Modifying the transform that maps the coexistence coordinate system
-into the virtual world coordinate system changes what the end user can
-see. The Java&nbsp;3D application programmer moves the end user within
-the
-virtual world by modifying this transform.
-</p>
-<p>
-</p>
-<h4>The Physical Coordinate
-Systems</h4>
-<h5> The Head Coordinate System</h5>
-The head coordinate system allows an application to import its user's
-head geometry. The coordinate system provides a simple consistent
-coordinate frame for specifying such factors as the location of the
-eyes and ears.
-<h5> The Image Plate Coordinate System</h5>
-The image plate coordinate system corresponds with the physical
-coordinate system of the image generator. The image plate is defined as
-having its origin at the lower left-hand corner of the display area and
-as lying in the display area's <em>XY</em>
-plane. Note that image plate is a different coordinate system than
-either left image plate or right image plate. These last two coordinate
-systems are defined in head-mounted environments only.
-<h5> The Head Tracker Coordinate System</h5>
-The head tracker coordinate system corresponds to the
-six-degrees-of-freedom tracker's sensor attached to the user's head.
-The head tracker's coordinate system describes the user's instantaneous
-head position.
-<h5> The Tracker Base Coordinate System</h5>
-The tracker base coordinate system corresponds to the emitter
-associated with absolute position/orientation trackers. For those
-trackers that generate relative position/orientation information, this
-coordinate system is that tracker's initial position and orientation.
-In general, this coordinate system is rigidly attached to the physical
-world.
-<h3>Head-Mounted Coordinate
-Systems</h3>
-Head-mounted coordinate systems divide the same virtual coordinate
-systems and the physical coordinate systems. <a href="#Figure_6">Figure
-6</a>
-shows these coordinate systems graphically. As with the room-mounted
-coordinate systems, the coordinate systems within the grayed area exist
-in the virtual world; those outside exist in the physical world. Once
-again, the coexistence coordinate system exists in both worlds. The
-arrangement of the coordinate system differs from those for a
-room-mounted display environment. The head-mounted version of
-Java&nbsp;3D's
-coordinate system differs in another way. It includes two image plate
-coordinate systems, one for each of an end-user's eyes.
-<h5> The Left Image Plate and Right Image Plate Coordinate Systems</h5>
-The left image plate and right image plate
-coordinate systems correspond with the physical coordinate system of
-the image generator associated with the left and right eye,
-respectively. The image plate is defined as having its origin at the
-lower left-hand corner of the display area and lying in the display
-area's <em>XY</em> plane. Note that the left image plate's <em>XY</em>
-plane does not necessarily lie parallel to the right image plate's <em>XY</em>
-plane. Note that the left image plate and the right image plate are
-different coordinate systems than the room-mounted display
-environment's image plate coordinate system.
-<p><a name="Figure_6"></a><img style="width: 499px; height: 162px;"
- alt="Display Rigidly Attached to Head Tracker"
- title="Display Rigidly Attached to Head Tracker" src="ViewModel6.gif"></p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 6</i> &#8211; Display Rigidly Attached to the
-Head Tracker (Sensor)</b></font>
-</ul>
-<p>
-</p>
-<h2>The Screen3D Object</h2>
-A Screen3D object represents one independent display device. The most
-common environment for a Java&nbsp;3D application is a desktop computer
-with
-or without a head tracker. <a href="#Figure_7">Figure
-7</a> shows a scene graph fragment for a display environment designed
-for such an end-user environment. <a href="#Figure_8">Figure
-8</a> shows a display environment that matches the scene graph
-fragment in <a href="#Figure_7">Figure
-7</a>.
-<p><a name="Figure_7"></a><img style="width: 499px; height: 185px;"
- alt="Environment with Single Screen3D Object"
- title="Environment with Single Screen3D Object" src="ViewModel7.gif"></p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 7</i> &#8211; A Portion of a Scene Graph
-Containing a Single Screen3D
-Object</b></font>
-</ul>
-<p>
-<a name="Figure_8"></a><img style="width: 500px; height: 237px;"
- alt="Single-Screen Display Environment"
- title="Single-Screen Display Environment" src="ViewModel8.gif"></p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 8</i> &#8211; A Single-Screen Display
-Environment</b></font>
-</ul>
-<p>
-A multiple-projection wall display presents a more exotic environment.
-Such environments have multiple screens, typically three or more. <a
- href="#Figure_9">Figure
-9</a> shows a scene graph fragment representing such a system, and <a
- href="#Figure_10">Figure
-10</a> shows the corresponding display environment.
-</p>
-<p><a name="Figure_9"></a><img style="width: 500px; height: 196px;"
- alt="Environment with Three Screen3D Object"
- title="Environment with Three Screen3D Object" src="ViewModel9.gif">
-</p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 9</i> &#8211; A Portion of a Scene Graph
-Containing Three Screen3D
-Objects</b></font>
-</ul>
-<p>
-<a name="Figure_10"></a><img style="width: 700px; height: 241px;"
- alt="Three-Screen Display Environment"
- title="Three-Screen Display Environment" src="ViewModel10.gif"></p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 10</i> &#8211; A Three-Screen Display
-Environment</b></font>
-</ul>
-<p>
-A multiple-screen environment requires more care during the
-initialization and calibration phase. Java&nbsp;3D must know how the
-Screen3Ds are placed with respect to one another, the tracking device,
-and the physical portion of the coexistence coordinate system.
-</p>
-<p>
-</p>
-<h2>Viewing in Head-Tracked Environments</h2>
-<p>The "<a href="#Generating_View">Generating a View</a>" section
-describes how Java&nbsp;3D generates a view for a standard flat-screen
-display with no head tracking. In this section, we describe how
-Java&nbsp;3D
-generates a view in a room-mounted, head-tracked display
-environment-either a computer monitor with shutter glasses and head
-tracking or a multiple-wall display with head-tracked shutter glasses.
-Finally, we describe how Java&nbsp;3D generates view matrices in a
-head-mounted and head-tracked display environment.
-</p>
-<h3>A Room-Mounted Display with
-Head Tracking</h3>
-When head tracking combines with a room-mounted
-display environment (for example, a standard flat-screen display), the
-ViewPlatform's origin and orientation serve as a base for constructing
-the view matrices. Additionally, Java&nbsp;3D uses the end-user's head
-position and orientation to compute where an end-user's eyes are
-located in physical space. Each eye's position serves to offset the
-corresponding virtual eye's position relative to the ViewPlatform's
-origin. Each eye's position also serves to specify that eye's frustum
-since the eye's position relative to a Screen3D uniquely specifies that
-eye's view frustum. Note that Java&nbsp;3D will access the PhysicalBody
-object to obtain information describing the user's interpupilary
-distance and tracking hardware, values it needs to compute the
-end-user's eye positions from the head position information.
-<h3>A Head-Mounted Display with
-Head Tracking</h3>
-In a head-mounted environment, the ViewPlatform's origin and
-orientation also serves as a base for constructing view matrices. And,
-as in the head-tracked, room-mounted environment, Java&nbsp;3D also
-uses the
-end-user's head position and orientation to modify the ViewPlatform's
-position and orientation further. In a head-tracked, head-mounted
-display environment, an end-user's eyes do not move relative to their
-respective display screens, rather, the display screens move relative
-to the virtual environment. A rotation of the head by an end user can
-radically affect the final view's orientation. In this situation, Java
-3D combines the position and orientation from the ViewPlatform with the
-position and orientation from the head tracker to form the view matrix.
-The view frustum, however, does not change since the user's eyes do not
-move relative to their respective display screen, so Java&nbsp;3D can
-compute the projection matrix once and cache the result.
-<p>If any of the parameters of a View object are updated, this will
-effect
-a change in the implicit viewing transform (and thus image) of any
-Canvas3D that references that View object.
-</p>
-<p>
-</p>
-<h2>Compatibility Mode</h2>
-<p>A camera-based view model allows application programmers to think
-about
-the images displayed on the computer screen as if a virtual camera took
-those images. Such a view model allows application programmers to
-position and orient a virtual camera within a virtual scene, to
-manipulate some parameters of the virtual camera's lens (specify its
-field of view), and to specify the locations of the near and far
-clipping planes.
-</p>
-<p>Java&nbsp;3D allows applications to enable compatibility mode for
-room-mounted, non-head-tracked display environments or to disable
-compatibility mode using the following methods. Camera-based viewing
-functions are available only in compatibility mode. The <code>setCompatibilityModeEnable</code>
-method turns compatibility mode on or off. Compatibility mode is
-disabled by default.
-</p>
-<hr noshade="noshade">
-<p><b>Note:</b> Use of these view-compatibility
-functions will disable some of Java&nbsp;3D's view model features and
-limit
-the portability of Java&nbsp;3D programs. These methods are primarily
-intended to help jump-start porting of existing applications.
-</p>
-<hr noshade="noshade">
-<h3>Overview of the
-Camera-Based View Model</h3>
-The traditional camera-based view model, shown in <a href="#Figure_11">Figure
-11</a>,
-places a virtual camera inside a geometrically specified world. The
-camera "captures" the view from its current location, orientation, and
-perspective. The visualization system then draws that view on the
-user's display device. The application controls the view by moving the
-virtual camera to a new location, by changing its orientation, by
-changing its field of view, or by controlling some other camera
-parameter.
-<p>The various parameters that users control in a
-camera-based view model specify the shape of a viewing volume (known as
-a frustum because of its truncated pyramidal shape) and locate that
-frustum within the virtual environment. The rendering pipeline uses the
-frustum to decide which objects to draw on the display screen. The
-rendering pipeline does not draw objects outside the view frustum, and
-it clips (partially draws) objects that intersect the frustum's
-boundaries.
-</p>
-<p>Though a view frustum's specification may have many items in common
-with those of a physical camera, such as placement, orientation, and
-lens settings, some frustum parameters have no physical analog. Most
-noticeably, a frustum has two parameters not found on a physical
-camera: the near and far clipping planes.
-</p>
-<p><a name="Figure_11"></a><img style="width: 500px; height: 202px;"
- alt="Camera-Based View Model" title="Camera-Based View Model"
- src="ViewModel11.gif">
-</p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 11</i> &#8211; The Camera-Based View Model</b></font>
-</ul>
-<p>
-The location of the near and far clipping planes allows the application
-programmer to specify which objects Java&nbsp;3D should not draw.
-Objects
-too far away from the current eyepoint usually do not result in
-interesting images. Those too close to the eyepoint might obscure the
-interesting objects. By carefully specifying near and far clipping
-planes, an application programmer can control which objects the
-renderer will not be drawing.
-</p>
-<p>From the perspective of the display device, the virtual camera's
-image
-plane corresponds to the display screen. The camera's placement,
-orientation, and field of view determine the shape of the view frustum.
-</p>
-<p>
-</p>
-<h3>Using the Camera-Based View
-Model</h3>
-<p>The camera-based view model allows Java&nbsp;3D to bridge the gap
-between
-existing 3D code and Java&nbsp;3D's view model. By using the
-camera-based
-view model methods, a programmer retains the familiarity of the older
-view model but gains some of the flexibility afforded by Java&nbsp;3D's
-new
-view model.
-</p>
-<p>The traditional camera-based view model is supported in Java&nbsp;3D
-by
-helping methods in the Transform3D object. These methods were
-explicitly designed to resemble as closely as possible the view
-functions of older packages and thus should be familiar to most 3D
-programmers. The resulting Transform3D objects can be used to set
-compatibility-mode transforms in the View object.
-</p>
-<p>
-</p>
-<h4>Creating a Viewing Matrix</h4>
-<p>The Transform3D object provides a <code>lookAt</code> utility
-method
-to create a
-viewing matrix. This method specifies the position and orientation of
-a viewing transform. It works similarly to the equivalent function in
-OpenGL. The inverse of this transform can be used to control the
-ViewPlatform object within the scene graph. Alternatively, this
-transform can be passed directly to the View's <code>VpcToEc</code>
-transform via the compatibility-mode viewing functions. The <code>setVpcToEc</code><code></code>
-method is used to set the viewing matrix when in compatibility mode.
-</p>
-<h4>Creating a Projection
-Matrix</h4>
-<p>The Transform3D object provides three methods for
-creating a projection matrix: <code>frustum</code>, <code>perspective</code>,
-and <code>ortho</code>. All three map points from eye coordinates
-(EC) to clipping coordinates (CC). Eye coordinates are defined such
-that (0, 0, 0) is at the eye and the projection plane is at <em>z</em>
-= -1.<br>
-</p>
-<p>The <code>frustum</code> method
-establishes a perspective projection with the eye at the apex of a
-symmetric view frustum. The transform maps points from eye coordinates
-to clipping coordinates. The clipping coordinates generated by the
-resulting transform are in a right-handed coordinate system (as are all
-other coordinate systems in Java&nbsp;3D).
-</p>
-<p>The arguments define the frustum and its associated perspective
-projection: <code>(left</code>, <code>bottom</code>, <code>-near)</code>
-and <code>(right</code>, <code>top</code>, <code>-near)</code>
-specify the point on the near clipping plane that maps onto the
-lower-left and upper-right corners of the window, respectively. The <code>-far</code>
-parameter specifies the far clipping plane. See <a href="#Figure_12">Figure
-12</a>.
-</p>
-<p>The <code>perspective</code> method establishes a perspective
-projection with the eye at the apex of a symmetric view frustum,
-centered about the <em>Z</em>-axis,
-with a fixed field of view. The resulting perspective projection
-transform mimics a standard camera-based view model. The transform maps
-points from eye coordinates to clipping coordinates. The clipping
-coordinates generated by the resulting transform are in a right-handed
-coordinate system.
-</p>
-<p>The arguments define the frustum and its associated perspective
-projection: <code>-near</code> and <code>-far</code> specify the near
-and far clipping planes; <code>fovx</code> specifies the field of view
-in the <em>X</em> dimension, in radians; and <code>aspect</code>
-specifies the aspect ratio of the window. See <a href="#Figure_13">Figure
-13</a>.
-</p>
-<p><a name="Figure_12"></a><img style="width: 500px; height: 209px;"
- alt="Perspective Viewing Frustum" title="Perspective Viewing Frustum"
- src="ViewModel12.gif">
-</p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 12</i> &#8211; A Perspective Viewing Frustum</b></font>
-</ul>
-<p>
-<a name="Figure_13"></a><img style="width: 500px; height: 212px;"
- alt="Perspective View Model Arguments"
- title="Perspective View Model Arguments" src="ViewModel13.gif"></p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 13</i> &#8211; Perspective View Model Arguments</b></font>
-</ul>
-<p>
-The <code>ortho</code> method
-establishes a parallel projection. The orthographic projection
-transform mimics a standard camera-based video model. The transform
-maps points from eye coordinates to clipping coordinates. The clipping
-coordinates generated by the resulting transform are in a right-handed
-coordinate system.
-</p>
-<p>The arguments define a rectangular box used for projection: <code>(left</code>,
-<code>bottom</code>, <code>-near)</code> and <code>(right</code>, <code>top</code>,
-<code>-near)</code>
-specify the point on the near clipping plane that maps onto the
-lower-left and upper-right corners of the window, respectively. The <code>-far</code>
-parameter specifies the far clipping plane. See <a href="#Figure_14">Figure
-14</a>.
-</p>
-<p><a name="Figure_14"></a><img style="width: 500px; height: 220px;"
- alt="Orthographic View Model" title="Orthographic View Model"
- src="ViewModel14.gif">
-</p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 14</i> &#8211; Orthographic View Model</b></font>
-</ul>
-<p>
-</p>
-<p>The <code>setLeftProjection</code>
-and <code>setRightProjection</code> methods are used to set the
-projection matrices for the left eye and right eye, respectively, when
-in compatibility mode.</p>
-</body>
-</html>
diff --git a/src/main/java/org/jogamp/java3d/doc-files/ViewModel1.gif b/src/main/java/org/jogamp/java3d/doc-files/ViewModel1.gif
deleted file mode 100644
index e94743e..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/ViewModel1.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/ViewModel10.gif b/src/main/java/org/jogamp/java3d/doc-files/ViewModel10.gif
deleted file mode 100644
index aceb6e7..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/ViewModel10.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/ViewModel11.gif b/src/main/java/org/jogamp/java3d/doc-files/ViewModel11.gif
deleted file mode 100644
index f943c15..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/ViewModel11.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/ViewModel12.gif b/src/main/java/org/jogamp/java3d/doc-files/ViewModel12.gif
deleted file mode 100644
index 787afe7..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/ViewModel12.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/ViewModel13.gif b/src/main/java/org/jogamp/java3d/doc-files/ViewModel13.gif
deleted file mode 100644
index a8482ef..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/ViewModel13.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/ViewModel14.gif b/src/main/java/org/jogamp/java3d/doc-files/ViewModel14.gif
deleted file mode 100644
index f201443..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/ViewModel14.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/ViewModel2.gif b/src/main/java/org/jogamp/java3d/doc-files/ViewModel2.gif
deleted file mode 100644
index 2d549b1..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/ViewModel2.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/ViewModel3.gif b/src/main/java/org/jogamp/java3d/doc-files/ViewModel3.gif
deleted file mode 100644
index 5285015..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/ViewModel3.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/ViewModel4.gif b/src/main/java/org/jogamp/java3d/doc-files/ViewModel4.gif
deleted file mode 100644
index ab9db1d..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/ViewModel4.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/ViewModel5.gif b/src/main/java/org/jogamp/java3d/doc-files/ViewModel5.gif
deleted file mode 100644
index 859b456..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/ViewModel5.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/ViewModel6.gif b/src/main/java/org/jogamp/java3d/doc-files/ViewModel6.gif
deleted file mode 100644
index 2200595..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/ViewModel6.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/ViewModel7.gif b/src/main/java/org/jogamp/java3d/doc-files/ViewModel7.gif
deleted file mode 100644
index ec84ac2..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/ViewModel7.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/ViewModel8.gif b/src/main/java/org/jogamp/java3d/doc-files/ViewModel8.gif
deleted file mode 100644
index ee4b331..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/ViewModel8.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/ViewModel9.gif b/src/main/java/org/jogamp/java3d/doc-files/ViewModel9.gif
deleted file mode 100644
index 0cbf72c..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/ViewModel9.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/VirtualUniverse.gif b/src/main/java/org/jogamp/java3d/doc-files/VirtualUniverse.gif
deleted file mode 100644
index 4d713a8..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/VirtualUniverse.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/VirtualUniverse.html b/src/main/java/org/jogamp/java3d/doc-files/VirtualUniverse.html
deleted file mode 100644
index 2f9dd14..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/VirtualUniverse.html
+++ /dev/null
@@ -1,265 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
- <meta content="text/html; charset=ISO-8859-1"
- http-equiv="content-type">
- <title>Java 3D API - Scene Graph Superstructure</title>
-</head>
-<body>
-<h2>Scene Graph Superstructure</h2>
-<p>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 <a
- href="#Figure_1">Figure
-1</a>).
-</p>
-<p>
-</p>
-<h2>The Virtual Universe</h2>
-Java 3D defines the concept of a <em>virtual universe</em>
-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.
-<p>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.
-</p>
-<p>To support large virtual universes, Java 3D introduces the concept
-of Locales that have <em>high-resolution coordinates</em>
-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.
-</p>
-<p>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.
-</p>
-<p><a name="Figure_1"></a><img style="width: 500px; height: 340px;"
- alt="The Virtual Universe" title="The Virtual Universe"
- src="VirtualUniverse.gif">
-</p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 1</i> &#8211; The Virtual Universe</b></font>
-</ul>
-<p>
-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.
-</p>
-<p>
-</p>
-<h2>Establishing a Scene</h2>
-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 "<a href="intro.html#Structuring">Structuring
-the Java 3D Program</a>")
-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.
-<h2>Loading a Virtual Universe</h2>
-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.
-<h2>Coordinate Systems</h2>
-By default, Java 3D coordinate systems are right-handed, with the
-orientation semantics being that +<em>y</em> is the local gravitational
-up, +<em>x</em> is horizontal to the right, and +<em>z</em> is directly
-toward the viewer. The default units are meters.
-<h2>High-Resolution Coordinates</h2>
-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).
-<p>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.
-</p>
-<p>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.
-</p>
-<p>
-</p>
-<h3>Java 3D High-Resolution
-Coordinates</h3>
-Java 3D high-resolution coordinates consist of three 256-bit
-fixed-point numbers, one each for <em>x</em>, <em>y</em>, and <em>z</em>.
-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). <a href="#Table_1">Table
-1</a> shows how many bits are needed above or below the fixed point
-to represent the range of interesting physical dimensions.
-<p><a name="Table_1"></a>
-<table bordercolorlight="#FFFFFF" bordercolordark="#000000" border="1"
- cellpadding="5" cellspacing="0">
- <caption><font size="-1"><b> <i>Table 1</i> &#8211;
-Java 3D High-Resolution Coordinates </b></font></caption><tbody>
- <tr bgcolor="#cccccc" valign="top">
- <th><font color="#003366" size="-1">2<sup>n</sup> Meters </font></th>
- <th><font color="#003366" size="-1">Units </font></th>
- </tr>
- <tr valign="top">
- <td> 87.29</td>
- <td>Universe (20 billion light years)&nbsp; <br>
- </td>
- </tr>
- <tr valign="top">
- <td> 69.68</td>
- <td>Galaxy (100,000 light years) </td>
- </tr>
- <tr valign="top">
- <td> 53.07</td>
- <td>Light year </td>
- </tr>
- <tr valign="top">
- <td> 43.43</td>
- <td>Solar system diameter </td>
- </tr>
- <tr valign="top">
- <td> 23.60</td>
- <td>Earth diameter </td>
- </tr>
- <tr valign="top">
- <td> 10.65</td>
- <td>Mile </td>
- </tr>
- <tr valign="top">
- <td> 9.97</td>
- <td>Kilometer </td>
- </tr>
- <tr valign="top">
- <td> 0.00</td>
- <td>Meter </td>
- </tr>
- <tr valign="top">
- <td> -19.93</td>
- <td>Micron </td>
- </tr>
- <tr valign="top">
- <td> -33.22</td>
- <td>Angstrom </td>
- </tr>
- <tr valign="top">
- <td> -115.57</td>
- <td>Planck length </td>
- </tr>
- </tbody>
-</table>
-</p>
-<p>A 256-bit fixed-point number also has the advantage of being able to
-directly represent nearly any reasonable single-precision
-floating-point value <em>exactly</em>.
-</p>
-<p>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.
-</p>
-<p>
-</p>
-<h3>Java 3D Virtual World
-Coordinates</h3>
-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.
-<h3>Details of High-Resolution
-Coordinates</h3>
-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.
-<p>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 <em>not</em> officially part of the
-Java 3D specification).
-</p>
-<p>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.
-</p>
-<p>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.
-</p>
-<p>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.
-</p>
-<p>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.
-</p>
-<p><strong>Semantics of widely moving objects</strong>. 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.
-</p>
-<p><strong>Semantics of viewing</strong>. 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.)
-</p>
-</body>
-</html>
diff --git a/src/main/java/org/jogamp/java3d/doc-files/intro.gif b/src/main/java/org/jogamp/java3d/doc-files/intro.gif
deleted file mode 100644
index 503f818..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/intro.gif
+++ /dev/null
Binary files differ
diff --git a/src/main/java/org/jogamp/java3d/doc-files/intro.html b/src/main/java/org/jogamp/java3d/doc-files/intro.html
deleted file mode 100644
index f5ea134..0000000
--- a/src/main/java/org/jogamp/java3d/doc-files/intro.html
+++ /dev/null
@@ -1,337 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
- <meta content="text/html; charset=ISO-8859-1"
- http-equiv="content-type">
- <title>The Java 3D API - Introduction</title>
-</head>
-<body>
-<h2>Disclaimer</h2>
-<p>
-<i>This guide, which contains documentation formerly
-published separately from the javadoc-generated API documentation,
-is <b>not</b> an
-official API specification. This documentation may contain references to
-Java and Java 3D, both of which are trademarks of Sun Microsystems, Inc.
-Any reference to these and other trademarks of Sun Microsystems are
-for explanatory purposes only. Their use does impart any rights beyond
-those listed in the source code license. In particular, Sun Microsystems
-retains all intellectual property and trademark rights as described in
-the proprietary rights notice in the COPYRIGHT.txt file.
-</i>
-</p>
-<hr>
-<h2>Introduction to the Java 3D API</h2>
-<p>The Java 3D API is an application
-programming interface used for writing three-dimensional graphics
-applications and applets. It gives developers high-level constructs for
-creating and manipulating 3D geometry and for constructing the
-structures used in rendering that geometry. Application developers can
-describe very large virtual worlds using these constructs, which
-provide Java 3D with enough information to render these worlds
-efficiently.
-</p>
-<p>Java 3D delivers Java's "write once, run anywhere"
-benefit to
-developers of 3D graphics applications. Java 3D is part of the
-JavaMedia suite of APIs, making it available on a wide range of
-platforms. It also integrates well with the Internet because
-applications and applets written using the Java 3D API have access to
-the entire set of Java classes.
-</p>
-<p>The Java 3D API draws its ideas from existing
-graphics APIs and from
-new technologies. Java 3D's low-level graphics constructs synthesize
-the best ideas found in low-level APIs such as Direct3D, OpenGL,
-QuickDraw3D, and XGL. Similarly, its higher-level constructs synthesize
-the best ideas found in several scene graph-based systems. Java 3D
-introduces some concepts not commonly considered part of the graphics
-environment, such as 3D spatial sound. Java 3D's sound capabilities
-help to provide a more immersive experience for the user.<br>
-</p>
-<!--
-<p><i>NOTE: Prior to version 1.4, the
-Java&nbsp;3D API was formally specified by a
-separate Java&nbsp;3D API Specification Guide, published separately
-from the javadoc. As of version 1.4,
-the javadoc-generated API reference is definitive. Relevant portions of
-the guide have been included here and supersede any previously
-published
-information.</i>
-</p>
--->
-<p>
-</p>
-<h2>Programming Paradigm</h2>
-Java 3D is an object-oriented API. Applications construct individual
-graphics elements as separate objects and connect them together into a
-treelike structure called a <em>scene graph</em>. The application
-manipulates these objects using their predefined accessor, mutator, and
-node-linking methods.
-<h3>The Scene Graph Programming
-Model</h3>
-Java 3D's scene graph-based programming model provides a simple and
-flexible mechanism for representing and rendering scenes. The scene
-graph contains a complete description of the entire scene, or virtual
-universe. This includes the geometric data, the attribute information,
-and the viewing information needed to render the scene from a
-particular point of view. The "<a href="SceneGraphOverview.html">Scene
-Graph Basics</a>" document provides more information on the Java 3D
-scene graph programming model.
-<p>The Java 3D API improves on previous graphics APIs
-by eliminating many
-of the bookkeeping and programming chores that those APIs impose. Java
-3D allows the programmer to think about geometric objects rather than
-about triangles-about the scene and its composition rather than about
-how to write the rendering code for efficiently displaying the scene.
-</p>
-<p>
-</p>
-<h3>Rendering Modes</h3>
-Java 3D includes three different rendering modes: immediate mode,
-retained mode, and compiled-retained mode (see "<a href="Rendering.html">Execution
-and Rendering Model</a>").
-Each successive rendering mode allows Java 3D more freedom in
-optimizing an application's execution. Most Java 3D applications will
-want to take advantage of the convenience and performance benefits that
-the retained and compiled-retained modes provide.
-<h4>Immediate Mode</h4>
-Immediate mode leaves little room for global
-optimization at the scene graph level. Even so, Java 3D has raised the
-level of abstraction and accelerates immediate mode rendering on a
-per-object basis. An application must provide a Java 3D draw method
-with a complete set of points, lines, or triangles, which are then
-rendered by the high-speed Java 3D renderer. Of course, the application
-can build these lists of points, lines, or triangles in any manner it
-chooses.
-<h4>Retained Mode</h4>
-Retained mode requires an application to construct a scene graph and
-specify which elements of that scene graph may change during rendering.
-The scene graph describes the objects in the virtual universe, the
-arrangement of those objects, and how the application animates those
-objects.
-<h4>Compiled-Retained Mode</h4>
-Compiled-retained mode, like retained mode, requires the application to
-construct a scene graph and specify which elements of the scene graph
-may change during rendering. Additionally, the application can compile
-some or all of the subgraphs that make up a complete scene graph. Java
-3D compiles these graphs into an internal format. The compiled
-representation of the scene graph may bear little resemblance to the
-original tree structure provided by the application, however, it is
-functionally equivalent. Compiled-retained mode provides the highest
-performance.
-<h3>Extensibility</h3>
-Most Java 3D classes expose only accessor and mutator methods. Those
-methods operate only on that object's internal state, making it
-meaningless for an application to override them. Therefore, Java 3D
-does not provide the capability to override the behavior of Java 3D
-attributes. To make Java 3D work correctly, applications must call "<code>super.setXxxxx</code>"
-for any attribute state set method that is overridden.
-<p>Applications can extend Java 3D's classes and add
-their own methods.
-However, they may not override Java 3D's scene graph traversal
-semantics because the nodes do not contain explicit traversal and draw
-methods. Java 3D's renderer retains those semantics internally.
-</p>
-<p>Java 3D <em>does</em> provide hooks for mixing
-Java 3D-controlled scene graph rendering and user-controlled rendering
-using Java 3D's immediate mode constructs (see "<a
- href="Immediate.html#Mixed">Mixed-Mode Rendering</a>"). Alternatively,
-the application can
-stop Java 3D's renderer and do all its drawing in immediate mode (see "<a
- href="Immediate.html#PureImmediate">Pure Immediate-Mode Rendering</a>").
-</p>
-<p>Behaviors require applications to extend the
-Behavior object and to
-override its methods with user-written Java code. These extended
-objects should contain references to those scene graph objects that
-they will manipulate at run time. The "<a href="Behaviors.html">Behaviors
-and Interpolators</a>" document describes Java 3D's behavior
-model.
-</p>
-<p>
-</p>
-<h2>High Performance</h2>
-Java 3D's programming model allows the Java 3D API to do the mundane
-tasks, such as scene graph traversal, managing attribute state changes,
-and so forth, thereby simplifying the application's job. Java 3D does
-this without sacrificing performance. At first glance, it might appear
-that this approach would create more work for the API; however, it
-actually has the opposite effect. Java 3D's higher level of abstraction
-changes not only the amount but, more important, also the kind of work
-the API must perform. Java 3D does not need to impose the same type of
-constraints as do APIs with a lower level of abstraction, thus allowing
-Java 3D to introduce optimizations not possible with these lower-level
-APIs.
-<p>Additionally, leaving the details of rendering to
-Java 3D allows it to
-tune the rendering to the underlying hardware. For example, relaxing
-the strict rendering order imposed by other APIs allows parallel
-traversal as well as parallel rendering. Knowing which portions of the
-scene graph cannot be modified at run time allows Java 3D to flatten
-the tree, pretransform geometry, or represent the geometry in a native
-hardware format without the need to keep the original data.
-</p>
-<p>
-</p>
-<h3>Layered Implementation</h3>
-Besides optimizations at the scene graph level, one of the more
-important factors that determines the performance of Java 3D is the
-time it takes to render the visible geometry. Java 3D implementations
-are layered to take advantage of the native, low-level API that is
-available on a given system. In particular, Java 3D implementations
-that use Direct3D and OpenGL are available. This means that Java 3D
-rendering will be accelerated across the same wide range of systems
-that are supported by these lower-level APIs.
-<h3>Target Hardware Platforms</h3>
-Java 3D is aimed at a wide range of 3D-capable hardware and software
-platforms, from low-cost PC game cards and software renderers at the
-low end, through midrange workstations, all the way up to very
-high-performance specialized 3D image generators.
-<p>Java 3D implementations are expected to provide
-useful rendering rates
-on most modern PCs, especially those with 3D graphics accelerator
-cards. On midrange workstations, Java 3D is expected to provide
-applications with nearly full-speed hardware performance.
-</p>
-<p>Finally, Java 3D is designed to scale as the
-underlying hardware
-platforms increase in speed over time. Tomorrow's 3D PC game
-accelerators will support more complex virtual worlds than high-priced
-workstations of a few years ago. Java 3D is prepared to meet this
-increase in hardware performance.
-</p>
-<p>
-</p>
-<h2><a name="Structuring"></a>Structuring the Java 3D Program</h2>
-<p>This section illustrates how a developer might
-structure a Java 3D application. The simple application in this example
-creates a scene graph that draws an object in the middle of a window
-and rotates the object about its center point.
-</p>
-<h3>Java 3D Application Scene
-Graph</h3>
-<p>The scene graph for the sample application is shown below.
-</p>
-<p>The scene graph consists of superstructure
-components&#8212;a VirtualUniverse
-object and a Locale object&#8212;and a set of branch graphs. Each branch
-graph is a subgraph that is rooted by a BranchGroup node that is
-attached to the superstructure. For more information, see "<a
- href="SceneGraphOverview.html">Scene Graph Basics</a>."
-</p>
-<p><a name="Figure_1"></a><img style="width: 500px; height: 263px;"
- alt="Application
-scene graph" title="Application scene graph"
- src="intro.gif"></p>
-<p>
-</p>
-<ul>
- <font size="-1"><b><i>Figure 1 &#8211; </i>Application Scene Graph</b></font>
-</ul>
-<p>
-A VirtualUniverse object defines a named universe. Java 3D permits the
-creation of more than one universe, though the vast majority of
-applications will use just one. The VirtualUniverse object provides a
-grounding for scene graphs. All Java 3D scene graphs must connect to a
-VirtualUniverse object to be displayed. For more information, see "<a
- href="VirtualUniverse.html">Scene Graph Superstructure</a>."
-</p>
-<p>Below the VirtualUniverse object is a Locale object.
-The Locale object
-defines the origin, in high-resolution coordinates, of its attached
-branch graphs. A virtual universe may contain as many Locales as
-needed. In this example, a single Locale object is defined with its
-origin at (0.0, 0.0, 0.0).
-</p>
-<p>The scene graph itself starts with the <a href="../BranchGroup.html">BranchGroup</a>
-nodes.
-A BranchGroup serves as the root of a
-subgraph, called a <em>branch graph</em>, of the scene graph. Only
-BranchGroup objects can attach to Locale objects.
-</p>
-<p>In this example there are two branch graphs and,
-thus, two BranchGroup
-nodes. Attached to the left BranchGroup are two subgraphs. One subgraph
-consists of a user-extended Behavior leaf node. The Behavior node
-contains Java code for manipulating the transformation matrix
-associated with the object's geometry.
-</p>
-<p>The other subgraph in this BranchGroup consists of a
-TransformGroup
-node that specifies the position (relative to the Locale), orientation,
-and scale of the geometric objects in the virtual universe. A single
-child, a Shape3D leaf node, refers to two component objects: a Geometry
-object and an Appearance object. The Geometry object describes the
-geometric shape of a 3D object (a cube in our simple example). The
-Appearance object describes the appearance of the geometry (color,
-texture, material reflection characteristics, and so forth).
-</p>
-<p>The right BranchGroup has a single subgraph that
-consists of a
-TransformGroup node and a ViewPlatform leaf node. The TransformGroup
-specifies the position (relative to the Locale), orientation, and scale
-of the ViewPlatform. This transformed ViewPlatform object defines the
-end user's view within the virtual universe.
-</p>
-<p>Finally, the ViewPlatform is referenced by a View
-object that specifies
-all of the parameters needed to render the scene from the point of view
-of the ViewPlatform. Also referenced by the View object are other
-objects that contain information, such as the drawing canvas into which
-Java 3D renders, the screen that contains the canvas, and information
-about the physical environment.
-</p>
-<p>
-</p>
-<h3>Recipe for a Java 3D Program</h3>
-<p>The following steps are taken by the example program to create the
-scene graph elements and link them together. Java 3D will then render
-the scene graph and display the graphics in a window on the screen:</p>
-<ul>
-1. Create a Canvas3D object and add it to the Applet panel.
- <p>2. Create a BranchGroup as the root of the scene branch graph.</p>
- <p>3. Construct a Shape3D node with a TransformGroup node above it.</p>
- <p>4. Attach a RotationInterpolator behavior to the TransformGroup.</p>
- <p>5. Call the simple universe utility function to do the following:</p>
- <ul>
-a. Establish a virtual universe with a single high-resolution Locale
-(see "<a href="SceneGraphOverview.html">Scene Graph Basics</a>").
- <p>b. Create the PhysicalBody, PhysicalEnvironment, View, and
-ViewPlat-form objects.</p>
- <p>c. Create a BranchGroup as the root of the view platform branch
-graph.</p>
- <p>d. Insert the view platform branch graph into the Locale.</p>
- </ul>
-6. Insert the scene branch graph into the simple universe's Locale.
-</ul>
-<p>The Java 3D renderer then starts running in an infinite loop. The
-renderer conceptually performs the following operations:</p>
-<pre> while(true) {<br> Process input<br> If (request to exit) break<br> Perform Behaviors<br> Traverse the scene graph and render visible objects<br> }<br> Cleanup and exit<br></pre>
-<h3>HelloUniverse: A Sample Java
-3D Program</h3>
-<p><a href="HelloUniverse.html">Click here</a> to see code fragments
-from a simple program, <code>HelloUniverse.java</code>,
-that creates a cube and a RotationInterpolator behavior object that
-rotates the cube at a constant rate of pi/2 radians per second.<br>
-</p>
-<h2>Other Documents<br>
-</h2>
-<p>Here are other documents that provide explanatory material,
-previously included as part of
-the Java 3D API Specification Guide.<br>
-</p>
-<ul>
- <li><a href="Concepts.html">Java 3D Concepts</a></li>
- <li><a href="SceneGraphOverview.html">Scene Graph Basics</a></li>
- <li><a href="VirtualUniverse.html">Scene Graph Superstructure</a></li>
- <li><a href="SceneGraphSharing.html">Reusing Scene Graphs</a></li>
- <li><a href="ViewModel.html">View Model</a></li>
- <li><a href="Behaviors.html">Behaviors and Interpolators</a></li>
- <li><a href="Rendering.html">Execution and Rendering Model</a></li>
- <li><a href="Immediate.html">Immediate-Mode Rendering</a></li>
-</ul>
-<p><br>
-</p>
-</body>
-</html>
diff --git a/src/main/java/org/jogamp/java3d/package.html b/src/main/java/org/jogamp/java3d/package.html
deleted file mode 100644
index d95eda6..0000000
--- a/src/main/java/org/jogamp/java3d/package.html
+++ /dev/null
@@ -1,40 +0,0 @@
-<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
- <meta content="text/html; charset=ISO-8859-1"
- http-equiv="content-type">
- <title>org.jogamp.java3d</title>
-</head>
-<body>
-
-<p>Provides the core set of classes for the
-3D graphics API for the Java platform; <a
- href="doc-files/intro.html">click here</a> for more information,
-including explanatory material that was formerly found in the guide.
-</p>
-
-<p>The 3D API is an application
-programming interface used for writing three-dimensional graphics
-applications and applets. It gives developers high-level constructs for
-creating and manipulating 3D geometry and for constructing the
-structures used in rendering that geometry. Application developers can
-describe very large virtual worlds using these constructs, which
-provide the runtime system with enough information to render these worlds
-efficiently.
-</p>
-
-<!--
-<p><i>NOTE: Prior to version 1.4, the
-Java&nbsp;3D API was formally specified by a
-separate Java&nbsp;3D API Specification Guide, published separately
-from the javadoc. As of version 1.4,
-the javadoc-generated API reference is definitive. Relevant portions of
-the guide have been included <a href="doc-files/intro.html">here</a>
-and supersede any previously
-published
-information.</i>
-</p>
--->
-
-</body>
-</html>