Jump to content

  • Log In with Google      Sign In   
  • Create Account


What to do with a voxel ray-caster


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 Tom Mulgrew   Members   -  Reputation: 194

Like
4Likes
Like

Posted 14 March 2014 - 03:16 AM

SVO Terrain 2

I'm keen to hear if anyone has ideas what I should do with my project.

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

http://youtu.be/ca7xcP3-c18

 

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



Sponsor:

#2 Krypt0n   Crossbones+   -  Reputation: 2505

Like
6Likes
Like

Posted 14 March 2014 - 08:10 AM

I think your limitations already guide to the next steps



#3 Tom Mulgrew   Members   -  Reputation: 194

Like
0Likes
Like

Posted 14 March 2014 - 07:24 PM

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.



#4 Hodgman   Moderators   -  Reputation: 29546

Like
1Likes
Like

Posted 14 March 2014 - 07:51 PM

For a CPU version,I find ispc to be a great language for graphics stuff, as it lets you easily take advantage of SSE/AVX/etc happy.png

 

To get wider usage, you'd either need a fast CPU version, or alternatively a HLSL (compute shader) and/or OpenCL version (more game developers use HLSL than OpenCL, but in other industries, architectural visualization, etc, it might be the opposite).

You could potentially start an open-source project and see if you can find other interested people to help with these ports.

Alternatively, if you do the ports yourself (and some optimization work), you could end up with a potential middleware product.

 

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 biggrin.png

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.



#5 Buckeye   Crossbones+   -  Reputation: 4447

Like
2Likes
Like

Posted 14 March 2014 - 08:14 PM

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.


Edited by Buckeye, 14 March 2014 - 08:17 PM.

Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.


#6 Tom Mulgrew   Members   -  Reputation: 194

Like
1Likes
Like

Posted 14 March 2014 - 09:24 PM

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.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS