Culling for long and thin objects

We are wasting a lot of resources during drawing because of many long and thin objects that are computed in frustum and they are not.

For example, if you have a very long & thin electrical cable, you get a huge bounding sphere that it’s always “in frustum”.

Is there any more smart approach to get rid of this kind of objects?

Thank you!

Alberto

Cheap Bounding Sphere tests will cull the lion’s share of the out-of-frustum objects away. But for objects (or object groups) that are relatively short in 1 or 2 of the 3 dimensions, you may want OBBs (Oriented Bounding Boxes) under the spheres to discard most of the stuff that’s out-of-frustum but yet has a Sphere that straddles the edge of the frustum. You’ll just have to balance that against the cost of 2nd level OBB culling.

The good thing is that you only pay the cost for OBB tests in cases where the Spheres straddle the edge of the frustum. If the Sphere is completely outside, no sense in checking the OBB. And if the Sphere is completely inside, again, no sense in checking the OBB. OBB test can be made fairly efficient tool. After you get its point and vector in the right space, it’s a few adds and a few dot products and compares IIRC. There may be even simpler ways to check.

However, if you haven’t already, determine what the “wasting a lot of resources during drawing” really is? Is this CPU overhead of submitting a bunch of separate batches for wires? If so, batch them up spatially by render state and cull+draw as a group. Is this vertex transform cost? If so, same thing with some group-based LOD using estimated screen width calculation (i.e. small feature culling). Depending on your bottleneck(s), the best solution may have nothing to do with better culling but better batching and LOD.

OBB computation is slow, our sequence is:

  1. flatten the scene graph
  2. small and -sphere-based- frustum culling
  3. draw

With “wasting” I refer to drawing objects actually outside the frustum at every frame and skipping important ones (always in frustum) to keep the desired framerate.

Thanks again for your precious help.

Alberto

Yeah, but the point is that it prevents you from doing something even slower: rendering unseen meshes. Also, you should only do it for objects that need it.

A valid approach for this type of object is to not bother with CPU frustum culling but just draw it anyway. If the object is simple enough the cost of doing this might be cheaper than the cost of CPU culling it.

This is exactly what we are talking about: https://screencast-o-matic.com/watch/crlbQHV2EA9

During dynamic movements, a lot of objects in frustum (but not visible) are drawn before the object(s) in focus and to maintain the required FPS they are skipped.

The result is unacceptable from the end-user point of view.

More in general, even with slow & accurate frustum culling this could still happen but it should be less likely.

Any idea on how to avoid this problem? Most of the common approaches, like sorting by screen size at every frame are prohibitive with a large number of objects.

Thanks,

Alberto

No, this is not “exactly what we are talking about.” Initially, you asked about “many long and thin objects that are computed in frustum and they are not”. That’s a question of how to do frustum culling more effectively.

You’re now talking about general object visibility within a scene. Such techniques can include aspects of frustum culling (if a portal is found to not be in the frustum, you don’t render anything within it), but they’re functionally a separate thing (just because a portal is inside the frustum doesn’t mean everything inside of it is).

This is a different topic with different solutions. You’re talking about things involving BSPs, portal visibility culling, and so forth. These things generally require some pre-processing of the fixed objects in the scene.

There’s no free lunch. There’s no simple algorithm that can guarantee zero overdraw. You either use more advanced culling techniques (portal visibility, etc) which will take up more CPU time, or you accept that you’re going to draw stuff that’s not visible. There’s going to be a tradeoff.

It’s up to you and your particular needs (many visibility techniques require some knowledge of what the scene is) to decide which techniques to use.

Alfonse,

Regarding this:

No, this is not “exactly what we are talking about.” Initially, you asked about “many long and thin objects that are computed in frustum and they are not”. That’s a question of how to do frustum culling more effectively.

the video should show how poor frustum culling affects the drawing of a complex scene.

Are you talking about these?

https://visualizationlibrary.org/documentation/pag_guide_portals.html

Thanks,

Alberto