viewmodel.html

JAVA多媒体开发类库说明

<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