what are sparse voxel octrees?

Question

I have reading a lot about the potential use of sparse voxel octrees in future graphics engines.

However I have been unable to find technical information on them.

I understand what a voxel is, however I dont know what sparse voxel octrees are or how are they any more efficient than the polygonal techniques in use now.

Could somebody explain or point me to an explanation for this?

Answer 1

A nVidia whitepaper describes it very detailed~ http://www.nvidia.com/object/nvidia_research_pub_018.html

Answer 2

Here's a snippet about id Software on this subject.

id Tech 6 will use a more advanced technique that builds upon the MegaTexture idea and virtualizes both the geometry and the textures to obtain unique geometry down to the equivalent of the texel: the Sparse Voxel Octree (SVO).

It works by raycasting the geometry represented by voxels (instead of triangles) stored in an octree.

The goal being to be able to stream parts of the octree into video memory, going further down along the tree for nearby objects to give them more details, and to use higher level, larger voxels for further objects, which give an automatic level of detail (LOD) system for both geometry and textures at the same time.

Also here's a paper on this.

Found more information in this great blog entry.

Well, voxels alone are not that interesting, because for any reasonably detailed modeled, you would need extremely huge amounts of voxels (if using an uniform grid).

So, a hierarchical system is needed, which brings us to octrees. An octree is a very simple spatial data structure, which subdivides each node into 8 equally large subnodes.

A sparse octree is an octree where most of the nodes are empty, similar to the sparse matrices that you get when discretizing differential equations

Answer 3

an octree has 8 neighbors because if you imagine a square, that was cut into 4 equal quarters like so

______________
|     |      |
|     |      |
|_____|______|
|     |      |
|     |      |
|_____|______|

then it would be a "quad"(four)-tree.

but in 3 dimensions, you have yourself, a cube, rather then a square, so cutting it horizontally, vertically, and along the Z axis, you'll find 8 chunks rather then 4 like so

    _____________
   /     /     / |
  /-----/-----/  |
 /_____/_____/ | |
 |     |     | |/|
 |-----|-----|/| |
 |     |     | |/
 |_____|_____|/

hope that makes since..

what makes the SVO unique, is that it stores Voxel information, which is a point in space, that has properties such as Color, Normal, etc..

the idea behind SVO is to ignore triangles, and the need of textures, by putting them together into a single SVO which contains the Voxelized Triangle Hull(the Model), and its surface textures all in one object.

The reason a Octree is needed here, is that otherwise a uniform grid structure would require far to much memory for existing graphics cards to handle..

so using the SVO allows for a sort of Mip-Mapped 3D Texture..

MipMapping basically is the same image, but at difference scales, one which has more detail, and the latest which has the least detail(but look fairly similar from a distance)

that way near objects can stream from the SVO with greater detail, while further objects stream with less detail.. that is if you're using Ray-Casting.. the further away the ray from the camera, the less we dig into our Mega-Texture/SVO

But, if you think outside the box like "Euclideon" with its "unlimited-detail", you would just use frustum slicing, and plane/aabb intersection, with projected UV of our sliced billboard for finding each texels color on the screen, opposed to Width*Height pixels, shooting out rays, with nvidia's naive "beam optimizations".

PS(sorta off topic): for anyone who doesn't understand how Euclideon does their shi, I believe thats the most practical solution, and I have reason to back it up(that they DO NOT use ray casting)

The biggest mystery they have, isn't rendering, but storing their data.. RLE simply doesn't cut it.. because some volume/voxel data may be more random, and less "solid" where RLE is usless, also compression of which for me typically requires at least 5 bytes into anything less. they say they output roughly half of what is put in) through their compression.. so they're using 2.5 bytes, which is about the same as a Triangle now-adays

Answer 4

actually, the 1.15 bits make me suspect they just store things sequentially, in some brilliantly simple way. that is, if they're only storing the volume data and not things like colour or texture data as well.

think about it like this: 1 voxel only needs to be 1 bit: is it there or is it not there? (to be or not to be, in other words :P). the octree node it's in is made of 8 voxels and a bit to store whether the thing contains anything at all. that's one bit per voxel plus one per 8. 1 + 1/8 = 1,125. add another parent node with 7 siblings and you get 1 + 1/8 + 1/8/8 = 1,140625. suspiciously close to the 1.15 they mentioned. although i'm probably way off, it may give someone some clue.

Answer 5

You can even simply raster all the points, you needent raytrace or raycast these days, since video cards can project obscene amounts of points. You use an octree because its a cube shape, continually dividing making smaller and smaller cubes. (voxels) I have an engine on the way now using a rastered technique and its looking good. For those that say you cant animate voxels I think they really havent thought much about the topic, of course its possible. As I see it, making the world is alot like "infinite 3d-coat" so look up 3d coat and the level design will be very similar to the way this program works. Main draw backs involve streaming speed not being fast enough, the raytracing or rastering not quite making 60 fps, and plotting the actual voxel objects is very computationally expensive, at the moment I can plot a 1024x1024x1024 sphere in about 12 seconds, But all these problems could be remedied, its an exciting future. My maximum world size at the moment is a meg by a meg by a meg, but I actually might make it 8 times bigger than this. Of course the other problem which is actually quite serious is it takes about 100 meg to store a 8192x8192x8192 character even after compression, so an environment will be even more than this. Even though, saying your going to have characters 8192x8192x8192 is completely absurd compared to what we see in games today... an entire world used to be 8192x8192x8192 :)

How you do it by only storing bits per pointer is the pointers are constructed at runtime in video memory... get your mind around that and you could have your own engine. :)