The Octree is favoured in games and rendering, because
- It supports visual level of detail, sensibly.
- It provides extremely tight compression of sparsely-populated spaces. (c.f. SVOs)
- At its lowest level it matches the uniformly-sized / -placed cells required for a voxel world. Other 3D accelerative structures may not do this, as explained below.
Full Explanation - TL;DR
Hierarchical spatial subdivision is used for two main reasons
- LoD: To avoid iterating over detail that is far away and thus not of interest;
- To accelerate iteration through a space, e.g. in raytracing or AI pathfinding, by walking a shallow level of the data structure where possible, i.e. where there are fewer nodes across a given distance.
Why is the octree commonly touted? As compared against it's usual competitor, the KD-tree, it...
Provides uniform subdivision at every level. This is an excellent way to achieve smoothly-degrading LoD (level of detail) while maintaining equal "smoothness" across each LoD grade. So visually this works better than a KD-tree, which isn't really suited to the purpose of LoD.
Is exactly the same form of subdivision at each level (8 children per parent with the same layout each time) so certain assumption can be made, resulting in fewer conditionals. Perhaps more importantly, this gives us more accurate bounds on processing cost than a KD-tree, which may have
N != 2 subdivisions in each axis... there is a general rule in engineering real-time systems that it is better to have a lower but stable FPS than an FPS with a high maximum rate and a too-low minimum.
Provides extremely rigourous compression as compared with other 3D spatial subdivision approaches; hence the term, "sparse voxel octrees" (SVOs). This means you can store a relatively enormous space containing a very small amount of voxel solids, efficiently, using an octree.
To give you some further persective, pros and cons for KD-trees:
- KD-trees tend to make more efficient use of space / time overall, in terms of the number of boundary planes the data structure contains, which also improves speed of traversal.
- Simply not suitable for distance-based LoD, due to variable granularity and alignment.
For most, it turns out that the pros of octrees end up winning the day. From an engineering standpoint, conceptual uniformity (simplicity) and predictability of execution paths win the day.
Less compact alternatives
In many instances it has been proposed that in spite of the conceptual simplicity of octree traversal, the octree is non-optimal in this sense due to the sheer number of levels of subdivision, which results from the division ratio (1:2 per axis) being so low. If, as in your case, instead of 2x2x2 children per node, there are 16x16x16, we would greatly reduce the number of node boundaries, simplifying cache linearisation which leads to better performance on the overall. Of course, what is crucial to note is that, as with most engineering decisions, this is a trade-off between space and time; the compression of sparse spaces will be far worse with 16x16x16 subdivisions, than with an octree. We call this flattening the data structure.