Actual use of sparse voxel octrees in a game

oking for different ways to speed up my simple voxel system reducing the number of voxels and generated triangles, I stumbled upon these sparse voxel octrees. Now, I read a lot about it: how do they work, their implementation, pro and cons especially regarding level of detail (that was my research purpose). I am not an experienced game developer at all, until now I managed to create a simple yet working procedural generation based on chunks, contoured with Marching Cubes. As many other voxel engines, every chunk is formed by a tridimensional array of voxels, where each one has a density value and a position. Before I even start trying to implement a Voxel Octree, my questions are:

1) How can I "translate" my world generation in order to use the octrees?

2) Should I use an octree for every chunk, or justone octree with "big" bounds containing the whole generated data?

3) Regarding my project, the aim is to create simple spherical world (fairly big, definitely too much without a LOD), are Voxel Octrees even necessary for my purpose?

Forgive my ignorance, I probably don't have the basic knowledge on these topics, but I still wanted to try this cool stuff. Thanks!

 

Hello Strappo,

I know I'm a bit late to this thread, but just curious - did you ever find a solution for implementing octrees in Unity? I'm in exactly the same position as you - I've being tinkering around with my voxel engine - only I've gone with a DC (Dual Contouring) solution - I have a requirement for sharp geometry - e.g. things like buildings and other static objects that could be "voxelized", for lack of a better term.

My engine has started to grow in complexity (and therefore vert/ tri count) - and I've been on an optimization rampage. My engine is chunk-based as well, and while it was OK when things were simple, now I need a dynamic LOD and I too have been researching octrees, which lead me to your post, actually And I am looking for answers to the same questions you presented (minus the scale - my world isn't spherical).

In case you're still looking, if you haven't come across this library from Nition on GitHub - https://github.com/Nition/UnityOctree - it may be worth checking out. I'm planning on digging into it this weekend.

There was also this video I came across:

By Stegabyte that has a Unity project demoing octrees - that one I have tried out and it's pretty cool to watch the division as you add new objects, move existing ones around, etc. He supplies the full source, so it's excellent learning material.

As for the question concerning how to utilize octrees in place of chunks - my theory, based on the little I know about octrees, is that most require that you encapsulate your entire world, which becomes the "root" node. From there, depending on the view distance from the camera, the octree subdivides until the desired LOD is achieved (this is usually controlled by clamping the depth of the division).

In your case, if your world is a fixed size and you know the dimensions in advance, then based on that theory, I would think it would be rather straight forward to make the root node the dimensions of your world, and start subdividing. Those subdivisions would be recalculated as the player moves and the LOD needs updating, or if your terrain is destructible, every time the terrain changes.

I think the octrees replace the chunk method completely - but I could be wrong here. If that's the case, each node would represent a chunk in essence. I assume we would just place our voxels inside a node instead of a chunk, but my brain is telling me that would lead to geometric errors, holes, etc. if your density data in the voxel doesn't jive with the node (like how does one node match up to another node if it shares similar density values, but one portion is a bit further in viewing distance, requiring less detail? Each would be in a different LOD plane, would the geometry even mesh together properly?) - someone with more experience would need to chime in here because I'm just taking a guess, sorry.

In my case, I'm going for the "infinite world" approach..though TBH, I'm starting to think "infinite" is unrealistic (at least with my ancient hardware, anyway!) and maybe I should cap my world dimensions - which would get around my predicament. But, at current, what's preventing me from implementing octrees in this case is how to make a "root" node when the dimensions of my world are unknown. Traditional octrees are top-down - you start with a large root node, and keep subdividing until the desired LOD is achieved (and for the stuff out of view, there would just be very large, empty nodes), with the finer details being closer to the camera...in an infinite approach where chunks are calculated and then laid out before the player as they move through the world, would be bottom-up I would think - finer details being generated in the nodes closest to the player / camera, and expanding outward to coarser detail - e.g. a flat plane in the far distance would end up being a single quad or at least very basic - but I haven't been able to dig up much on a "bottom-up" approach.

One thing you might want to look into, instead of octrees (since you're using a spherical world), might be geometry clip maps. I've only read about them over on the procworld blog, but the gist of it seems to be: Clip maps are used directly on the GPU. You use a shader to sample heightmap data and - I believe a "megatexture", which is used by your engine to render texture the different LOD rings (clipmaps are typically toroidal, growing larger like an octree the further away from the camera the geometry is)...I dunno - I probably am getting my wires crossed, but the point is - it may also be worth checking out if you use a heightmap for your density sample values instead of perlin / simplex noise. I've wondered if using clip maps was possible with procedurally generated terrain derived from noise samples - since clip maps work with a heightmap.

Anyway, I'm rambling - I get chatty when I'm tired..oddly. I hope some of the references / links help you out and / or spark some ideas.

Take care,

-O.K.

Edit: added info about geometry clipmaps