[sharedmedia=gallery:images:4917]

It's a CUDA ray-caster into a sparse voxel octree data structure, which runs at about 60fps at 1024x768.

So far it's just been a personal research project.

It's not really feasible to put this into a game, due to the size of the voxel data (20Gig on disk) and the fact that it's limited to CUDA capable graphics cards. And 1024x768 is a pretty small resolution these days (or 20fps at 1920x1080 is pretty choppy - take your pick).

My current ideas are:

• Add some trees, foliage, buildings, bridges etc, etc
• Figure out the Morrowind map format and convert it to voxels
• Experiment with a polygon/voxel hybrid renderer (polygons for close up content, voxels for distant)
• Some half-baked, grandiose plan for a voxel server and ray-casting browser

-Tom

Thanks for those links. The second one in particular looks very interesting (I'm currently using about 10 bits/voxel for colour data, so there's room for improvement).

I don't think it would work in a GLSL shader mainly because of the need to traverse several 100 MBs of voxel data. But OpenCL could be workable.

I also have a 32-bit CPU version that runs about 20-40% of the GPU one. It's hampered by having not quite enough available registers to store the ray traversal state, so I'm curious how a 64-bit version would do.

What kind of tools do you have for importing content? Do you have some kind of pipeline for pre-converting polygonal data into voxel data?

I just made a game for a game-jam using ray-marching in a pixel shader, which is quite slow, so I decided to go with an early 90's graphics style and present the game in 320 x 200 pixels
Indie game fans seem to love retro graphics, so if you want to make a game with your renderer maybe you could go that direction, where the performance of your ray-caster would be adequate.

That's an impressive game jam entry btw. Would be perfect for a GCW-Zero. Was that really done in just 2 days?

I use a software rasterizer to convert textured triangles into voxels by projecting them orthogonally. The X & Y pixel indices become the X & Y coordinates. The Z buffer (or what would be written to the Z buffer) is the Z. I find that projecting it 3 times (once along each axis) ensures there are no holes, although it does create a few more voxels than are strictly necessary.

I'd love to get it to the point where it could be viable middleware, but it comes down to whether I can squeeze the necessary performance out of it. Right now it needs at least a factor of 2.5. From the 2010 nVidia paper krypt0n linked to it looks like this should be technically possible (they claimed they could do 60Mrays on 2010 hardware).

You may find the U. S. Geological Survey site of interest (National Elevation Dataset). Elevation data can be downloaded in several formats, some are simple ASCII. Some areas of the country have resolutions down to 3(?) meter grid size ( whatever 1/9 arc-second comes out to be ). I don't know what resolution you're using now. For my flight simulator, I have data for several US states, preprocessed into single precision floating-point, and the data size is in 100s of MB, not 10s of GB. Finer data can be calculated interpolating either linearly or higher order.

I'm using a 64K x 64K map. But every entry is a voxel so there's no obvious means of interpolation and the voxels need to be smaller than meters to look reasonable close up.

To be honest a heightmap based terrain is not the best for showcasing the strength of a voxel engine. A dense forest or city-scape would be better. But it's more work to create this kind of content than grabbing an off the shelf heightmap generator.

Having said that, it would be interesting to throw some real-world elevation data at it and see what the results look like. I'll definitely look into it.

The voxel approach isn't really suited to huge areas imo, unless you're okay with very coarse voxels.

It behaves a lot like a mega-texture in that you store a separate color for every point, so the feasibility of a large voxel world comes down to your ability to compress this data. There are lots of (flat) image compression algorithms that megatextures can draw on, but for point clouds they're fewer and harder to find.

I could probably put some work into compressing them on disk though. Currently they're stored in a format that allows a chunk of voxels to be read straight from disk into GPU memory without any conversion. This is great for implementing a fast LOD algorithm, but doesn't lead to the most compact representation on disk.