GPU Geometry Clipmaps DX9 1.5 WIP

Here is a new DX9 version of GPU geometry clipmaps.

It uses the new coordinate system from the DX10 version. Terrain is generated on CPU using Perlin's simplex noise & you can stream your own terrain. You can stream anything you need ( normals, textures, etc... ) the same way terrain is streamed.

Unfortunaltly, normal generation on GPU doesn't work yet so i removed it from this version. It is almost finished but i don't have much free time. I hope that i will release a full version before October 2009.

It also contains a few bug fixes.

GPU Geometry Clipmaps DX9 1.5 WIP

GPU Geometry Clipmaps DX10 wip

It has been some months since I wanted to make a new GPUgc using DX10 features. Specially with the new instancing, texture arrays & new formats available. ( leaving geometry shader & instanced tesselation out of the equation until nvidia presentations at coming siggraph ).

One week ago, i started the project from scratch except the MxM & Mx3 blocks generation from the DX9 version. The toroidal update & coordinates system is brand new, much faster, much shorter & support loading from a heightmap or a mathematical functions. Best of all, toroidal update is fully functional (not yet optimized ). Any out of core streaming/compression system can be plug in, i hope.

With all the new features of DX10, new problems appeared. Problems that bring questions, questions that need answers, answers that need to be found :)

GPUgc Dx10 Wip source

GPU Ocean Tessendorf 2001

In 2001, Jerry Tessendorf wrote "Simulating Ocean Water" which describe wave motion in open ocean. Based on statistical model, it simulates a realistic ocean, better than Gresner waves. The inverse FFT is the most CPU-intensive part. The DirectX SDK come with an 1D inverse FFT sample "GPUSpectrogram", since CUDA mapping support in directX10 is still on beta, i tranform the sample to do a 2D inverse FFT. The other parts can be precomputed or done on GPU easily.

Source DX10 : GPU Ocean

GPU Crysis Atmospheric scattering

Previously, i used ONeil atmospheric scattering from GPU Gems II to update a sky texture like Crytek did for Crysis. But they used nishita 93 model ( ONeil's code add optimisations and trade-off speed / flexibility / quality ). A few weeks ago, I made a shader that build this "sky texture" based on nishita93. There is two methods, the first one just compute all nasty integral and the other one use a precomputed texture to speed up thing at the cost of loosing some quality when sun is near horizon.

Source DX10 : Sky2008

left : first method, right : second one


Playing with parameters :

GPU Geometry Clipmaps 1.1

A small release with few improvements and bug fix :

- A update in the Z compression/ decompression process allow an higher Z Scale.

- Fix a bug in normal mapping by adding an offset of 0.5 / NormalSize.

- Support grids up to N = 1023 using 16 bits index.

- Use triangle lists instead of tristrip for Mx3 and MxM blocks for some FPS.

- Vertex buffer storage takes less than 1/12 of previous version.

GPU Geometry Clipmaps Source 10.06.2007

Other C++ version

GPU Geometry Clipmaps v1.1 in progress

I am going to make a game demo and need GPUgc to manage terrain's demo. I notice that there is some bugs in my old version. First, the generation of normal maps that were too sharp. Now, I use another way to find normals and to use them while keeping the same memory usage. I also rewrite the system that let the user control max height and height scale so that it fully support the z encoding/decoding in the shader without artefacts. I plan to rewrite/correct more parts and add a "LoadFromBMP" function. Of course, i will release it once done :).

In the screenshot z goes from 0 to 1023 with a scale of 20.0 -> 20 * 1024 different values.

CryEngine2 atmospheric approach on GPU

I ported their approach on GPU and update is fast ! A 6200 can update a 256x256 map with 64 samples 9-11 times per second. With a temporary texture, you can update small quads but it's so fast that it's useless. Of course, no APG/PCIe bandwith, no cpu needed.

I also tryed to map texture into a full dome where viewer is at Origin. Some work needed to be done on shader to handle this but at last there is artefacts caused by poor tesselation of dome (always 32 rows, 32 cols on screenshots) and the uniform distribution of samples cause by low resolution texture stretching (8x8, 32x32). Problems that do not exist when using original code from O'Neil 's GPU Gems II or with a higher resolution map.

Note : On CryEngine2 they seem to map texture on a low tesselate geodesic dome. I use Oneil optimisations (GPU Gems II) which is much simpler than crytek that uses Nishita with 2D table.