It may sound anal, but the point of BSP is NOT finding intersections, it's for calculating partitions. They are not really the same thing -- it's just that BSP makes working with intersections easier.
Originally posted by Sayeh
Not quite. Although your meaning is somewhat correct, fundamentally the reason the two are compared the way I did is because each is a method of determining intersections. Nothing more, nothing less.
No, that would take too long because it would require you to check every polygon in the visible sectors and then you'd have to figure out which to cull out and which to split. It would take more time to do that than it would to accept drawing what's not visible. You basically just draw visible sectors and don't do any further than that. Otherwise it becomes counter-productive.
Doesn't standard frustum culling require you to split polygons before they are drawn, i.e create a new, smaller polygon that fits within the viewing volume (all of this determined mathematically). Or does it just calculate whether it is 'mostly' in or 'mostly' out of the viewing volume and either draw it or not draw it, but completely avoid the splitting.
The leaves are where the geometry for all of the sectors go, the rest of the tree is all of the partitions that lead up to the leaves. You don't partition in a pie form -- at least not in BSP. The reason BSP is called binary space partitioning is the fact that with each action you partition the current sector into 2 parts. You usually try to do this having equal polygon counts on each side.
what exactly is a leaf and how would they become concave? I don't know if this is an appropriate question, but how does a world get partitioned, i.e is it split up in a pie form with all of the partitioning boundaries intersecting at the middle? Erm...yeah...
If you understand binary trees, this shouldn't be a difficult concept.
So you start with a full world. Then you split it in half -- then, you split those 2 into 2 more halves, etc. and you keep going until you are left with a bunch of small sectors.
A concave sector is a sector made of polygons all facing inward with no overlap (IE a box). The reason for this is -- from within the box, no 2 walls can ever overlap each other. When you make all of your sectors concave like this, you only have to worry about drawing the furthest sector first, etc. and not have to worry about the order of drawing polygons within the sector because they themselves will never overlap.
Again, that's not as necissary with z-buffers, but z-buffers are only so accurate while the former concept is 100% accurate and fast.
The reason you used to want to always have concave sectors (and many times you still want to).