Determine whenever box is visible in frustum

This topic is 1022 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

I'm talking about case when frustum is inside the box or i see the side of a box but every point of box is outside of frustum, i can't find any solution for that.

Share on other sites

I am not certain if I understand the question correctly, but here is a short tutorial on frustum culling: View Frustum Culling. You can check the second section about Testing Boxes, which gives an efficient method to determine if the box is inside, outside or intersects the frustum. If the above does not help, could you please elaborate (perhaps with pictures) what is the specific case you need to determine?

Share on other sites

as shown there are two cases:

one box is visible (covers whole screen) and points are all outside of frustum thats the easy one (you can make another exaple when 50% of box is outside of far plane) anyway

theres second case when only part of the box is bisible thus its vertices are outside of frustum but still testing against each frustum plane will return that its not visible

or

or you coudl imagine that frustum intersect right line of box

Edited by WiredCat

Share on other sites

You should only reject a box if all vertices are "outside" the same frustum plane.

Edited by Eternal

sorry for -1 rep

Share on other sites

You should only reject a box if all vertices are "outside" the same frustum plane.

OP doesn't mention whether he's trying to implement frustum culling so I believe it's worth to mention that such approach isn't error free. Sometimes it gives false-positives, as in flags box as visible even though it is not.

Share on other sites

its vertices are outside of frustum but still testing against each frustum plane will return that its not visible

Perhaps I am missing something obvious, but I can't imagine a case when this happens. If we pick the most distant point of the box for each of the view frustum's planes in respect to the plane's normal, we'll see the points are always on the positive half-space, even though none of them is inside the frustum itself. See the image below:

[attachment=30787:FrustumCulling.png]

OP doesn't mention whether he's trying to implement frustum culling

Perhaps we need more details what he needs this for, before we can help.

Edited by vanka78bg

Share on other sites

And after having written the above, I'm now reassessing whether it's really worth it to do all those computations in order to eliminate false positives

My idea to speed things up is to bound the frustum with a cone and test against that, the remaining false positives might be acceptable.

What i do in practice is to clip the box polygons inside frustum, because i need this for software hidden surface removal anyways.
There are always only 1-3 polys visible, i guess this could be used to speed up any approach a lot.

http://iquilezles.org/www/articles/frustumcorrect/frustumcorrect.htm

Share on other sites

Usually GJK is used to quickly figure out if two pieces of 3D geometry are intersecting, or not. This is great for visibility testing. Assuming some kind of spatial partition is used the frustum can be treated as an AABB (or some other primitive) and tested against the spatial partition's primitives to rule out most potential collision pairs. Then, when an object is close enough to the frustum to get through the spatial partition GJK can be used to quickly figure out if an actual volume intersection occurs.

3D GJK isn't too hard to implement and I'm sure there are some 3D sources online to refer to. My suggestion to anyone that would like to implement GJK is to take Erin Catto's 2D example and port it to 3D -- he has slides to explain the algorithm. Just a note for any future readers: the tetrahedron case has 14 Voronoi regions, and 15 cases counting the interior.

The reason GJK is preferred is that it crawls through the volumes of two 3D objects very effciently, despite how complex they may be. It also doesn't do any extra work involving gathering information about *how* shapes are penetrating one another, making it focused solely on the closest features (to be exact, closest points) in the non-intersecting case. Explained another way: GJK treats the problem of closest points on two objects as closest point on *a single* object to the origin; this allows for an efficient intersection testing algorithm.

Erin's PDF and demo code.

If GJK isn't an attractive solution I did like Andy's idea for approximation

Edited by Randy Gaul

1. 1
2. 2
3. 3
4. 4
Rutin
13
5. 5

• 26
• 11
• 9
• 9
• 11
• Forum Statistics

• Total Topics
633701
• Total Posts
3013435
×