Some points that were pending.

The format of the octree can be multilevel, keeping, instead of the color, the address of the octree that follows it, and if the octree that continues is the same, then it will be infinitely recursive, get to do a test of this and it worked.

In the first versions of this format use the language :r4 that works in 32 bits, I am currently using the successor, called r3 that is 64 bits. The code to convert a set of voxels into the octree needs to sort the cubes by the morton code of the coordinates, the maximum I could save as a cube address was 10 bits, the 3 coordinates gives me 30 bits, until there the limit of the converter.

Here the converter in :r4

https://github.com/phreda4/reda4/blob/master/r4/3d/buildoctree.txt

When I wanted to try larger models I had to make a C version of the converter and that I needed the 64 bits to save up to 21bit per coordinate, this project converts the 75 million voxels sibernik model into 3do format.

https://github.com/phreda4/octree-generator-for-sibenik

Of course, the idea of ​​investigating how to rasterize an octree in an isometric perspective was to see the Bruce Robert Dell patent of euclideon that basically says that to render in projective perspective we can divide the octree until the perspective is indistinguishable from the isometric, and then apply this rendering, which, on the other hand is not explained.

https://patents.google.com/patent/US9842425B2/en?inventor=Bruce+Robert+DELL

Maybe improvements can be made to the algorithm, I progressed very slowly until I reached this version. The rendering version with the full perspective still does not work completely well, you can see these codes on the language page :r4 and r3