frustrum culling slower

Started by
6 comments, last by Nibbles 22 years, 8 months ago
Hi, I made this simple terrain program that uses frustrum culling. The same methode used in Loadrunners QLAND program. So I duplicated the program and simply commented out the frustrum culling calls. My program is slower using frustrum culling that without it. I don''t get it. Scott Email Website
"If you try and don''t succeed, destroy all evidence that you tried."
Advertisement
if you want help, your going to have to share your problem in a tad more detail my frined ...
masterghttp:/masterg.andyc.org
Hay


It all depends on how you do it and what you are culling if you use a bad method to cull a huge amount of very simple object/polygons one buy one there could be a way that it could be slower. But then again if you use culling on the node’s of a quad/octree then you will be very efficiently culling a lot of data very quickly. I have no idea how you are coding your app. But you might want to take a look at the cone 3d octree tut, I am quite sure he covers culling (I must get round to reading the tut I have done a quick scan read). I use node and object culling I would say that it is very effective and if you are after high frame rates it is a must have feature.


Anon
That''s funny, so many people seem to be using the word ''frustrum'' instead of frustum... An example on how an initial spelling error became a pseudo-standard
yes, a cull meathod that works well with hundreds of thousands of poly''s could be horrible for a thousand.

Alex Broadwin
A-Tronic Software & Design
-----
"if you fail in life, you were destined to fail. If you suceed in life, call me."
"The answer is out there."
"Please help, I''m using Windows!"
Alex BroadwinA-Tronic Software & Design-----"if you fail in life, you were destined to fail. If you suceed in life, call me.""The answer is out there.""Please help, I'm using Windows!"
Well doing frustum rejection on each polygon seperately could definitely slow you down. You''d be better off using some sort of octree structure to group your polygons, say have about 50 in each node, and then frustum reject each node, remember the cool thing about octrees is that if a node isn''t in the frustrum then neither are any of its children. If you don''t understand about octrees then this won''t make much sense, check out the Cone3D octree tutorial recently discussed on this msg board for more information.

Obviously the 50 polygons per node can be adjusted to suit your app.

FatalXC
so basically, the checking of all the polygons to the "frustum" (depending on how many poly''s of course) can/will cause a greater slowdown that just drawing every poly? hmm.

and i just guessed frustrum instead of frustum... i guessed wrong. leave me alone

Scott

Email
Website

"If you try and don''t succeed, destroy all evidence that you tried."
That''s right.

The key to culling is to eliminate as much as you can with as few tests as you can... hence we use hierarchical (that looks wrong :/ ) space partitioning techniques (such as BSP trees, Quadtrees, Octrees) to group polys so that we can test in "chunks".

Hug a tree today... your 3D card will thank you

This topic is closed to new replies.

Advertisement