What you will improve is culling speed since you can disregard subtrees without having to check every node when traversing the tree.
Right now I won't because my octrees are used strictly for data storage... When I generate polygonal data, I need to flatten them as a list. Which brings me to...
Trees are generally used to search data in a more efficient way, so if you're looking to have a smaller memory footprint then that's probably not the way to go.
The cases where you actually get better performance from octrees would likely be even further improved if you didn't store the tree but only 3D-areas with missing trixels - that is, like the first version but with width/height/depth for each point (or even better, only for the points that weren't 1,1,1)
Yeah. It makes sense now that you say it.
I think the real solution to my problem would be a custom data structure like the one you suggest. But those can be annoying to keep tidy. I liked about octrees how simple it was to collapse empty or full cells together...
why your octree have a fixed size?
It's only fixed because my triles are always 16x16x16. It doesn't make sense to make them smaller, or to have cells smaller than 1x1x1 for that matter...
About memory, octree doesn't use such great memory (...)
Agreed, but I'm still doubtful that it's smaller than my dictionary in any realistic case. (and in fact it's a hash set, since it would be a dictionary<vector3, bool>)
Also, i don't understand that thing you posted so well... it's like a file format were you store the octree?
Er, does this mean you're worried about disk storage and you're storing your data structures as text?
Yeah, about that...
My editor saves/loads my game content into an intermediate, human-readable and -editable file format as SDL (because it's much cleaner than XML in many respects), which is then compiled to a leaner binary format for the game.
What I'm worried about is that the SDL parser that I use (the open-source C# implementation) is pretty slow for big files, and with dictionaries for the trixels, my trile set files got pretty huge. Also having such huge lists of trixels defeats the "human readability" purpose. But then octrees are even worse.
In the end I'm probably going to go for a custom data structure that "chunks" trixels together into blocks, and saves a list of blocks, like Saint suggested.
Thanks for the insights everyone!