Frustum Culling

Unity Engine
1

Hello guys.
Let me tell you that I didn’t have the chance yet to work with Unity, so I do apology if this may sound a silly question.
Based on what I’ve read on the forum, I’ve understood that the frustum culling in Unity is bounding box based. I was wondering if this is a simple AABBOX culling or a hierarchical type (quadtree, octree, etc).
In the former case, would be possible for us to develop and plug into the pipeline a hyerarchical type? Also, related to this, would be possible to develop bsp compiler with pvs as an editor plug-in?
Any information will be appreciated.
Thanks.

Eugenio

2

Right now it’s a simple (“flat”) bounding box culler. However, all the data is kept in nice small arrays, so the actual culling is really fast, making it into a hierarchy (octree, etc.) would not make that big difference. Right now it can cull 50000 objects at more than 200 frames per second, so at the typical world sizes the culling is never the bottleneck.

We plan to add portal based culler in Unity 2.0. Unlike a hierarchical one (which produces the same set of visible objects, only potentially faster), a portal culler would actually produce a smaller set of visible objects, especially in indoors-type games.

3

Aras, thanks for your reply.

Please bear with me, but your reply instilled few more questions on this.

  1. Let’s say I have a landscape (streets + buildings), a level a-la doom, or a track like the one you showcase in the car demo. Do I have to ‘cut’ in chunks the mesh by hand or the editor does it by itsef (i.e. based on material, etc)?

  2. What about the dynamic (i.e. actors) / static (i.e. crates) objects that are not included in the level mesh? Are they tested individually or can they be associated someway with the level ‘quadrant’ (chunk) where they lie?

  3. What about collision detection? Does each rigid body check for collisions with every other object in the frustum or we can group them someway?

  4. From your reply, I assume we can’t plug in the pipeline. Am I correct?

  5. Any chance to see some sort of octree for outdoors / physics in Unity v2?

  6. Could you please provide a rough (I know…I have read the other posts :wink:) estimate when v2 should become available?

Thanks.

Eugenio

4

I was talking only about the culler used for the rendering.

The physics/collision space partitioning is handled by PhysX, I believe they use some sort of sweep-and-prune for the broad collision phase. But I’ve gotta check that, all I know is that they are using “something” and that something does work fast :slight_smile:

Now onto the questions:

  1. Whatever you like. Your level is a bunch of objects (each can have multiple materials), and that is what’s culled and rendered. In general, less objects is faster; but on the other hand extremely big objects are not good either. The Performance Tips on the wiki has quite a lot of tips.

  2. Same here. Again, your level does not have to be a single object either. You don’t need to assign anything into any “quadrants”; the collision and physics will just work fast; and for rendering culling is really fast. Later on, when we add portals you might need to setup portals for your level manually.

  3. Answered above.

  4. You’re correct.

  5. Again, physics is already very fast. Not sure if that’s a (loose) octree or SAP, or combination of them, but most game developers should not be concerned about the internals as long as it’s fast :slight_smile:

    1. No precise date has been set; we’re mainly focused on making it really great. And stable too.