triangle in frustrum?

Started by
34 comments, last by CoderTCD 20 years, 5 months ago
Yes, close here...it''s better!
Advertisement
quote:Original post by Basiror
why would you test a single triangles against your frustrum

usually you should use some sort of octree/quadtree system and cull these against the viewfrustrum and if the node pass the test you render the scene
OGL does the rest for you

and actually his question has been answered and this topic should be closed
we don t need these pointless discussions


Yes I''ve been thinking of a way for making my terrain engine faster. At first I thought couldn''t use a quadtree because the terrain is so huge (2600*2600). But now I found another way to change it to a quadtree.
But this topic includes very useful information about the question. although the clipping is automatically made by opengl, understanding it''s principle is important for 3d programmers. (for me at least). I think it should stay.
In lod reduction algorithm quadtrees are stored in different ways...it''common to use quadtrees that are stored as a matrix of the same dimensions of your height map (but I cannot explain it without seem too low-level).
If you search you will find something about.
See also http://www.vterrain.org/ (there is everything about terrain)

However you continue to have the same problem: check for octree (generated from the quad) in view-frustum (and create the frustum itself)...but perhaps it''s useless because some wise men have discovered that OpenGL will do the clip for you. Wow!
quote:Original post by blizzard999
However you continue to have the same problem: check for octree (generated from the quad) in view-frustum (and create the frustum itself)...but perhaps it''s useless because some wise men have discovered that OpenGL will do the clip for you. Wow!


Not useless actually. OpenGL still has to transform all the vertices in your scene in order to determine whether or not they should be culled/clipped. If you can reject large parts of the geometry with a coarse test on octree or quadtree nodes then you can avoid this, and potentially save a lot of computation time.

As well as view frustum culling, Octrees can also be used very nicely in combination with extensions such as HP_occlusion_test or NV_occlusion_query in order to perform hardware occlusion culling on nodes (using their bounding boxes).

____________________________________________________________
www.elf-stone.com | Automated GL Extension Loading: GLee 1.12 for Win32

____________________________________________________________www.elf-stone.com | Automated GL Extension Loading: GLee 5.00 for Win32 and Linux

quote:Original post by blizzard999
In lod reduction algorithm quadtrees are stored in different ways...it''common to use quadtrees that are stored as a matrix of the same dimensions of your height map (but I cannot explain it without seem too low-level).
If you search you will find something about.
See also http://www.vterrain.org/ (there is everything about terrain)

However you continue to have the same problem: check for octree (generated from the quad) in view-frustum (and create the frustum itself)...but perhaps it''s useless because some wise men have discovered that OpenGL will do the clip for you. Wow!


I already use the advantage of constant x-z coordinates of the heightmaps. I just have to make a vertex array and change y coordinates in every frame duty the height values. I will also take a look at the web site you just wrote.
I''m also goint to saperate the vertex arrays into 16 quad parts so I will be able to eliminate averagely %60 of the triangles by just 16 frustrum checks (quadinfrustrum). So this is very efficent and have very low cpu usage. if opengl did it for every triangle it would cost more cpu and gpu.


quote:Original post by benjamin bunny

Not useless actually. OpenGL still has to transform all the vertices in your scene in order to determine whether or not they should be culled/clipped. If you can reject large parts of the geometry with a coarse test on octree or quadtree nodes then you can avoid this, and potentially save a lot of computation time.

As well as view frustum culling, Octrees can also be used very nicely in combination with extensions such as HP_occlusion_test or NV_occlusion_query in order to perform hardware occlusion culling on nodes (using their bounding boxes).


Occlusion queries are too expensive and less accurate than good and eventually optimized math algorithm. Some reasons

You cannot use queries on BB vertices because vertices can be out but the octree can be visible; to be sure you need to ''draw'' every face of the box to know if #pixels>0. You simply are drawing more than what you are culling. This fact has two drawbacks:
- you render a lot of pixels (you cannot render every BB!)
- you change GPU state and this is bad
- you pretend feedback from GPU that is terrible

Other reasons

- BB faces can be invisible from viewer but not its interior
- it requires a specific extension (you cannot implement an algorithm based on an extension)

This is well documented here http://oss.sgi.com/projects/ogl-sample/registry/NV/occlusion_query.txt

I cannot say that it is useless...but I think that it''s better to use it as a bonus in specific situation.

It''s clear that it''s stupid to cull a single triangle (portals and shadows are exceptions). But to test an octree you need your frustum and your test-functions. In this case I believe that only at high level octrees accurate culling is necessary...for smaller octrees a fast conservative algorithm should be better.


This topic is closed to new replies.

Advertisement