As always, there are many ways to save a figure composed of voxels in an octree.

The version I use has the advantage that, as it is stored on disk, it works when it is loaded into memory, that is, it does not need any processing.

As a disadvantage it can be seen that it is not possible to modify it dynamically, it would be possible that it occupies less place if it does not calculate is offset of the children but it would have to be modified when loading disk. And memory is also being wasted since the 32 bits of color are saved for each voxels, it is propagated for a version with palette but do not get to do any test.

First let's say that the object ends at a certain level, that is, all final voxels are the same size. This does not mean that we have a limit in the subdivision, on the contrary there is a way to generate several levels to represent many voxels or as I also test it, make the levels recursive, that is, a part of the octree is the same octree what is being defined.

All numbers are 32-bit integers,

the first in the number in hexadecimal $3d00000 with number of levels in the first byte, so if the first dword is the number $3d00008 it is an octree of 8 levels, that is, 256x256x256 voxels, the mario object have this resolution.

Next, the end of nodes and the start of pixel, next some unused numbers and the octree start in the byte 28 (7 dwords of header).

Now the octree, let's see in 2d how this encoding works, using a quadtree to save pixels.

Format .3do

First dword, format

----------------------------
x=0 normal
x=1 octree with suboctree
ss= power of dimenion
	..
	8=256^3
	9=512^3
	10=1024^3
----------------------------

0:	0x3d0000xss
4:	Nodes quantity
8:	Reserved for future use
12:	Reserved
16:	Reserved
20:	Reserved
24:	Reserved
28:	octree nodes
..
..
28+Nodes quatity*4: pixels
..
..


Example in quadtree

+--+--+-----+
|r |r |     |
+--+--+     |
|b |  |     |
+--+--+--+--+
|     |  |b |
|     +--+--+
|     |g |g |
+-----+--+--+


0:	$3d0000002
4:  3 ; 3 nodes , first pixel in 28+3*4
8:	0
12:	0
16:	0
20:	0
24:	0
28:	$000000009 ; 9=1001 binary ; NextNode=32+0	; level 0
32: $00000010b ; b=1011 binary ; NextNode=36+4	; level 1 children 1
36: $00000030d ; f=0111 binary ; NextNode 40+12 ; level 1 children 2
40: $7f7f3f ; color root node, average pixel 44 and 48
44: $ff007f ; color children 1, average r+r+b
48: $00ff7f ; color children 2, average g+g+b
52: $ff0000
56: $ff0000
60: $0000ff
64: $0000ff
68: $00ff00
72: $00ff00

We have a tree of fixed height, that is, it is not necessary to mark the end, only the nodes that arrive will have a voxel, and something very important, it is not necessary to use the last pointer level, since they are the voxels, we will save the color here.

Each node has in the lower byte the children it owns and in the upper 24 bits the number of nodes to go forward to find the first child, the rest of the children are recorded successively.

The size limitation used to advance the nodes can be seen here, it is not possible to advance more than 2^24 nodes between levels, but, assuming we have a 10-level object full of voxels, this is 1024x1024x1024 = 1073741824 voxels, which makes almost no sense since the internal voxels would not look. it will not be possible to represent it with this amount. I have 10 level items and they fit perfectly into this structure.

As I mentioned the last level of nodes does not exist, the check is that if the address of the node is larger than the size of the stored nodes, then this level is reached.

Note in the figure that only level 0 and level 1 are saved, although the node calculation does point beyond this limit, nodes do not exist (dotted nodes).

And the last piece to understand this coding, from the end of the nodes is the color of ALL the nodes, including the root, that is if I stop in node 0, the color of the node will be the first, if I stop at node 1 will be the second and so on.

The file size is going to be the size of all the color pixels plus the nodes of the octree minus the last level, which is the most expensive.

the mario.3do has 348kb

I leave for later the octree within the octree and the recursive octree. Please let me know if I need to explain any part in more detail