Voxel Engine Development using NVIDIA CUDA

Procedural Geometry Maps & Tessellation Shaders

2012-01-19T07:30:00.000-08:00

In this sample, terrains and objects are created using procedural geometry maps as input for the tessellation shader. For windows in procedural buildings, hole generation is supported.

Features

• Geometry-Map based Procedural Geometry
• Dynamic Tesselation via Tesselation Shaders
• Procedural Holes / Extrusions

Performance

~ 48 FPS @ 1024x768 (no object culling)
~ 140 FPS @ 1024x768 (with object culling)
Used Hardware: Nvidia 560 Ti

General Scene

With carved holes Wireframe

Tessellation Shader Sample

2011-09-24T14:37:00.000-07:00

To make it easier to start with Tessellation Shaders, here a GL4.0 example. (VS9,C++).

The file can be downloaded from here:

http://forums.nvidia.com/index.php?showtopic=210979

Update: a first performance benchmark gives around 266 Million Polygons/second using tesselation, which is slower than using a common VBO or OpenGL DisplayList (400 MPoly/s). However, its more flexible, so geometry can be rendered much more efficient.

Voxel Sculpting test

2011-06-14T16:19:00.000-07:00

Here a first test of using voxel sculpting with COAT3D, created in just few hours.

Sculpting is done in Coat3D, the lightmap is rendered in Blender. The models polygon count is reduced using MeshLab.

The UV map is not ideal in this case since its created in LithUnwrap. Using the unwrap function of Coat3D creates a seamless UV map.

Raycasting Procedural Height-map based Geometry

2011-03-04T07:27:00.000-08:00

This one is a trial to use multiple textures for defining a complex procedural 3D object. The basic idea is similar to True Impostors (link) - however with multiple maps to allow complex 3D objects. The screenshot below shows the rendering result of a biologic plant-like structure. The raycasting not optimized, but the results are promising. To render one bean, only a cube needs to be rendered - which means that its possible to render raycasted forests as well. As the geometry is procedural, also animation can be applied - as long as the animated part doesnt leave its bounding box.

Demo download: link

In the demo, the raycasting is not optimized yet which means artifacts near thin features can be observed. For the ones of you adept with shaders - shader source is included, so you can play around.

Screen Space Displacement Mapping

2011-03-04T07:15:00.000-08:00

The demo is an experiment to combine terrain raycasting of perlin noise generated terrain with screen space ambient occlusions (SSAO) and screen space displacement mapping (SSDM).

The terrain is generated at the beginning of the demo as a 1024x256x1024 sized perlin noise volume data in CUDA, which is raycasted in the demo using distance functions for acceleration. To improve the quality, third-order texture filtering and hitpoint refinement using binary search are included.

After the first hit is found, the screen-space normal vector is computed for shading and for the SSDM. The SSDM is not achieved using a stack of textures as this leads to problems in case of overlapping areas for large displacements. Instead, the SSDM is achieved in a post-process using a high-resolution triangle mesh with two triangles per pixel. That is the reason why sometimes articafts near the screen-boundary can be observed.

The ones of you adept in CG may play around with the shader thats included.

Here the link to the Demo (needs an NVidia card as it uses CUDA):
Link1: Filefront
Link2: 2Shared

(Edit) Note: As the program generates the terrain as a 256MB PBO that is copied to the final texture, at least 768MB of GPU memory are recommended.

I've posted this already on Gamedev (link) a while ago, but to update the Blog as well, here it is.

Perlin Noise Terrain Raycasting

2009-11-26T08:58:00.000-08:00

Here a first trial to raycast perlin noise on the fly for achieving volumetric terrain rendering. In the demo, a 128^3 sized random volume data is used as a base for the scenes on the screenshots above.

By optimizing the empty-space skipping, it is possible to raycast reasonably large outdoor scenes at interactive framerates (20-40 fps) on a Nvidia GTX 260 GPU. The advantage of this kind of landscapes is, that they are extremely easy to handle and also that they are very memory friendly ( its just 128^3 rgba voxels = 8 MB of data ). Also can the performance easily adjusted for older graphics cards depending on the empty-space skipping configuration.

The Demo can be downloaded here: Perlin_Noise_Raycasting.zip Controls are w,s,a,d.

SVO-Voxel-Raycasting

2009-11-14T01:53:00.001-08:00

Here some demos of my new sparse-voxel-octree (SVO) rayster.

Technical details:

-Storage: ca. 100 bit/voxel

-Stack-based

-Uses a variant of persistent threads

Demo download: SVO-Demo-Cuda.2.3.7z

Tile-based memory layout

2009-06-22T23:50:00.000-07:00

After long time now another update. Next logical step in the development is to add a tile-based memory layout to allow large, unique, non-repeating landscapes. Here a first screenshot showing the tiles.

Video

2009-03-30T07:03:00.000-07:00

For the ones of you who cannot run the demo for some reason, I just captured a short video of it. You can watch it below in the window or download the larger version with better quality to see more details.

Landscape AVI [mirror]

CUDA optimizations II

2009-03-28T10:02:00.001-07:00

Today I would like to share a couple of interesting references about optimizing CUDA. There are many similariries among these presentations, but still its interesting as reading through give you new ideas about whats possible.

1.) Optimization Techniques for Large Data Structures on CUDA
2.) AstroGPU - CUDA Optimization Part I
3.) AstroGPU - CUDA Optimization Part II
4.) CUDA Programming Notes
5.) NVISION08: Advanced CUDA: Optimizing to Get 20x Performance
6.) Top 5 Optimization Strategies for CUDA
7.) CUDA at MIT - IAP2009

Looking at foil 3 of the first presentation, using the GPU should give an average speedup of factor 10 compared to the CPU in case the algorithm can be fully SIMD parallized. ( GPU: GTX280, 933GFlops/141.7 GB/s Mem, CPU: Intel Core 2 QX9650, 96 GFlops/12.8 GB/s Mem).

Now looking at NVidias CUDA page, I am often surprised to see that some algorithms seem to have been sped up like 100x or even more, compared to CPU - this seems to be rather hard to believe, taking the numbers above into account.

New Benchmark Version

2009-03-23T10:17:00.000-07:00

Today I ported the CUDA version to CPU (multicore), it is included in the updated Demo

[-Download-] (CUDA 2.1 Required - Driver version 181.20 or newer )

The first results so far are:

CPU (3Ghz PentiumD) - Single/Repeated/Repeated 2xAA: 3/1.2/0.6 fps
CPU (Intel Core2 Quad Q6600, 4x 3Ghz) - Single/Repeated/Repeated 2xAA: 15/8/5 fps
GPU (8800GTS) - Single/Repeated/Repeated 2xAA: 33/24/17 fps
GPU (285GTX) - Single/Repeated/Repeated 2xAA: 44/34/36 fps

Scene is this time the complex version of the one shown in the pictures below
(spherescape_complex.rle4).

Reason for the low CPU performance is mostly due many floating point operations I guess. Changing the calculations to Integer might improve the speed. Now its the most possible fair comparison however, since CPU and GPU get the same c++ code to execute.

CPU vs. GPU

2009-03-19T07:18:00.000-07:00

Today I made a comparison of CPU vs. GPU, to see if it was really worth the work to write everything in CUDA rather than for CPU. [detaild pics] [-CPU-Demo-]

The oponents:
CPU: 3.0 Ghz Pentium D, 1GB vs.
GPU: NVidia GTX285, 1GB

In the first round the CPU seems to provide a good performance, compared to the GPU - the GPU is just 3x faster than the CPU.

In the second round however, the GPU already wins over CPU with a speed factor of 7.3 : 1.

In the third round the CPU now lost all ground and the GPU wins about 20:1 (47.5:2.4)

Finally it would be interesting to know why the GPU doesnt work linear at all. I dont have any idea why the framerate is not half if the computations are doubled or vice versa.

Demo with 2x AA

2009-03-18T10:43:00.001-07:00

Small update - the demo linked below now also includes 2xAA (not 2x2!), reducing the aliasing of distant pixels significantly. On the GTS 8800 its quite slow right now, but on the GTX285 its almost no difference to the normal version I found.
For the GTS perhaps I will think about only applying AA to distant geometry to increase the speed.

Now the algorithm works entirely on the GPU

2009-03-17T09:18:00.000-07:00

Today I finished shifting the ray generation part to the GPU, saving another 1-4ms as well as an unnecessary memcopy. Also silhouette-smoothing is working well, together with basic anti-aliasing ( so far only for GTX2xx cards ).

As for the smoothing, I tried two variants (left), and found the one in the middle looks best so far. The unsmoothed original (top) is too edgy and the one on the bottom smoothens too much for the tree-scene which lets near rendered geometry look like a 2D impostor.

The updated demo is here [-download-] (Cuda 2.1)
Also containing softening for the buddha & dragon scenes now

For the experienced ones of you, the shader-folder contains the shader in GLSL (soft.frag). You can experiment a bit by modifying the smoothing.

Silhouette Smoothing

2009-03-15T00:31:00.001-07:00

Today I experimented with a new shader to smoothen the silhouette based on the depth buffer. Looks not bad but its difficult to figure out the optimal parameters.

Soft Voxels II

2009-03-14T11:41:00.001-07:00

Today I improved the filtering a bit. The softening looks more nice than yesterday (also its slower a litte). [-dl-new shaders-]

Still I'm not yet sure if soft voxels look better than hard-edged voxels in general. It gives the impression of missing detail and low resolution - both things which are unwanted..

Better would be real filtering to approximate the surface.

Soft Voxels

2009-03-13T12:04:00.001-07:00

Today I added depth of field to soften the edgy voxels a littelbit. Its very simple - the smoothing radius just depends on the actual depth.

New Release

2009-03-12T11:24:00.001-07:00

Today its time for a new release. Major mapping bugs are fixed and the colors look better now (I hope).

[-Demo Version v2-] ( Cuda 2.1 )

I also posted the Demo as IOTD on GDev as I think its worth to see.
[-link-]

Happy Buddha reloaded

2009-03-10T22:53:00.000-07:00

This time with shading - looks more nice.
From far its not possible to see if its polygons or voxels - only a closeup reveals what our buddha is made of.

Any limit?

2009-03-10T03:22:00.003-07:00

View distance set to 4.000.000 - still interactive (18fps). To have unique voxels everywhere is a problem in this case however.

Here we can also see an advantage of the RLE structure - its very easy to generate procedural mountains. With octree-raycasting it might be possible too, but right now I dont have an idea how this could work easily.

Anti-Aliasing

2009-03-09T04:22:00.000-07:00

Here we can see the 4 variants of Anti-aliasing. For the quality, also the distance where the next mipmap is switched to is very important.

Maximal complexity ?

2009-03-06T23:24:00.000-08:00

Here another very complex scene.
RLE Elements total :15.4M
RLE Elements processed:5.8M
RLE Elements rendered:1M
Visible Pixels:0.66M

Better Performance

2009-03-05T09:42:00.001-08:00

Today I wrote a converter for PLY.files. The first result can be seen on the left.

After several optimizations, also the framerate could be increased in average about 10% and depending on the scene of up to 50%.

Voxelstein

2009-02-28T01:04:00.001-08:00

Here a scene from Voxelstein
Surprisingly, the rendering is very quick :-)

Download Demo (Cuda 1.1)

It's an alphaversion,
so not expect anything ;-)

First Color for the new Version

2009-02-27T04:23:00.001-08:00

Today the scene gots a bit more colored.

Benchmarks so far:
1024x1024, 1024 rays : 40ms / 25 fps avg.
1024x768 , 1024 rays : 39ms / 25 fps avg.
1024x768 , 512 rays : 36ms / 27 fps avg.
1024x768 , 256 rays : 36ms / 27 fps avg.
512x512 , 512 rays : 21ms / 47 fps avg.
512x512 , 256 rays : 21ms / 47 fps avg.
512x512 , 128 rays : 21ms / 47 fps avg.

So far I couldnt figure out why less rays not increase the framerate significantly - the computation cost proportional to the number of rays.

Texture-mapping Works !

2009-02-26T10:19:00.000-08:00

Here an actual screenshot
25 fps@1024x768 :-)
View distance: 40.000 voxels
(with mip-mapping)

New Download

2009-02-25T10:51:00.000-08:00

Here you can download the Demos below.
Its still the old version, so rendering at 1024x768 is not fast yet.

Required: Cuda 1.1
Filesize: 22MB

VoxelDemos.zip

Progress

2009-02-24T03:33:00.001-08:00

Mapping seems to work now - next step is to compute the rays accurately.

Performance

2009-02-19T22:34:00.001-08:00

Today I measured the performance of the actual implementation. The result: The scene on the right has about 8.0M RLE elements in the view frustum, out of which 4.7M are not culled and 280k are visible, rendered as 450k pixels. This, at a frame-rate of about 25 means the renderer processes about 117M RLE elements/second.

My graphic cards maximum untextured triangle performance is 280M/s in case the triangles share vertices, and about 133M/s in case the triangles have independent vertices. Maximal vertex transform rate is about 400M/s.

This means, if the landscape would be visualized using splats, each rendered as single triangle, then at least 8M triangles would be required. Without any culling, this would lead to a performance of about 133/8=16 fps. Here, perhaps the geometry shader might be used to accelerate the rendering. It would be possible to send only one vertex from which the geometry shader generates a quad or triangle.

I case we would visualize each voxel inside the landscape using conventional polygons, we would have to use at least 2 triangles for each to create a quad. This means, taking shared vertices into account, We would have to render at least 16M quads, resulting in a theorethic frame rate of 280/16=17.5.

Common technologies to render Voxels

2009-02-19T20:52:00.000-08:00

1.) Heightmap based Voxel-Terrain. Ref

2.) Voxlap Technology. Ref1 Ref2

3.) Splatting / Rendering voxels as sprites. Ref1 Ref2

4.) Sparse Voxel Octree (SVO) Raycasting. Ref

5.) Mixed Octree / Regular Grid Raycasting. Ref

6.) Mixed Polygon / Voxel (Splatting) rendering Ref

7.) Rendering Voxels as Polygons.Ref

2009-02-13T23:54:00.000-08:00

Its more difficult than one could expect.. Simple texture mapping can't do the job actually. This means, a pixel-shader is necessary to do the unwrapping.

Still some work

2009-02-13T09:05:00.000-08:00

Until the new version is complete, its necessary to stretch out the temporary rendered buffer correctly using texture mapping.. Left we can see the debug output so far.

Cuda output right now is 32 bit. 16 bit depth, 8 bit color + 8 bit normal.

More Speed

2009-02-12T18:50:00.000-08:00

After adjusting a couple of parameters and doing further opimizations I got get 20 fps at 1024x768 now. Update: after some more optimizations, 30 fps seem possible at 1024x768 :-)

Bunny Dataset

2009-02-11T23:39:00.000-08:00

The Bunny dataset has a very complex surface and runs only at about 7-8 fps (1024x768)

Today: The Bonsai Tree Dataset

2009-02-11T20:50:00.000-08:00

Today I played a bit with the bonsai dataset from here.The number of visible trees is about 3000.

Tips for CUDA programming

2009-02-11T05:44:00.000-08:00

If some of you think of writing a CUDA program, here a couple of things to keep in mind:

1.) Reduce the number of used registers to run more parallel threads
2.) Reduce the number of memory accesses
3.) Store runtime variables in registers
4.) Do not use local arrays in your code like int a[3]={1,2,3} - better use variables such as a0=1;a1=.. etc if possible.
5.) Write small kernels. If you have one large Kernel, try to split it up into multiple small ones - it might be faster due to less used registers.
6.) Use textures to store your data where possible. Texture reads are cached - global memory reads aren't.
7.) Conditional jumps should branch equal for all threads
8.) Avoid loops which are run only by a minority of threads while the others are idle
9.) Use fast math routines where possible
10.) A complex calculation often is faster than a large lookup table
11.) Writing your own cache manager that uses shared memory for caching might not be an advantage
12.) Try to avoid multiple threads accessing the same memory element (accesses get serialized - also for shared mem)
13.) Try coalescence of global memory accesses.
14.) Try to avoid bank conflicts for reading memory
15.) Small lookup tables can be stored in shared mem
16.) Experiment with the number of parallel threads to find the optimum. In case you run out of registers, use --maxrregcount=...

17.) If you can implement you method using GLSL, it might be faster than CUDA. In GLSL you get a lot of calculations for free like alpha blending, fog, z buffer testing, interpolation of variables between pixels and perhaps a better thread handling too. Also you not have to copy around the rendered image as PBO and you'll save development time since there is no bluescreen from a bad pointer.

First Colorful Screenshots

2009-02-04T23:27:00.000-08:00

Here the first colorful result of what voxel can do when used with a simple L-System.

I tried to add the culling feature, which is used in Voxlap, but unfortunately it didnt give any speedup wth CUDA.. So back to the previous version.

For the demo, Cuda 1.1 is required.

[ Download Link ( ca.10 MB ) ]