Real-time voxel raytracing, in development..

[IJs]

Hey Lee,

Good work on your ray-tracer. It seems (from what I've seen) it's based on some kind of slice-based or heightmap algorithm, something I thought about using before I got access to CUDA.

3D grids for voxel data are extremely big and sparse, and I'm generally not a fan of octrees and related tree structures for GPU applications. The RLE approach is pretty nice actually but can be costly to lookup as well. Anyways, spatial hashes have extremely fast constant lookup times (e.g. hash_map[3D_to_hash(x,y,z)]). The question is whether you can find an implementation that can recalculate the hash maps fast enough.

And as far as empty space skipping is concerned, I use multiple uniform grids at different scales to skip certain fixed distances along the rays.

[Spacerat]

As for octrees, I also would like to add a reference: the siggraph presentation of zelex's work 
His SVO implementation renders a 32k^3 voxel creature @60fps on a GTX280.
http://s08.idav.ucdavis.edu/olick-current-and-next-generation-parallelism-in-games.pdf

@Lee: can you tell what I do wrong ? I think you saw my screenshots. Perhaps the attached log helps.

[theamusementmachine]

Spacerat, I saw your screenshots...but they dont give enough info...look at the help.log, that is your best bet, If you can't get it to work try the chat link on my website....dont waste too much time on it just yet, we are hoping to have things updated some (finally) this weekend with any luck... If all goes well the website will be in 3d after you install The Amusement Machine, and will have a basic development system to write your own gpu raytracing code...all in realtime (without having to leave the exe), in summary look at the help.log and just wait a little longer to run The Amusement Machine.

IJs, thanks very much, it used to use heightmap data and probably still will for terrains, as you can see in one of our videos the terrain even though it is a heightmap need not be non-overlapping, i think the caves video shows what i mean. Hash Maps.... we are working right now on this and I practically guarantee they are the method everyone should be using but why do you need to recalculate them all the time? For dynamic objects? As i said to spacerat above soon you will have a 3d dev environment for GPU raytracing with some of my example code already in it ready to tweak. Right now there is no CUDA in this dev environment but if I go with CUDA then I would have to drop support for ATI/AMD cards? .... I know there is not a good solution there right now.... anyway the code is all in HLSL for now so that is what everyone will get to start.... Thanks to all who viewed and ill post when i update (which will be soon)

Lee

[IJs]

You would need this for dynamic objects.

As far as CUDA is concerned, it is indeed targetted at NVIDIA cards, but it's very powerful. On the other hand, there seems to be some progress on other platforms such as OpenCL or RapidMind (although I stepped away from this at some point due to low performance compared to CUDA). It's a choice you have to make.

[straaljager]

Hi,

I am very interested in the potential of voxel rendering. I have read somewhere that the guy that made the AMD Ruby demo uses geometry maps (or geometry images) to store the voxel data of "Light Stage 5 structured data" which is characters I suppose. Geometry maps seem to be useful for raycasting dynamic objects according to a paper by Carr et al. (Fast GPU Ray Tracing of Dynamic Meshes using Geometry Images, 2006). They're using geometry maps to store triangles instead of voxels, and I think they could get an extra speedup if they were storing voxels for raycasting. I wonder if any of you have tried this method for dynamic objects yet.

IJs, do you think it's possible to use your technology to render a highly detailed GTA-like environment with moving cars, people (and multi-player ) ?

[Spacerat]

Hm.. in my eyes, the raycasting performance of a 512x512 map is really poor. But an adaptive geometrymap rasterizer is something I thought about recently. The algorithm: Rasterize every n'th texel in the map in u/v and then backcheck the rasterized screen-space coordinates whether there is space left in between (by using zbuffer of course). If there is, upsample and rasterize more texels in this area until there is no change in screen-space coordinates anymore. Also necessary for this idea are mipmaps of the original image, tiles (quadtree perhaps) that are loaded dynamically with higher resolution and a boundary map to lead the upsampling process. I think thats superior in speed to raycasting since multiple per-pixel tree-traversals are not required, which is the biggest performance-hit in SIMD raycasting. In case a quadtree-structure for the geometry-map is used, its possible to store lists of each tree level and then simply rasterize all tiles - so there wont be a single tree-traversal during rendering. Also the result will be a smooth surface as hardware accelerated texture filtering can be used. The method also allows to add antialiaing very easy.

The only problem might be the memory consumption in case of a big and detailed model.. its like 3 floats (12*8=96 bit) per coordinate - in a pointerless, binary octree its like 1.x bit / coordinate, so about 100 times more. Perhaps wavelet compression, 16 bit floats etc might be a help there..

[straaljager]

Thanks for the comprehensive answer spacerat. As for the compression, the OTOY guy said he was using wavelet compression in one of the first video's.

[Spacerat]

I think it could also be interesting to use geometry-maps for skeletal animation. In this case, 1 matrix multiplication and 2 matrix blending operations would be required for 3 weights per rasterized pixel. Since the upsampling in screenspace is adaprive, there wont be much overdraw in the ideal case.

[ConsistentCallsign]

The sad little gamer boy, whose parents died in a car crash  :'( :'(, does not have a CUDA-compatible GPU!!

oh well.. CUDA will eventually become obsolete anyway..

[IJs]

I guess this topic more or less slipped my mind. Oops. My apologies. Happy new year by the way.

Anyways, I've updated the dead links in the first post (moved servers again) and added a little more info to my website as well.

I've been scanning through lots of papers on lighting lately and coming up with implementations that could be applied to my renderer. Here is a snapshot that's based on Keller's "Instant Radiosity" technique + something called "Imperfect Shadow Maps" plus some other fancy algorithms in a standard Cornell Box scene:



It basically involves a few photons, Virtual Point Lights, and a lot of voxels. And yes, it's still real-time. Also, before you mention the vagueness of the shadows and colors; I'm a little unsure about how to proceed with blending the different types of lighting together, but I'll probably figure it out.

Now that the lighting is at an adequate level, I guess it would be fair enough to spend some more time on getting the voxels in the scene moving around massively at real-time performance as to make it a little more practical for everyday usage.

[hark]

Beautiful. How's the performance? I'm guessing it's good enough since you're proceeding with more interactive elements.