I was going to post something about your thoughts are on a possible alternative to rendering voxel (while still using PolyVox for data organization) using hierarchical based ray / voxel intersection on the GPU. Well, actually, I only thought about how it may apply to cube voxel world; I'm not sure what the implications are for smooth terrain.

Basically this paper (http://www.rendering.ovgu.de/rendering_ ... oxelGI.pdf) describes a voxel based GI method. But I think one could use this also for rendering voxel based world (cube worlds). Their voxelization technique is not really needed here because my world is already voxelized. However, this technique makes a "binary" voxel representation of a 3d world by using only one bit to represent depth (actually I thought about doing this exactly I just haven't gotten around to it). So in my case, instead of extracting surface, I would just construct this 2D binary voxel map (through bitmasking). All that is invovled for each voxel are some bit operations so it ought to be fast.

Once you have the 2d "binary" voxel. You just ray cast it in the pixel shader. One quick way is to render 512 * 3 quads then "sample" the 2d "binary" voxel texture using a fast ray / voxel intersecting technique, but all you have to do is check this one depth value at a point, you don't even have to ray cast (not 100% sure about this), and it is fast because checking depth against this "binary" texture involves only bit operations. Or maybe just render a fullscreen quad and ray cast.

The advantages of this are that is done on the GPU. You can do ambient occlusion. The "binary" voxel texture construction may be faster than extracting the mesh. AND LOD. With a ray cast method you may get LOD for free because it's a ray casting method.

I split this topic off from the streaming volume stuff, hope you don't mind.

I haven't read the paper (just skimmed over the pictures) but I did think about using binary voxels on the GPU when doing the ambient occlusion work. What I'm currently doing is upload the final AO values and just sampling them, but an alternative is to upload binary voxels and then cast rays in the fragment shader to calculate the AO. This is a lot less work on the CPU, and the AO calcualtion is pretty slow at the moment so it could be beneficial.

It might also make sense to do shadows using the same data, which could allow pixel perfect (and sharp) shadows without needing shadow maps. Great for point lights in particular.

The way I was imagining there would be no material information, so I wouldn't use it for full GI. Maybe they've addressed that in the paper though.