What follows is nothing but random musings relating to octrees which use the hierarchical volumes model as mentioned by Scronty in my CBoundingBox thread.

I was thinking about the process of building such a hierarchical octree from one big xfile and was struck by several revelations.
The first and most obvious (to me) is this: there is very little benefit to be gained from taking things too far: if we generate an octree all the way so that the terminal nodes contain single surfaces, we have to keep a boundingbox per surface in the world, which is impractical in terms of resource consumption, inefficient in terms of the cpu time taken to walk a tree to such a depth, and intensive in terms of the number of calculations being made on a per-surface-per-frame basis.
I started thinking about increasing the limit of how many surfaces we can have in a terminal node, ie, a cluster of geometry, and this led me to review my earlier work on something called "reference objects". Then it occured to me that we can speed up the generation of the octree to the point where it could be done as a realtime process while loading a level, if we exploit the hierarchical nature of xfiles. Simply put, this would be applied by the level designer in two stages: firstly by exploiting the Material tag to group polygons which belong to the same cluster (mesh subsets) and secondly by using the inherent object hierarchy feature of xfiles to guide the construction of the octree, even to explicitly define it.
During loading of such a level we would use the frames hierarchy of the xfile to create the major octree structure, and at the same time we'd use per-material subsets of the mesh within a given volume to embelish the octree further.
This method would not place undue responsibility on the level designer except to use unique materials for unique surfaces , and to split large surfaces into reasonably small subsets by using uniquely named materials. Rendering of all non-reference clusters would be possible just using the mesh subset function. Referenced objects would be inserted into the octree node structure using a specialised node structure catering to the fact that the geometry is in a different mesh. Reference objects would thus remain mere references, would be separately loaded as separate mesh objects, and would share their common geometry in the manor in which I believe ref objects were meant to be used. Rendering of referenced objects would use the same dx render function as the non ref stuff, except thered be no subdivision of the mesh required since we can assume that reference objects are relatively small in comparison to the world..that is to say, such a special octree node would need to store little more than a pointer to the loaded object's mesh interface. The world level file then becomes nothing but one fat binary xfile and necessary textures.
Am I losing my mind? :grin:
Posted on 2004-01-16 04:07:19 by Homer