About Octree

1) You don''t need to store octree nodes which are empty - much of the area above the ground wil be empty space, so lots of empty nodes.


2) Personally I''d go for a more heirarchical approach:

a. Find the bounding box (OBB) of each *object* in the world. A single building would be an object, as would a single car on a road etc.

b. Make an octree which stores only the bounding boxes of the whole objects (as found in a.)

c. For visibility determination etc, use this octree to find which complete objects (buildings etc) are _probably_ visible.

d. Every one of the objects above has its own personal octree which is aligned to the bounding box of the object in the "world" octree (a & b). This local/personal octree is used for finer grained culling etc.

e. So to render a part of the city you do:
- Create a list of objects in the "world" octree which are in the view frustum
- For each object:
--- Check the octree for this object against the frustum,
--- any visible polygons/meshes* go for rendering
[* or whatever is stored by the finer grained octree]

f. You can extend the idea in both directions too - "districts" or "blocks" of a city could themselves be "super objects" in a wider octree describing the whole city. [Actually once you get to the citywide level a quadtree becomes more sensible]

.. <-- GALAXY, PLANET, WORLD, COUNTRY <--
CITY QUADTREE: occupied nodes contain AREA/BLOCK OCTREES
AREA OCTREE: occupied nodes contain OBJECT/BUILDING OCTREES
BUILDING OCTREE: occupied nodes contain meshes/polygons etc
.. --> SUB OBJECTS, PER RENDER STATE, PER TEXTURE -->

Hierarchies of hierarchies are often much more efficient (performance and space) than one hierarchy with inappropriate scale.


--
Simon O''Connor
Creative Asylum Ltd
www.creative-asylum.com

Thanks a lot. your suggestion is very helpful!