[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In this subsection we go deeper into the structure of a sector. A very common case to use sectors is to define a sector with one thing which is convex and makes up the outer hull of the sector.
Then we have two possibilities. Either we stop here and add entities from the above list to this sector and use outgoing portals to define the rest of the world or else we first add a number of things and merge them into an octree/bsp-tree combination. After that we add further entities like above (and we can still use the outgoing portals). All things which are not marked as movable and detail can be added to the octree.
Note that this is only a very short explanation about BSP trees. There are much better documents explaining them.
A BSP tree is a way to partition space into convex subspaces. Crystal Space uses BSP trees mostly to get perfect Z ordering of polygons (i.e. front to back or back to front). Why Crystal Space needs this will be explained later.
To build a BSP tree you define one big thing containing all the polygons that will make the octree and mark it using the VISTREE keyword. The algorithm will then select one polygon to split all the others. This will create two child nodes. All polygons on the same plane as the splitter will be added to the current node. All polygons at the left side of the splitter will be added to the left node and all polygons at the right side will be added to the right node.
If a polygon intersects the plane of the splitter then the polygon will have to be split. The left side of the polygon will go to the left node and the right side to the right node.
This process continues recursively (i.e. into the left and right children) until there are no more polygons left.
This entire process creates a tree (i.e. a BSP tree) that can be used for many purposes. For instance, to render from back to front (painters algo) using a BSP tree you take the camera view point and then start traversing the tree. First you traverse the node that is on the back side of the splitter plane as seen from the camera. Then you traverse the polygons on the splitter (i.e. in this node) and then the polygons on the side in front of the splitter plane. This is also a recursive process. To render front to back you simply reverse the process.
An octree is a variant of a BSP tree. Instead of selecting a splitter from the given polygons you select three axis aligned splitter planes usually centered around the center of the set of input polygons. The planes are always axis aligned so you can't do much about that but there is some freedom with the choice of the center of those three planes. Crystal Space currently tries a number of random center points and selects the one which causes least number of splits. A better criterion would be to select a center which causes the planes to intersect as much solid space as possible. This is somewhat harder to implement. The reason why this is good has to do with visibility culling and PVS. If a splitter plane intersects more solid space than open space the chance is high that you will be able to cull nearby octree nodes. More about culling later though.
The advantages of an octree in comparison with a BSP tree is that it is easier to handle (easier to calculate) and also easier to do culling with as all nodes are boxes.
Crystal Space uses an octree for structuring polygons. However, at some number of polygons (currently set at 150) it will switch to BSP trees. So at the end you get a large octree with many mini-BSP trees at the leaves of the octree. This combined structure provides everything that Crystal Space needs for efficient visibility culling.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |