Culling Scene Geometry for Rendering

[darkprophet]

Umm…you will end up drawing more than you need using sphere bounds as opposed to boxes (near the frustum planes, where the actual object is out of view but the bound is still in) and hence the reason to using AABBs and OOBBs in complex scenary because you want to cull as many as you can…

Your calculations are based on calculating against a single plane, which isn’t the case in real situations. Also, if you use the n-p vertex test that I did, you only do 12 operations for a box bound and not 36.

Granted, I did say in my first post that spheres do take the least amount of CPU, but with AABBs and OOBB’s the GPU will still be the bottleneck and not the CPU, with spheres, your only making the matter worse (by sending more data near the frustums to the GPU).

Also, for the sphere-false positive thing, your using up more memory per bound as your having to store a Vec3f as an offset and a float for the radius + the Vec3f offset for the box and the Vec3f extents of the box and you have to recalculate both depending on animation, translation…etc.

So infact, your doing a load deal more than just testing against a plane with a sphere, you still need to initialise it and maintain the sphere and box. I am definetly sure (tho I haven’t done any tests) that this will be slower than just calculating OOBB’s because you need to go through each vertex to find the max extent and the mean of the vertices per update twice. Once for box and once for sphere in a scenegraph…

DP

[Vorax]

@darkprophet

Umm…you will end up drawing more than you need using sphere bounds as opposed to boxes (near the frustum planes, where the actual object is out of view but the bound is still in) and hence the reason to using AABBs and OOBBs in complex scenary because you want to cull as many as you can…

If the actual object is out of view, but the sphere intersects one of the planes, then that is a false positive. It doesn’t mean the object will be rendered, it means that a bounding box check will happen that is wasteful. With just bounding box tests, 90% tests (of the example) are wasteful. ANY bounding box test is slow compared to a sphere test that is why its very beneficial to cull the BB tests as well.

I am not sure how I am confusing you, but obviously I am not explaining this well.

Please read the flipcode link (http://www.flipcode.com/articles/article_frustumculling-pf.shtml) posted before. It’s a feature article by Dion Picco - its very well known. It’s basically considered must read on frustum culling. A frustum culling 101 guide for game developers.

Please, if such a link exists - I would like to read what bounding box test can outperform a hybrid sperical/bounding box combination for general purpose frustum culling.

Your calculations are based on calculating against a single plane, which isn’t the case in real situations. Also, if you use the n-p vertex test that I did, you only do 12 operations for a box bound and not 36.

Those numbers are for 6 planes, not one. It’s 1 test per point (radius or box corner) - which is actually a simplification as well. With plane aligned boxes you can cut that down to 4 checks though. Any optimization you make to the bounding box check is good - all the numbers I posted for the tests above drop, but drop with the same ratios. The sphere testing still gets you the same % less CPU utilization.

Granted, I did say in my first post that spheres do take the least amount of CPU, but with AABBs and OOBB’s the GPU will still be the bottleneck and not the CPU, with spheres, your only making the matter worse (by sending more data near the frustums to the GPU).

Again - With spherical testing combined with box testing - EXACTLY THE SAME NUMBER of operations/data is sent to the GPU -they just get there sooner because the CPU is less burdened - and that’s why it’s better.