Sparse voxel signed distance octree ray-guided GPU streaming

[@Alexander_Sannikov]

This is the next step of my previous streaming experiment. Now instead of treating each octree leaf as a solid block, they are treated as 8x8x8 signed distance fields instead.

[@iestynne]

Wow, some of those debug modes are like abstract art

[@sythys_]

I loved playing with octs in cube 2 years ago.

[@wilkesreid]

I'm trying to work on the same thing, but I've only gotten as far as implementing an SVO in Vulkan using a vertex buffer for cube indices and indexed drawing. Nothing as efficient as this. Would you be up to touch base?

[@XorDev]

Scratching my head wondering how this works. What do the buffers look like?

[@TylerBata]

What do you use for the profiler? Looks really useful!

[@Alexander_Sannikov]

it's my profiler that i use for lots of stuff. it's rendered via imgui, all the relevant code is on Raikiri/LegitProfiler github repo. the profiler timestamps are gathered as part of Raikiri/LegitEngine render graph.

[@johnwilco5730]

this is super cool - perhaps a very basic question but, how do you decide when to split an octree cell? do you evaluate the SDF at the centroid of the cell and somehow compare that against the radius of the bounding sphere of the cell or something?

[@Alexander_Sannikov]

no, it's not a basic question, because there's no precise criterion for it, only heuristics. what I do is for a given branch's 8x8x8 rasterized SDF i check whether it changes sign or not (so whether it encodes a surface or not). obviously this won't work with branches that are too large (their sdf resolution is still 8x8x8), for higher levels of the hierarchy i just subdivide it forcefully until level 5 or so, and then prune all branches that will end up redundant.

[@johnwilco5730]

@@Alexander_Sannikov thank you for the quick reply! apologies if im misunderstanding something but, how do you know what a branch's 8^3 rasterized SDF "looks like" until you've hit leaf nodes? is the tree not built top down (from very coarse levels until you hit 8^3 resolution)? i guess i was assuming that it worked something like gigavoxels, where you recurse until you have an octree cell that is 8^3, at which point you allocate a "brick" that you fill up with SDF data, and afterwords, work backwards up the tree doing some sort of filtering to generate intermediate levels

[@Alexander_Sannikov]

@@johnwilco5730 actually this part is built exactly like giga-voxels: each leaf and each branch has a 8x8x8 SDF associated with it. Higher-level coarser branches are larger, so their 8x8x8 bricks are less detailed relative to the world space, so you further subdivide them in sub-branches. If a branch has all 8 of its sub-branches, then you won't even need its SDF while rendering, but it will become handy when one of the sub-branches gets unloaded. In general it's very useful to have SDF's associated not only with leaves, but with all branches too, and their memory usage is always less than that of the leaves, so it's not a big deal to store them. For each point in space you read the lowest available level of the currently loaded tree, but it also means that even a partially loaded tree is still renderable (just some branches will lack detail). When all goes well, each point in space corresponds to a leaf in the "working tree" and to a branch in a "full tree". The "full tree" lives on your SSD and you dynamically stream its subtree to the gpu that forms the working tree. But their branches contain exactly the same data (SDF's). The tree is built top-down and for each leaf you decide whether you want to further subdivide it (making it into a branch) or not, depending whether there's a sign change in its 8x8x8 brick.

[@johnwilco5730]

@@Alexander_Sannikov thanks for all of the insight! one interesting idea i saw on twitter (i think from one of the Dreams devs) was to use interval arithmetic to decide when to split an octree cell... i think. i dont know enough about IA to say. but it looks interesting enough to mention here. but im sure that's something you're already aware of :)

[@Alexander_Sannikov]

@@johnwilco5730 btw this whole gigavoxels-like-streaming journey was inspired by Alex Evans. yeah, i thought of using interval arithmetics too, but they only thing they help with is literally just the subdivision part which is most often done offline anyway, so it's not the biggest problem to start with.

[@trshmanify]

Can we check the implemention code?

[@3sc4p1sm]

The algorithm is such that each octant of the octree has an 8x8x8 field approximating the min distance of the interior ray step length? Did you follow any specific papers for the data structure? Presumably it is a typical ray marched svo implementation with the adaptive ray distance calculation optimization..? Adding 8x8x8 float array at each octant feels memory expensive

[@Alexander_Sannikov]

the data structure itself has an sdf in its leaves where interpolated value at each point is signed distance to the closest point of the surface that it corresponds to. this sdf is used for raymarching step estimation. i.e the sdf is a self contained representation of the geometry that's used by the raymarching algorithm, sdf itself, however, has nothing to do with raymarching inhetently. the idea of using an 8x8x8 bricks instead of a single value is that 8x8x8 bricks provide a much better data locality and ultimately memory usage because you don't waste space on storing all the octree pointers at the finest levels of the octree because even though each leaf contains more data, your octree has 8x8x8=512 times less nodes overall. you can also use hardware linear interpolation as well as the gpu texture cache to raymarch within a brick. this idea was popularized by the paper "learning from failures" by alex evans, 2015

[@Rafale25]

Is this project inspired by Voxelbee ?

[@Alexander_Sannikov]

it's mostly inspired by me wanting to try it for years, but also I saw another talk by digital molecule recently and those are always very inspiring

[@delphicdescant]

Lots of people have worked on ray-based voxel rendering engines for years before voxelbee made theirs. Whenever some project gets a lot of views on KZbin, we get viewers believing that project "invented" the idea. But hey, at least you didn't ask if this was a teardown clone.

[@Rafale25]

@@delphicdescant I don't think i watched his work before posting that 8 month ago, so yeah my bad Also, don't need to be rude please, i guess i posted this because of similarities i hadn't seen somewhere else like the translucide octree and "frustrum culling" with chunks loading after getting into the field of view

[@delphicdescant]

@@Rafale25 Sorry, I guess that did sound rude. I was frustrated by how often I see commenters attribute things to popular youtubers/figures, but that isn't your fault and I shouldn't have made the comment.