Frustum: What is it for??

Started by
10 comments, last by Glass_Knife 20 years, 8 months ago
I have been working on understanding how 3D graphics work by trying to write my own software 3D engine, or at least do all the stuff using code. I have been surfing, reading, experimenting, and I''ve come to the conclusion that when trying to figure this stuff out on your own, everyone seems to understand everything until they get to the frustum/view projection/viewport part of the 3D pipeline. I understand model to world to camera just fine. But the stuff after that is fuzzy, and its mostly because there are many ways of doing it, and everytime I find an example, it''s done a different way. There does not seem to be much information about this, because most people don''t mess with this stuff because DirectX or OpenGL can do it for you behind the scenes. There a over 50 tutorials on how to set up the frustum in openGL, but not many on how to do it yourself with software. Here are my questions. 1. What is the frustum for? So far it seems that projecting the coord onto the viewing plane with perspective could be done without the frustm, but then objects might have z <= 0 which makes the projection equation not work. I''ve also seen examples of the frustum being normalized, so all the stuff to the front is expanded, causing a perspective view. This is the same view that I get if I don''t normalize the frustum, but divide by z during the viewport projection phase. Is the frustum just for clipping, or is there more to it? 2. How does the distance of the viewing plane from the camera figure into all this. Is there anyway to set this in OpenGL and Directx, or is that done for you because it doesn''t matter what the distance is. 3. Are there any alternatives to using the frustum to get a perspective view? Thanks in advance. Glass_Knife I think, therfore I am. I think?

I think, therefore I am. I think? - "George Carlin"
My Website: Indie Game Programming

My Twitter: https://twitter.com/indieprogram

My Book: http://amzn.com/1305076532

Advertisement
I don''t quite understand what do u mean by "setting frustum".U generally initialize the projection matrix that defines some boundaries.Later u can extract the frustum by the product of the projection and world matrix(i can''t figure why people call it modelview).A projection matrix can be initialized like that for example:

float m[16];memset(m,0,sizeof(float)*16);m[0] = cot(fov / 2) / ((float)viewport_width / viewport_height);m[5] = cot(fov / 2);m[10] = (far_plane + near_plane)/(near_plane-far_plane);m[11] = -1;m[14] = (2*far_plane*near_plane)/(near_plane-far_plane);


1.The term ''frustum'' is used not used when doing the perspective calculations.There is another term ''unit cube'' that is used for clipping yes.

2.This distance is called ''near'' plane and it''s of great importance.It DOES matter what the distance is and it will affect the clipping.

3.Huh?!

"Tonight we strike,there is thunder in the sky,together we''ll fight,some of us will die,but they''ll always remember that we''ve made a stand and many will die by hand!" - ManOwaR
OK, the first very important thing you have to understand is the following: there is a mathematical frustum, and a geometrical one. Both describe the same volume of space, but both use different representations, and are used for different purposes.

I suppose you already know that the space occupied by the frustum is the visible subset of the entire 3D space. It represents the pyramid that will be totally visible on screen.

Now, the mathematical frustum is actually your perspective projection equation. Both are the same thing: the equation mathematically describes that frustum. If you plotted the minimum and maximum ranges for each XY along the z axis, you would get a visual 3D representation of the space, in which the projection equation is considered valid: a double truncated pyramid - the frustum. So basically, the mathematical frustum is already encoded within your perspective projection, it is the visual representation of that projection''s valid space.

The shape of this frustum is defined by the parameters of the projection equation. This is done by supplying the maximum extends of an XY plane through the volume at a known distance from the frustum origin (which is assumed at 0,0,0). Although any plane could be specified, the plane at clipping distance is typically used: the screen plane. This distanced is often called the ''near clipping distance'', ie. the distance from the eye to the screen plane.

That distance is very important. Try to picture a frustum with the screen plane. Now, imagine that you keep the screen plane at a fixed position and size, but you move the eye towards it. See what happens ? The rays extending behind the plane will spread outwards. This means, that more space will be projected onto the screen plane. This inverse is also true: if you move the eye farther away from the screen plane, the rays will narrow down, and less will be visible. This effect is called the FOV (field of view). It is often measured as the angle between both -X/+X frustum limits (the horizontal FOV), and the -Y/+Y limits (vertical FOV). The effect is directly comparable to the FOV used in photographics: a large FOV angle (ie. a small eye to plane distance) is like a macro-lens: you''ll get a fisheye effect. A small angle (ie. large eye to plane distance) will give you a zoom-type effect.

Finally, you have the geometric frustum. It desribes the same volume of space than the mathematical one, by using 6 planes, positioned at the minimum and maximum extends of the mathematical frustum. Note, that this is just another way to describe the same viewing volume, the analytic form and the geometric form are mathematically equivalent. The geometric frustum is typically used for geometric object culling, by geometrically evaluating the intersection of objects with the frustum volume.

Now, that was just a quick''n''dirty rundown over the basic concepts, and somewhat over-simplified. If you have more detailed questions, feel free to ask.
quote:Original post by Mihail121
i can''t figure why people call it modelview


probably because opengl calls it like that, as it contains the model-world matrix and the view matrix. and most people just stick to the names they are used to ,-)
f@dzhttp://festini.device-zero.de
quote:Original post by Yann L
Now, that was just a quick''n''dirty rundown over the basic concepts, and somewhat over-simplified. If you have more detailed questions, feel free to ask.


Thanks to everyone who has tried to help me understand this stuff. I wish I could phrase my question in a more specific way, but because I am not clear on the theory, its hard to put into words what I am confused about.

Here is the equation I''m using that will get the points from 3D to the 2D view-plane( not sure on the correct name for this ). I am reading from TOT3DGPG, and the first part that I do not understand is the equation to figure out the distance of the viewplane from the camera. Here is the equation that is used...
dist = 0.5 * screenWidth * tan( fov / 2.0 );

I''ve messed with this, but I can''t figure out how this is true. By my calculations, the correct equation would be this...
dist = screenWidth / ( 2 * tan( fov / 2.0 );

Either way, the distance from (0,0,0) to the viewplane/projection plane is d, and the equation to project the points onto the viewplane screen is as follows...
viewplaneX = d * x / z;
viewplaneY = d * y * HeightWidthRatio / z;

I am trying to figure out how the frustum fits into this part.


Glass_Knife
I think, therfore I am.
I think?

I think, therefore I am. I think? - "George Carlin"
My Website: Indie Game Programming

My Twitter: https://twitter.com/indieprogram

My Book: http://amzn.com/1305076532

The viewing frustum cannot be determined using this equations of yours.Yes u are using advanced calculations but this is not the advanced possible.U need to use a ''projection'' matrix.When vertices are multiplied by the projection matrix then they can be checked agains the mathematical frustum as Yann pointed for clipping.Look at my first point to see how a projection matrix usually looks like.Of course u also can clip polygons using this equations of yours but you''ll have to clip against viewport.

"Tonight we strike,there is thunder in the sky,together we''ll fight,some of us will die,but they''ll always remember that we''ve made a stand and many will die by hand!" - ManOwaR
quote:Original post by Glass_Knife
[...]
Here is the equation that is used...
dist = 0.5 * screenWidth * tan( fov / 2.0 );

I''ve messed with this, but I can''t figure out how this is true. By my calculations, the correct equation would be this...
dist = screenWidth / ( 2 * tan( fov / 2.0 );



aren''t those two the same thing?

quote:Original post by psykr
aren''t those two the same thing?


dist = 0.5 * screenWidth * tan( fov / 2.0 );//his
dist = 0.5 * screenWidth / tan( fov / 2.0 );//mine

Mine and his are not the same thing. Which one is right??? I don''t know. That''s part of why I''m confused!





Glass_Knife
I think, therfore I am.
I think?

I think, therefore I am. I think? - "George Carlin"
My Website: Indie Game Programming

My Twitter: https://twitter.com/indieprogram

My Book: http://amzn.com/1305076532

Yours is right.

Look:


O is the frustum origin (the eye point). a is the fov angle, width the screen width (height is analogous). n is the near distance, ie. the distance from eye to screen plane. Then:

tan(a/2) = (width / 2) / n

tan(a/2) = width / (2n)

n = width / (2 * tan(a/2))


The perspective equations relate to your frustum in this way:


From here, you can use the simple mathematical relationship:

x' / x = z' / z

In terms of screenprojection, you would get:

x(screen) / x = n / z

x(screen) = (n*x) / z
y(screen) = (n*y) / z

This can all be encoded in a matrix, but you don't need to. The matrix encoding (as well as homogeneous coordinates) is basically a trick used to make the process compatible with a matrix based transformation pipeline (ie. the projection can be expressed as a matrix, and concatenated with others), and to make it more hardware friendly. It's in no way mandatory, especially not, if you write a software renderer.


[edited by - Yann L on August 6, 2003 3:10:33 PM]
Whoa, I never even noticed that error in the book. Did LaMothe mess up on his trig rules?

The funny thing is, the equation he used still plots the pixels on the screen correctly with no noticeable errors. Now I''m a little confused ..

This topic is closed to new replies.

Advertisement