The simple view of windows and viewports described in Chapter 1 glossed over some important points and so we need to take another look. Assume that [wxmin,wxmax]
¥[wymin,wymax] and [vxmin,vxmax] ¥[vymin,vymax] define the window and view-port rectangles, respectively. See Figure 4.8. We shall not change the basic idea that a window specifies whatwe see and that the viewport specifies wherewe see it, but there was a natural implication that it is by changingthe window that one sees dif-ferent parts of the world. Is that not how one would scan a plane by moving a rec-Figure 4.6. Two-point perspective
view.
Figure 4.7. Three-point perspective view.
tangular window around in it? What is overlooked here is the problem that occurs when the viewport and the window are not the same size rectangle. For example, suppose that the window is the square [-2,2] ¥[-2,2] and that the viewport the rec-tangle [0,100] ¥[0,50]. What would happen in this situation is that the circle of radius 1 around the origin in the view plane would map to an ellipse centered at (50,25) in the viewport. What we know to be a circle in the world would show up visually as an ellipse on the screen. Would we be happy with that? This is the “aspect ratio” problem.
The reader may have noticed this already when implementing some of the program-ming projects. What can one do to make circles show up as circles?
The best way to deal with the aspect ratio problem would be to let the user change the viewport but not the window. The window would then be chosen to match the viewport appropriately. First of all, users are not interested in such low level concepts anyway and want to manipulate views in more geometric ways by using commands like “pan,” “zoom,” “move the camera,” etc. Secondly, in the case of 3d graphics, from a practical point of view this will in no way affect the program’s ability to handle dif-ferent views. Changing the camera data will have the same effect. In fact, changing the position and direction of the camera gives the program more control of what one sees than simply changing the window. Changing the distance that the view plane is in front of the camera corresponds to zooming. A fixed window would not work in the case of 2d graphics, however. One would have to let the user translate the window and change its size to allow zooming. A translation causes no problem, but the zooming has to be controlled. The size can only be allowed to change by a factor that preserves the height divided by width ratio. There is no reason for a user to know what is going on at this level though. As long as the user is given a command option to zoom in or out, that user will be satisfied and does not need to know any of the underlying technical details.
Returning to the 3d graphics case, given that our default window will be a fixed size, what should this size be? First of all, it will be centered about the origin of the view plane. It should have the same aspect ratio(ratio of height to width) as the view-port. Therefore, we shall let the window be the rectangle [-1,1] ¥ [-b,b], where b = (vymax-vymin)/(vxmax-vxmin). Unfortunately, this is not the end of the story. There is also a hardware aspect ratio one needs to worry about. This refers to the fact that Figure 4.8. The window and
view-port rectangles.
the dots of the electron beam for the CRT may not be “square.” The hardware ratio is usually expressed in the form a = ya/xa with the operating system supplying the values xa and ya. In Microsoft Windows, one gets these values via the calls
where hdc is a “device context” and ASPECTX and ASPECTY are system-defined constants.
To take the aspect ratios into account and to allow more generality in the defini-tion of the viewport, Blinn ([Blin92]) suggests using normalized device coordinates (NDC) for the viewport that are separate from pixel coordinates. The normalized viewport in this case will be the rectangle [-1,1] ¥ [-a,a], where a is the hardware aspect ratio. If Nx and Ny are the number of pixels in the x- and y-direction of our picture in pixel space, then Figure 4.8 becomes Figure 4.9.
We need to explain the “-e” terms in Figure 4.9. One’s first reaction might be that [0,Nx-1]¥[0,Ny -1] should be the pixel rectangle. But one needs to remember our discussion of pixel coordinates in Section 2.8. Pixels should be centered at half integers, so that the correct rectangle is [-0.5,Nx-0.5]¥[-0.5,Ny-0.5]. Next, the map from NDC to pixel space must round the result to the nearest integer. Since rounding is the same thing as adding 0.5 and truncating, we can get the same result by mapping [-1,1]¥ [-a,a] to [0,Nx]¥[0,Ny] and truncating. One last problem is that a +1 in the x- or y-coordinate of a point in NDC will now map to a pixel with Nx or Ny in the corresponding coordinate. This is unfortunately outside our pixel rectangle. Rather than looking for this special case in our computation, the quickest (and satisfactory) solution is to shrink NDC slightly by subtracting a small amount e from the pixel ranges. Smith suggests letting ebe 0.001.
There is still more to the window and viewport story, but first we need to talk about clipping.
xa GetDeviceCaps hdc ASPECTX ya GetDeviceCaps hdc ASPECTY
= ( )
= ( )
, ;
, ;
Figure 4.9. Window, normalized view-port, and pixel space.