
test triangle for visibility?
Hi all,
Is there a (preferably easy
way to test if a triangle passed to opengl would be at least partially visible?
Eg a function that, when called with a triangle as argument, _only_ returns with a true (=partially visible) or false(=not visible).
Or will i have to check "by hand"? (backface, outside frustrum or optional clipping planes, entirely hidden behind other object)

may not be what you''re looking for, but you might want to take a look at GL_NV_occlusion_query. Haven''t looked into it myself(I don''t have the internet at home, or the docs at school), but it looks like it could help.
I do it by hand. One tip: Try to exclude entire groups of triangles. Don''t test for every triangle. That''s just waaay to slow. Dig a little into QuadTrees and OcTrees. They''re real easy to implement/use and can do it quite fast.
- An eye for an eye will make the world go blind -
- An eye for an eye will make the world go blind -
<hr />
Sander Marechal<small>[Lone Wolves][Hearts for GNOME][E-mail][Forum FAQ]</small>
Thanks for the hint!
I found that either GL_HP_occlusion_test or GL_NV_occlusion_query should do what i need. However I did not find on what hardware / driver these are available. I suppose Nvidia cards support this (2,3,4?) but what about Radeon (8500)?
Also I would greatly appreciate a link to a tutorial on how to do this! I only started with opengl about a week ago and am still very unsure on how to do things.
I found that either GL_HP_occlusion_test or GL_NV_occlusion_query should do what i need. However I did not find on what hardware / driver these are available. I suppose Nvidia cards support this (2,3,4?) but what about Radeon (8500)?
Also I would greatly appreciate a link to a tutorial on how to do this! I only started with opengl about a week ago and am still very unsure on how to do things.
Hi smarechal,
When doing the occlusion test by hand, do you also test the depth buffer? I imagine this would be really slow.
Also, since my geometry is restricted in certain ways, I think ill only have to test several quads per scene.
After google''ing a bit I might try if a bounding sphere check is sufficient.
eg (r_obj + r_view)² < (distance of obj from view)²
unless i can figure out the hardware way. Any suggestions?
When doing the occlusion test by hand, do you also test the depth buffer? I imagine this would be really slow.
Also, since my geometry is restricted in certain ways, I think ill only have to test several quads per scene.
After google''ing a bit I might try if a bounding sphere check is sufficient.
eg (r_obj + r_view)² < (distance of obj from view)²
unless i can figure out the hardware way. Any suggestions?
hmmm.. i guess noone''s remembered the infamous frustrum/frustum culling method eh?
May 15, 2002 09:47 AM
Can anyone recommend a link that would have more information on GL_NV_occlusion_query? Thanks.
Testing every triangle every frame to see if it''s visible is not very fast. I recommend you use a scene partitioning algorithm (Octree''s are pretty easy and fast )
"THE INFORMATION CONTAINED IN THIS REPORT IS CLASSIFIED; DO NOT GO TO FOX NEWS TO READ OR OBTAIN A COPY." , the pentagon
Thanks for the feedback.
I do _not_ plan to check visibility for every triangle. Would be pointless since the check is roughly the same as a draw. I do have certain key triangles which I´d like to check, which, if not visible, would allow me to skip several larger structures. (Essentially the same as a bsp tree i believe).
I am aware of "software" ways of doing this, in theory, but would appreciate a link to a tutorial or a code snippet. Question that remains here is, can i effectivly check if a triangle would not be drawn due to the depth buffer?
Concerning GL_HP_occlusion_test and GL_NV_occlusion_query: I think Im now aware what these do (which is exactly what i needed), how to check their presence and use them (just enable .. i said, i am new to opengl and this was one point that escaped me). But is there any resource where i can check what driver / card supports these 2 or are they generally available?
I do _not_ plan to check visibility for every triangle. Would be pointless since the check is roughly the same as a draw. I do have certain key triangles which I´d like to check, which, if not visible, would allow me to skip several larger structures. (Essentially the same as a bsp tree i believe).
I am aware of "software" ways of doing this, in theory, but would appreciate a link to a tutorial or a code snippet. Question that remains here is, can i effectivly check if a triangle would not be drawn due to the depth buffer?
Concerning GL_HP_occlusion_test and GL_NV_occlusion_query: I think Im now aware what these do (which is exactly what i needed), how to check their presence and use them (just enable .. i said, i am new to opengl and this was one point that escaped me). But is there any resource where i can check what driver / card supports these 2 or are they generally available?
Ketzer:
Here''s in detail how I do it (sorry if it''s a bit lengthy). I do it all in top-down view 2D. I am doing terrain generation via QuadTrees. 2D is good enough for me.
3 step approach (in this order):
1) is point in range?
2) is point to the right of the left frustum line?
3) is the point to the left of the right frustum line?
If all are TRUE, point is visible. As soon as a FALSE is found, return.
To elaborate:
Px, Py is the point I need to check.
Far is the distance to the far clipping plane (found in gluPerspective)
1) if ((Px*Px)+(Py*Py) < Far*Far) return TRUE
I check against the squares of the FAR so I can avoid an expensive SquareRoot on the distance to P.
Now for some math: take another point Q (Qx, Qy). A infinitly long line is going from (0,0) through (Qx, Qy). Math says:
If (Py*Qx)-(Qy*Px) < 0 then P is to the left of line. If 0 then P is ON the line, if >0 then P is to the right of the line.
2)
figure out Qx and Qy. Real easy. Take camera position, take half the fov from gluPerspective and substract that from the camera rotation. Translate forward a bit (like 10.0f). There''s point Q.
Use the math to figure out if P is to the right of line camera-Q.
3) exactly like 2) but now ADD half the fov to the camera rotation and check if P is to the LEFT.
Still returning TRUE? then P must be visible in the frustum. I don''t do any other checks. The rest can be figured out by OGL''s Z-buffer.
One last tip: Using this will make object disappear on the left and right edge of the screen because they get discarded once they are on the border. You may drop out polygons that are still partially visible. To fix this:
-Figure out the size of your biggest object (Size).
-before adding or substracting half the fov: Translate backwards (Size). Proceed normally.
I''ve seen people extracting all the clipplanes from OGL. That works best if you want to check 3D. If you only want to check the frustum in 2D (like me), this will be faster.
- An eye for an eye will make the world go blind -
Here''s in detail how I do it (sorry if it''s a bit lengthy). I do it all in top-down view 2D. I am doing terrain generation via QuadTrees. 2D is good enough for me.
3 step approach (in this order):
1) is point in range?
2) is point to the right of the left frustum line?
3) is the point to the left of the right frustum line?
If all are TRUE, point is visible. As soon as a FALSE is found, return.
To elaborate:
Px, Py is the point I need to check.
Far is the distance to the far clipping plane (found in gluPerspective)
1) if ((Px*Px)+(Py*Py) < Far*Far) return TRUE
I check against the squares of the FAR so I can avoid an expensive SquareRoot on the distance to P.
Now for some math: take another point Q (Qx, Qy). A infinitly long line is going from (0,0) through (Qx, Qy). Math says:
If (Py*Qx)-(Qy*Px) < 0 then P is to the left of line. If 0 then P is ON the line, if >0 then P is to the right of the line.
2)
figure out Qx and Qy. Real easy. Take camera position, take half the fov from gluPerspective and substract that from the camera rotation. Translate forward a bit (like 10.0f). There''s point Q.
Use the math to figure out if P is to the right of line camera-Q.
3) exactly like 2) but now ADD half the fov to the camera rotation and check if P is to the LEFT.
Still returning TRUE? then P must be visible in the frustum. I don''t do any other checks. The rest can be figured out by OGL''s Z-buffer.
One last tip: Using this will make object disappear on the left and right edge of the screen because they get discarded once they are on the border. You may drop out polygons that are still partially visible. To fix this:
-Figure out the size of your biggest object (Size).
-before adding or substracting half the fov: Translate backwards (Size). Proceed normally.
I''ve seen people extracting all the clipplanes from OGL. That works best if you want to check 3D. If you only want to check the frustum in 2D (like me), this will be faster.
- An eye for an eye will make the world go blind -
<hr />
Sander Marechal<small>[Lone Wolves][Hearts for GNOME][E-mail][Forum FAQ]</small>
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement