Graphics Reference
In-Depth Information
version, each geometry node has a color, and the
drawPolygon
procedure is passed
both the vertex coordinate array and the color. In a more complex version, the
color attribute may be set at some node in the graph, and that color is used for
all the geometry “beneath” that node. In this latter form, we can keep track of the
color with a parallel stack onto which colors are pushed as they're encountered,
just as transformations are pushed onto the transformation stack. The difference is
that while transformations are multiplied by the previous composite transforma-
tion before being pushed on the stack, the colors, representing an absolute rather
than a relative attribute, are pushed without being combined in any way with pre-
vious color settings. It's easy to imagine a scene graph in which color-alteration
nodes are allowed (e.g., “Lighten everything below this node by 20%”); in such
a structure, the stack would have to accumulate color transformations. Unless the
transformations are quite limited, there's no obvious way to combine them except
to treat them as a sequence of transformations; matrix transformations are rather
special in this regard.
Second, we've studied an example in which the scene graph is a
tree,
but
depth-first traversal actually makes sense in an arbitrary directed acyclic graph
(DAG). And in fact, our clock model, in reality,
is
a DAG: The geometry for the
two clock hands is shared by the hands (using a WPF
StaticResource
). During
the depth-first traversal we arrive at the hand geometry twice, and thus render two
different hands. For a more complex model (e.g., a scene full of identical robots)
such repeated encounters with the same geometry may be very frequent: Each
robot has two identical arms that refer to the same underlying arm model; each
arm has three identical fingers that refer to the same underlying finger model,
etc. It's clear that in such a situation, there's some lost effort in retraversal of
the arm model. Doing some analysis of a scene graph to detect such retraversals
and avoid them by prebaking can be a useful optimization, although in many of
today's graphics applications, scene traversal is only a tiny fraction of the cost, and
lighting and shading computations (for 3D models) dominate. You should avoid
optimizing the scene-traversal portions of your code until you've verified that they
are the expensive part.
Returning to the scene graph and the matrix products, the transformations applied
to the minute hand to get WPF coordinates,
⎡
⎣
⎤
⎦
⎡
⎣
⎤
⎦
⎡
⎣
⎤
⎦
⎡
⎣
⎤
10 8
01 8
00 1
4.8 0 0
0 .80
001
−
100
0
−
100
0
⎦
,
−
−
10
001
10
001
(10.89)
represent the transformation from minute-hand coordinates to WPF coordinates.
To go from WPF coordinates to minute-hand coordinates, we need only apply
the inverse transformation. Remembering that
(
AB
)
−
1
=
B
−
1
A
−
1
, this inverse
transformation is
⎡
⎤
⎡
⎤
⎡
⎤
⎡
⎤
−
100
0
−
100
0
1
/
4.8
0
0
10
−
48
⎣
⎦
⎣
⎦
⎣
⎦
⎣
⎦
.
10
001
−
10
001
−
01
/
4.8
0
01
48
00 1
−
(10.90)
0
0
1
You can similarly find the coordinate transformation matrix to get from any one
coordinate system in a scene graph to any other. Reading upward, you accumulate
