Question about ooc_svo_builder

[Forceflow]

On hold :)

Feel free to write a compatible viewer yourself!
Maybe hack something together with stb_voxel_render

[trsh]

@Forceflow Im going trough the documentation and got stuck by "morton: voxel payload" . Can you describe in simple worlds, what does this represent?

[Forceflow]

The voxel payload is additional info which is saved per voxel.

In the most simple voxel renderer, the only info you need is: "is there a voxel at this point in space or not?". Which is a binary value, and is inherently encoded in the tree: if the tree has a leaf there, there is a voxel :) If the tree doesn't have any leafs there, there are no voxels to be found - hence the tree is sparse there, which is the whole point of using a Sparse Voxel Octree.

Now, you might want to render some more interesting stuff. In my pipeline, I allow for a color (float32 R, float32 G, float32 B) and a normal (float32 X, float32 Y, float32 Z) to be stored in a node as well, which should be seen as " a color and a normal value representative of this voxel".

In this example, the payload (= data you store per voxel) also contains a morton code, which is a number which encodes the X, Y, Z position of the voxel in one 64-bit number.

So the total "voxel payload" = "data I want to store for every voxel of filled space" is:

• 64 bit morton code
• 32 bit + 32 bit + 32 bit color
• 32 bit + 32 bit + 32 bit normal

(Note that this is a horribly wasteful way of storing data, and the color and normal info could be reliably packed into one 32 bit value each, without losing too much precision)

[trsh]

Ok

[Forceflow]

Good luck :)

[trsh]

@Forceflow ok, but what the point of packing the coords into morton code? Is it much smaller?

[Forceflow]

The morton code at this point, if I recall correctly, is redundant and just for my own reference (I was working on some wild ideas back then). You can deduce the voxel's coordinates from its location in the tree as well.