I'm planning to use octree for “bloxel” chunk storage, because of its ability to compress portions of similar terrain to single node. While understand idea that single node can represent large space and new nodes can be allocated on demand, I'm barely can wrap my head around how to orient in such structure. I've seen that often node sizes used and there are algorithms (http://lsi.ugr.es/~curena/inves/wscg00/revelles-wscg00.pdf) for traversing such tree, another possible solution is “locational codes” (https://geidav.wordpress.com/2014/08/18/advanced-octrees-2-node-representations/) and node position is somehow calculated from path to the node. Ideally I want to achive 3d array like interface ( set(x,y,z, val), val = get (x,y,z) ). Also as I understand another complication is deciding when and how to simplify tree, is it fine just to reiterate over subnodes on the same level and if all subnodes (at one parent) contain same data they can be dropped and data can be propagated to their parent?
🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Octree for "bloxels".
If you want some types of portability such as moving data between CPU and GPU, you will want indexes not actual pointers. Also if you are multi-threading processes you can have separate threads work on their own arrays.
I always flag a LOD value in each node, so based on the level of detail required you know if the node is an end node or weather to traverse its children. This value reflects how much change there is in the node. Your description is very binary as though a node is either full or empty and you did not describe what to assume if it is nearly full or nearly empty or weather distance from camera will have an effect on final rendering.
Also I mostly work with terrains, and stitching different sized octree blocks into something like marching cubes is an issue but you might not be doing anything like that. For me it means I might split an octree that is solid because it is near a much smaller neighbour. That is a mesh generation issue not quad tree representation issue though.
