Graphics Reference
In-Depth Information
The second view says that there are several different coordinate systems, and
that the transformations tell you how to get from the tip's coordinates in one sys-
tem to its coordinates in another. We can then say things like, “The tip of the
minute hand is at ( 0, 9 ) in object space or object coordinates, but it's at ( 0,
9 )
in canvas coordinates.” Of course, the position in canvas coordinates depends on
the amount by which the tip of the minute hand is rotated (we've assumed that the
ActualTimeMinute rotation is 180 , so it has just undergone two 180 rotations).
Similarly, the WPF coordinates for the tip of the minute hand are computed by fur-
ther scaling each canvas coordinate by 4.8, and then adding 48 to each, resulting
in WPF coordinates of ( 48, 4.8 ) .
The terms object space, world space, image space, and screen space are
frequently used in graphics. They refer to the idea that a single point of some
object (e.g., “Boston” on a texture-mapped globe) starts out as a point on a unit
sphere (object space), gets transformed into the “world” that we're going to
render, eventually is projected onto an image plane, and finally is displayed on
a screen. In some sense, all those points refer to the same thing. But each point
has different coordinates. When we talk about a certain point “in world space”
or “in image space,” we really mean that we're working with the coordinates
of the point in a coordinate system associated with that space. In image space,
those coordinates may range from
1to1(orfrom0to1insomesystems),
while in screen space, they may range from 0 to 1024, and in object space, the
coordinates are a triple of real numbers that are typically in the range [
1, 1 ]
for many standard objects like the sphere or cube.
For this example, we have seven coordinate systems, most indicated by pale
green boxes. Starting at the top, there are WPF coordinates, the coordinates used
by drawPolygon() . It's possible that internally, drawPolygon() must convert to,
say, pixel coordinates, but this conversion is hidden from us, and we won't dis-
cuss it further. Beneath the WPF coordinates are canvas coordinates, and within
the canvas are the clock-face coordinates, minute-hand coordinates, and hour-hand
coordinates. Below this are the hand coordinates, the coordinate system in which
the single prototype hand was created, and circle coordinates, in which the pro-
totype octagonal circle approximation was created. Notice that in our model of
the clock, the clock-face, minute-hand, and hour-hand coordinates all play similar
roles: In the hierarchy of coordinate systems, they're all children of the canvas
coordinate system. It might also have been reasonable to make the minute-hand
and hour-hand coordinate systems children of the clock-face coordinate system.
The advantage of doing so would have been that translating the clock face would
have translated the whole clock, making it easier to adjust the clock's position
on the canvas. Right now, adjusting the clock's position on the canvas requires
that we adjust three different translations, which we'd have to add to the face, the
minute hand, and the hour hand.
We're hoping to draw each shape with a drawPolygon() call, which takes
an array of point coordinates as an argument. For this to make sense, we have
to declare the coordinate system in which the point coordinates are valid. We'll
assume that drawPolygon() expects WPF coordinates. So when we want to tell
it about the tip of the minute hand, we'll need the numbers ( 48, 4.8 ) rather
than ( 0, 9 ) .
 
 
Search WWH ::




Custom Search