Jump to content
  • Advertisement
Sign in to follow this  
iuliushide

Tricks Of The 3D Game Programming Gurus - Advanced 3D Graphics

This topic is 3977 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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 !

Share this post


Link to post
Share on other sites
Advertisement
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

Share this post


Link to post
Share on other sites
Quote:
Original post by iuliushide
It seems that nobody read this book !!!!
This is actually quite possible, if not likely. Most people here (myself included) have no respect for or interest in the books that LaMothe has written, and avoid them accordingly.

Share this post


Link to post
Share on other sites
Ask here

lamothe will probably answer it himself personally since he only sleeps like 2hr a day or so.
p.s. Yeah people rag on his books all the time but they can't change the fact that he was a pioneer when it came to game programming books. If it wasn't for him the only game programming info you'd find would still be through the web or knowing a game programmer personally.
I remeber his old DOS game programming in 21 days was the first game programming book I read and he personally answered all my questions via email back then about 10yr ago.

Share this post


Link to post
Share on other sites
Quote:
Original post by daviangel
Ask here

lamothe will probably answer it himself personally since he only sleeps like 2hr a day or so.
p.s. Yeah people rag on his books all the time but they can't change the fact that he was a pioneer when it came to game programming books. If it wasn't for him the only game programming info you'd find would still be through the web or knowing a game programmer personally.
I remeber his old DOS game programming in 21 days was the first game programming book I read and he personally answered all my questions via email back then about 10yr ago.


I also really enjoyed his old DOS game programming book along with his other ones on 2D game programming. But Promit is right.....every book after these first few was just a reiteration of the previous book. The first 3-4 chapters are about creating a window in DirectX. The next few chapters are about rendering sprites and drawing a 3D triangle. And if you're lucky, the last few chapters will be about sound and keyboard input.

Share this post


Link to post
Share on other sites
Quote:
Original post by soconne
Quote:
Original post by daviangel
Ask here

lamothe will probably answer it himself personally since he only sleeps like 2hr a day or so.
p.s. Yeah people rag on his books all the time but they can't change the fact that he was a pioneer when it came to game programming books. If it wasn't for him the only game programming info you'd find would still be through the web or knowing a game programmer personally.
I remeber his old DOS game programming in 21 days was the first game programming book I read and he personally answered all my questions via email back then about 10yr ago.


I also really enjoyed his old DOS game programming book along with his other ones on 2D game programming. But Promit is right.....every book after these first few was just a reiteration of the previous book. The first 3-4 chapters are about creating a window in DirectX. The next few chapters are about rendering sprites and drawing a 3D triangle. And if you're lucky, the last few chapters will be about sound and keyboard input.

Yeah even Lamothe admits he's already covered and recovered pretty much everything you need to make your own games using DirectX and 3D using DX so he's not writing any more books for it.
He's moved beyond and back to the lowlevel make your own console and program your game using assembly like in the old DOS book.

p.s. Another thing I noticed is that he likes to throw alot of math,physics and AI in his books probably due to his past engineering background.


Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!