PDA

View Full Version : Frustum Culling Tutorial Available



Toom
12-10-2000, 10:54 AM
If anyone is interested, I've written up a small tutorial on Frustum Culling with OpenGL. It provides code for extracting the current frustum planes and routines to test points, spheres, and cubes against the frustum.

I think it's fairly easy to follow, and it even includes a demo (source and Windows EXE are included as well).

You can access it here (http://www.markmorley.com/opengl/frustumculling.html) .

Feedback would be appreciated, especially if you spot any mistakes.

Toom


[This message has been edited by Toom (edited 12-10-2000).]

ZeeBoy
12-11-2000, 11:19 AM
all i have to say is this is some nice ****.

not that ur code is **** this is just the stuff i was looking for thanx for puting it up

Zee

ZeeBoy
12-11-2000, 11:20 AM
i didnt know about the stars

they make it look worse than it is i love ur code

12-12-2000, 04:10 PM
Hi toom,

great sample code for those who want to make a 3D shooter. I'm an absolute newbie to OpenGL, but I'm quite fascinated of the possibilities and technics, which an 3D API like this offers. I think I will just stick around in your code for the next few hours, maybe I'll learn something.

It would be very cool if someone would post the fps rate, which he/she gets, when running the frustum-demo of toom. Mine is very slow. When I stand very close before a sphere it's about 9 fps. When I have set the the amount of Boxes to about 200 it is a framerate of 17 fps...200 Spheres are 5 fps.

If it's fullscreen? Why so slow, is my voodoo2 not working? Or are these magic framerates I see in all the games a result of the glide-API supplied by a 3DFX Chip?

ZeeBoy
12-13-2000, 01:45 PM
ive been getting between 70 to 85 fps with 1000 cubes on the screen and when culling is on and between 15 to 20 with it off.

with 1000 spheres im getting 2 fps with culling off and about 10 fps with it on

12-14-2000, 03:43 AM
Hi ZeeBoy,

umm, that sucks...What is your actual Graphic Card?

So, I think OpenGL is only rendering in Software modus on my PC. Is the v2 not supported?

daniel

ZeeBoy
12-14-2000, 10:22 AM
Hi Afxtwins,

I have a voodoo3 2000 pci. So yes 3dfx card r supported by OpenGL the prob may be ur drivers. I suggest downloading glsetup to update the drivers on ur machine

alternatuivly if u r using win2k go to www.3dfx.com (http://www.3dfx.com) and download the latest win2k drivers. glsetup dosnt work with win2k.

Hope u get it sorted

Zee

12-17-2000, 11:07 AM
Originally posted by ZeeBoy:
Hi Afxtwins,
<snip>
alternatuivly if u r using win2k go to www.3dfx.com (http://www.3dfx.com) and download the latest win2k drivers. glsetup dosnt work with win2k.
Zee

I just wanted to throw a quick word of caution in here for some other Win2000/3dfx/GL developers that might be following the discussion. At least in the case of the Banshee (and maybe the V3? not sure), it seems that 3dFX has not yet released an OpenGL "ICD" driver for Windows 2000. The beta driver on their site for windows 2000 only includes their "MCD", which is a "mini-GL" that only implements enough of OpenGL to be able to run Quake3 (ie. the mcd only implements the opengl calls that john carmack actually USED in the Quake3 engine). For most people doing basic GL things (like me, For Now) this won't be a problem, but it could spell trouble for anyone who wants to venture beyond the functionality of what is used by Quake http://www.opengl.org/discussion_boards/ubb/frown.gif Also, in light of the recent NVidia purchase of 3dFX (and as a result the dissolution of the company-- check their site for the news!), there may never be proper drivers available. That kinda sucks. I guess it's time to rush out and buy an NVidia card http://www.opengl.org/discussion_boards/ubb/frown.gif
--
Maciek/__Maad__

12-17-2000, 07:22 PM
Hi Maciek,

what's an ICD, if I'm granted to ask? :-)

http://members.home.com/borealis/opengl.html

On this site, which is from a guy called Ryan Haksi, you can get information for 3DFX support in your OpenGL applications. I've compiled the demo Application(2 rotating Cubes, one with coloring , one textures), and it looks really great, and it runs very smooth on my V2.

Punchey
12-17-2000, 07:33 PM
It seems that I can only get about 20 - 30 fps with a mere 200 spheres while using culling on my K62-400 w/TNT2 M64. That's even when only actually rendering a handful of spheres. To me, that seems awefully slow considering what's being done. Although some things I've written don't go all that much faster... I wonder how professional developers manage to get those blazing framerates while including AI, networking, shadows, reflections, etc.?

Hofi
01-06-2001, 03:20 AM
[QUOTE]Originally posted by Toom:
[B]If anyone is interested, I've written up a small tutorial on Frustum Culling with OpenGL. It provides code for extracting the current frustum planes and routines to test points, spheres, and cubes against the frustum.

snip
To Toom (and everybody):
Thank you very much for this very usefull tutorial.
I don't know anything about matrix math but i know how to use your tutorial.
However, i have a related question wich, i hope, you can answer very easily:
I have a camera with a very small field of view (about 1 degree) which can be moved, tilted and turned freely. For all objects, i use your culling code but there is also a "world" (sea-surface and sky).
Considered the small field of view, the world is very large in terms of viewing volumes. Therefore, i want to construct the world "on the fly" but only the part of it which is actually visible.
What i think i need to do this is the combined viewing volume as [min-x max-x min-y max-y min-z max-z].
The best solution would be an addition to your culling code since i am using it already.
Can you or any body help me, please? http://www.opengl.org/discussion_boards/ubb/smile.gif
Thank you very much in advance:
Peter (Hofi)

Relic
01-06-2001, 05:46 AM
Don't mix MCD and Mini-GL they are not the same!

ICD: Installable Client Driver. Contains the complete OpenGL implementation. Called via opengl32.dll.

MCD: Mini Client Driver. Contains only a HW rasterization backend. All other calculations are done by a Microsoft engine internally (mcdsrv32.dll, mcd32.dll). There is no way to optimize or to use a geometry processor with this kind of implementation. HW vendors write ICDs.

Mini-GL: (Already explained by Maciek above.)Small ICD(!) which contains only the subset of functions necessary to run selected games. May not be called OpenGL because of lack of functionality.

Relic
01-06-2001, 05:49 AM
Sorry, previous text had been posted twice.


[This message has been edited by Relic (edited 01-06-2001).]

01-06-2001, 08:44 AM
Wow! Cool Tutorial! Not exactly what I need, but near. My problem is that I have the A, B, C and D coordinates of a plane. Now I want to replace a plane of the frustum by the new one with the ABCD coordinates. But how?

01-06-2001, 08:52 AM
I think if you use this as the PolygonInFrustum function, the "false positive" does not occur:



bool PolygonInFrustum( int numpoints, POINT* pointlist )
{
int f, p, points = 0;

for( p = 0; p < numpoints; p++ )
{
for( f = 0; f < 6; f++ )
{
if( frustum[f][0] * pointlist[p].x + frustum[f][1] * pointlist[p].y + frustum[f][2] * pointlist[p].z + frustum[f][3] > 0 )
break;
}
if( f == 6 )
points++;
else
return false;
}
return points == numpoints;
}

Am I right? http://www.opengl.org/discussion_boards/ubb/confused.gif

Toom
01-06-2001, 10:16 AM
Your version will return true if all the points are in the frustum, but what if one corner of your polygon is outside the frustum? It's still visible and you'd still want to draw it.

And imagine a large quad that represents a wall. If your camera is right next to it, looking straight at it, it's certainly visible even though all four corners of it are outside of the frustum.

So yes, you eliminate the false positives, but you introduce even more false negatives, which is worse because those are visible while false positives are not.

Toom

01-08-2001, 04:37 AM
Well, thats right...

01-08-2001, 04:43 AM
What about this?



bool PolygonInFrustum( int numpoints, POINT* pointlist )
{
int f, p, points = 0;
for( p = 0; p < numpoints; p++ )
{
for( f = 0; f < 6; f++ )
{
if( frustum[f][0] * pointlist[p].x + frustum[f][1] * pointlist[p].y + frustum[f][2] * pointlist[p].z + frustum[f][3] > 0 )
break;
}
if( f == 6 )
return true;
}

return false;
}

This should work, I think.

Toom
01-08-2001, 09:51 AM
Afraid not. You're returning true if any one of the points is inside the frustum (ie: in front of all the planes). This still doesn't work for polygons that have ALL their points OUTSIDE the frustum, yet the plane of the polygon passes through some part of the frustum.

I don't think there's a way to get a perfect test without also testing the corners of the frustum itself against the plane of your polygon.

My tutorial has a diagram of this.

Toom