Could someone help me with the math at the "View Plane with Arbitrary Field of View and General Viewing Distance d" paragraph from this book ?!!! The praragraph is at chapter 6 ,page number 560 . Lamothe said "Normally, we first project the image onto the view plane with a focal distance d for both the x and y axes, with the view plane size {x:-1 to 1, y:-1/ar to +1/ar}. Then we would map that onto the screen by multiplying by the SCREEN_WIDTH and SCREEN_HEIGHT on the x and y axes." How could this be possible ,when in this case I have a field of view other than 90 degrees and then |x| != z also |y|!=z so the camera coordinates would not map to a rect like {x:-1 to 1, y:-1/ar to +1/ar} !!! Also at the page 547 he said that the focal distance d=(0.5)*width*tan(θh/2) but I think it must be d = (0.5)*width /tan(θh/2) according so the definition of tan function !!! Thanks in advance !

It seems that nobody read this book !!!! Well , i make one more try !
Is out there anyone who understands what on earth is LaMothe trying to explain ?

"View Plane with Arbitrary Field of View and General Viewing Distance d
Now that you’ve seen the construction of the perspective-to-screen transformation where
d = 1, and the field of view is 90 degrees where the view plane coordinates in perspective
space are normalized to –1 to 1 (on each axis for square projections), let’s talk about the
more general case, where we compute the d’s like this:
d = (0.5)*viewplane_width*tan(θh/2)//my comments-I think here is a mistake
Remember, in this case we solve for d based on the major axis (usually the x) field of view
angle: θh (which would normally be 90 degrees for a square projection plane, but could be
anything in this case). Additionally, we need the view plane dimensions we want to
project the final image on, which would be (SCREEN_WIDTH × SCREEN_HEIGHT) in case we
want the view plane to be the same size as the screen or view port. However, we need to
be careful, because screen coordinates have the following ranges:
x: (0..SCREEN_WIDTH-1)
y: (0..SCREEN_HEIGHT-1)
So, in the previous formulas, we must replace viewplane_width and viewplane_height
with the slightly different ranges (SCREEN_WIDTH-1) and (SCREEN_HEIGHT-1), like this:
d = (0.5)*(SCREEN_WIDTH-1)*tan(θh/2)
This calculation will give us the correct d value if we want to merge the perspective transform
and screen transform into one. However, the SCREEN_HEIGHT seems to have been left
out—NO! Normally, we first project the image onto the view plane with a focal distance d
for both the x and y axes, with the view plane size {x:-1 to 1, y:-1/ar to +1/ar}. Then we
would map that onto the screen by multiplying by the SCREEN_WIDTH and SCREEN_HEIGHT
on the x and y axes. But, because the ratio of SCREEN_WIDTH/SCREEN_HEIGHT is exactly the
aspect ratio ar, the multiplication and division cancel out. Thus, when you map directly to
the screen without the intermediate step of first going to view plane coordinates and then
to viewport screen coordinates, the aspect ratio terms cancel out, and you are left with
xper = (d*xc)/zc
yper = (d*yc)/zc
The results will already be scaled to (SCREEN_WIDTH × SCREEN_HEIGHT), so you get the screen
transformation free during the perspective transformation! Well, almost. There are a
couple problems with this … Give up? First, the y-axis is inverted for raster display,
because 0 is at the top of a raster display and at the bottom of quadrant I (which is where
the projection is working). That’s no problem: We can simply invert the y coordinates:
yper = (SCREEN_HEIGHT – 1) – yper
xper = xper
The second problem is a bit more subtle, and much worse. Although the projection will
have a total range of (SCREEN_WIDTH-1) on the x-axis and (SCREEN_HEIGHT-1) on the
y-axis, the actual coordinates pumped out will be in the range of
X-axis: -(SCREEN_WIDTH-1)/2 to (SCREEN_WIDTH-1)/2
Y-axis: -(SCREEN_HEIGHT-1)/2 to (SCREEN_HEIGHT-1)/2
Centered about (0,0), the range is split into a positive and negative half about zero on
each axis! Just as the normalized projection gave us coordinates –1 to 1 on each axis, we
now have similar, although scaled, coordinates. Alas, although we’ve gotten rid of our
post-perspective normalized-to-screen transform scaling operation, it looks like we are still
stuck with some translation of the origin. This is true, but we can fix it, along with the
y-axis inversion, with this simple transform after the initial perspective transform:
xscreen = xper + (0.5*SCREEN_WIDTH-0.5)
yscreen = -yper + (0.5*SCREEN_HEIGHT-0.5)
If you analyze the preceding operations, you will come to the conclusion that they are
almost identical to the normalized screen projection without the scaling operation. So, as
you can see, this projection stuff all ends up being the same thing in the end—it’s just
how you want to think about it. In fact, if we let a = (0.5*SCREEN_WIDTH-0.5) and b =
(0.5*SCREEN_HEIGHT-0.5) as before, we have Formula 6.8:" blah blah

You're right about the tangent thing, it should be the cotangent instead (which is 1/tangent).

After projection, anything outside the rectangle you're projecting into is out of the view of the camera and therefore not drawn. Any values that fall within the rectangle are then scaled to convert the value to screen space, to get the actual pixel coordinates.