I have been wanting to create a Sparse Voxel Octree in order to do a minecraft style procedural planet with level of detail(blocks at the surface). I saw that PolyVox supports ray casting, and I realized I don't really know how PolyVox voxels are stored. Would it be easy to make a sparse voxel octree structure using PolyVox? As I have to do level of detail using a very large tree. Thanks.

PolyVox does support raycasting, though it's main purpose is picking a rather than rendering. You will probably find it is too slow for rendering as you would need to cast something like 50 million rays per second (well, there are ways to decrease this). The main reason it is too slow is that it does not skip over empty space in the volume and instead traverses every voxel between the start and the finish. It would be possible to modify the raycast to handle this better, but generally I have not seen raycasting-based engines achiving the same performance as rasterization-based engines.

As for the storage, well this depends on exactly which volume class you use. RawVolume stores the data as a single large array, SimpleVolume breaks it into blocks, and LargeVolume includes compression and paging of these blocks. It would be possible to create a new type of volume which stored the data in an Octree.

I see. That makes sense. Well, I am trying to make a little minecraft clone, so I feel like a SVO is probably overkill. My question is, would it be possible to use level of detail using LargeVolume? For instance, as I zoom into a planet, I use perlin noise to generate new volues inbetween the current volumes? I think it'd probably be better to use an octree for this.

Hi,

Yes, you can use an octree for this. I actually have been thinking to do an experiment like this. For an octree, you can probably just use a tree of RawVolumes to render from. Where you fill those RawVolumes is up to you (downsampling a LargeVolume, or direct from a LargeVolume etc.). Just be aware the following is not something practical, just thoughts I have had on this subject.

There are a few problems you'd have to solve with voxel LOD in a blocky world like minecraft.

Aliasing

Just as images have aliasing issues, so would voxel downsampling.

Quick example:

The simplest way to downsample a voxel is to simply march across the volume and skipping every other voxel. Now imagine you have every other voxel as solid, but in between each is an empty voxel. When you downsample, you can skip every voxel, and the whole volume will disappear. Another example is a thin sheet of voxels blocking your view. When you downsample it, you can skip over the entire sheet, resulting in a huge popping effect.

Possible solutions to reduce aliasing are to ignore it (hey, its a 8-bit style game anyhow), or to use "voxel filtering", which would mean adapting one of the many algorithms available for image filtering (each LOD volume can act like a different scale in a mipmap).

Another aliasing related issue, is that image filtering assumes that materials (colors) can be blended/averaged etc., however, with integer materials, you would have to decide how to blend between different materials. So it would be much easier to use colors instead of materials, however this would ruin the ability to easily apply complex textures etc. Furthermore, you might have to consider using *six* (or at least three) colors per voxel, one for each direction, because downsampled voxels represent 6 faces of higher resolution voxels, and should probably blend between them per-face.

Popping
When going from one LOD to another, things will just pop. Especially for a blocky world, lots of shading might change, for example something at a slight angle might have lots of "shadow" areas, but at a lower LOD would be flat.

One solution I have been thinking of is to use geomorphing here, but instead of the normal geomorphing when changing LODs, you can constantly geomorph between the LOD levels (and if you use a proper filtering algorithm, this would be akin to mipmaping, interpolating between two scales). Geomorphing between LODs for blocky voxels would probably be easy and look ... interesting.




I suspect such a world, with blocky filtering and constant geomorphing would be no doubt visually interesting, but I doubt it would have the same feel as Minecraft. The world would probably feel fluid as the terrain would constantly be making tiny shifts.

_________________
irc://irc.freenode.net/#polyvox

Interesting stuff. My logic was to only render minecraft blocks when you are very close to the surface, so at the surface level it would feel like minecraft. However, at the planetary level from space, you could use marching cubes instead of a cubic surface extraction.You would basically be interpreting your voxel data differently at this level. So the planet would look smoothish(not blocky) but at the surface you start rendering using cubes.

edit: I should also mention that I was going to be using perlin noise, and only being generating the 1m minecraft cubes when you see them at surface level. Otherwise, all you need is a seed for your noise, and your planet would only be a couple kilobytes to generate. As you get closer to the planet, you are using perlin noise to add more details to your octree, and THEN at surface level, you start saving data in the tree to a map format, because this is the level players will modify cubes and build things etc. But above that, its all noise generation, which will be the same visually everytime with the same seed.