Jump to content
  • Advertisement
Sign in to follow this  
technobot

Frustum culling without plane-AABB checks?

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

Quote:
Original post by technobot
Ok, I think I've got it. Represent the frustum by a set of 8 AABBs, plus the 6 planes. The AABBs are: an outer AABB that bounds the frustum, 6 AABBs that bound the individual frustum faces (one for each face), and an inner AABB, which is the volume left between the 6 faces' AABBs.

Then the test goes like this:
1. If the tree cell does not intersect the outer AABB, there's definitely no intersection. Else:
2. If the cell intersects the inner AABB, there definitely is an intersection. Else:
3. Using the direction from the center of the inner AABB to the cell center, select three of the faces' AABBs that may be between the two centers. Also select the closest cell corner.
4. The selected corner is most likely within one of the selected AABBs. If so, find that AABB and continue. Otherwise, then there is no intersection.
5. Test the corner against the plane of the corresponding frustum face. If the point is on the correct side of the plane, there is an intersection, otherwise there isn't one.

For most cases it will be one or two AABB-ABBB tests per tree cell, for the remaining minority it will be up to five AABB-AABB checks and one point-plane check. It's fast, and it's accurate.



You're forgetting that for any reasonable FarPlane distance (i.e. Far Plane is not right there within 50 meteres). Your outer and plane bounding AABB-s will be gigantic (esspecially with 45 degree camera angles) causing a lot of objects to pass those tests. I'm preety sure your method will be a lot slower than plain AABB-Frustum testing. AABB-Frustum testing is actually preety fast if its done properly (esspecially if you use FrameCoherency and Masking).

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by A Guy from CRO
You're forgetting that for any reasonable FarPlane distance (i.e. Far Plane is not right there within 50 meteres). Your outer and plane bounding AABB-s will be gigantic (esspecially with 45 degree camera angles) causing a lot of objects to pass those tests. I'm preety sure your method will be a lot slower than plain AABB-Frustum testing. AABB-Frustum testing is actually preety fast if its done properly (esspecially if you use FrameCoherency and Masking).

The objects may pass the outer AABB test, but they will still be rejected by the final point-plane test, so that's ok. As for speed, an optimised AABB-frustum test would still require more calculations without frame coherency and masking, and while I'm not sure about it, it may be possible to utilize frame coherency for this test as well. Anyway, testing is the only way to know for sure.

Share this post


Link to post
Share on other sites
Of course they'll pass the final point'plane test but I'm saying your outer AABB and plane AABB's are encompassing a large chunck of the scene causing it to be very very unoptimal as they'll reject very few objects and the whole point of pretest's is fast early rejection. It all has to come down to point-plane test anyway, but I think your method will be slover.

Anyway, if you test, please post the results, I'd be interested in a comparison.

Share this post


Link to post
Share on other sites
Frustum vs AABB is very cheap if you do it correctly, there's definitely no need to test all corners against all planes. Taking the sign of the components of the planes normal vector can give you a bitmask that can be used to look up the only two vertices of the AAB you need to test. This can be done once per plane per frame, and then all you need to reject a AABB is two dot products.

Anyway, using sphere-sphere or sphere-frustum tests for early out is fine, but your frustum-AABB test should really be fast. If it isn't, something is wrong.

Share this post


Link to post
Share on other sites
I haven't got to the testing part yet, but I've realized that although my idea may test faster than the conventional approach against each individual quadtree node, it will probably turn out to be slower for an entire quadtree, since it does not descriminate between the "completely-inside" and "intersecting" cases. So unless I'll find a way around this shortcomming, I'm going to ditch this idea.

Share this post


Link to post
Share on other sites
Quote:
Original post by technobot
it will probably turn out to be slower for an entire quadtree, since it does not descriminate between the "completely-inside" and "intersecting" cases.


,-) see, exactly thats the reason why i usually would even advice to NOT use a tree for culling in some cases like smallish terrains with just a few hundred or thousand patches/leaves/whatever. the overhead of traversing the tree and doing extra work to detect complete and partial intersections often takes longer than just brute force testing all of them quick and dirty. though i guess with the right method you can minimize the extra work quite well.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!