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.

Shafts of light alias God Rays

How to mix an atmospheric model with "radial blur" to achieve outdoor shafts of light ? Well, draw your dome with your atmospheric shader, write (max(MiePhase) * ShaftsPower) to alpha value of backbuffer. Copy backbuffer's alpha to a smaller render target, use radial blur with projected sun 's position as center even if it's outside screen. Subtract radial blur's alpha from original rendertarget's alpha. Mix rendertarget with backbuffer to illuminate or darken, as you wish.

There is no artefacts when sun is behind viewer because the alpha map is done with the MiePhase function. If ShaftsPower is high enough, backbuffer's alpha values will be 1 even if the sun is behind viewer and it will causes artifacts. Using other functions can give smoother results

like log2( max(MiePhase) * 2500.0f ).

For the screenshots, i used log2( max(MiePhase) * 2500.0f ), 16 samples for radial blur, 256x256 rendertargets and a bloom effect( glow + highlight ). it's not 100% perfect yet.

Navier-Stokes equations

Working on NSE for fluid an cloud simulations based on chapter 38 of GPU Gems II. Really slow on CPU but looks amazing. Support buoyancy and vorticity, currently trying to port it to GPU.

Cry Engine Approach

First : 256x256 RGBA FP16, Second : 8x8 RGBA FP16

After reading Real-Time Atmospheric Effects in Games, i implemented something using the same approach. In the paper, they used a 2D texture to store Mie / Rayleigh in-scattering integral which simplify shader code.

Instead of doing this, i store the Lin(r,g,b) and theta sun in a RGBA16F texture. I do most of ONeil's shader code in the CPU for viewing sky from ground. We still need to get Mie phase & Rayleigh phase function in the PS, but it's much more faster since there is no more loop. A 256x256 texture gives nice results without artifacts thanks to FP16 filtering. And instead of using 5 samples like in the ONeil's shader, we can choose a higher value ( increase CPU time ) which increase quality. The dome need to be highly tesselated if we want to use the theta sun from the texture or we will get a wrong shape of sun. We can also find theta sun in shaders by adding "Out.t1 = vEye - In.pos.xyz" to the vertex shader and "dot(vSunPos, In.t1) /length(In.t1)" to the fragment shader.

We can extend the idea by using a 3D texture for a full day/night cycle or to handle change of sky color when viewer fly and goes up in the atmosphere. I also tryed using a 32x32, 16x16, 8x8, 4x4 texture size. 8x8 is good choice but we can see few gradients when sun move from zenith. I still need to correct dome tessellation and texture creation to avoid this. Updating a 256x256 with 64 samples takes 5+ secs on a sempron 2600+, 8x8 with 64 samples is done in realtime 75fps+(VSync on). A high number of samples provides more accurate results, you will notice a small change if you only use 5 samples. 24 cycles for vertex shader, 8 cycles for fragment shader.

Note : 6200 TC Pci Express & 6200 AGP don't have FP16 filter...

GPU Geometry Clipmaps Source

Now, GPUgc only updates visible levels. When a level that was not rendered last frame is now visible it partially or fully update it.

GPU Geometry Clipmaps Demo 25.03.2007
GPU Geometry Clipmaps Source 25.03.2007

Edit : Updating visible levels only boost FPS during motion at high height. On a low height, there is less update calls but they have more work to do (GPU (synthetize)/ CPU (decompress)), the user might feel some freeze during motion on downmarket CPU/GPU. Updating all levels prevent freezes but it's slower when user is at high height. ( choice is yours ).

Note : if you want to try using normal maps size twice clipmap ones change
"TexNormalSize = TexClipSize * 1;" to "TexNormalSize = TexClipSize * 2;"
In GPUGeometryClipmap(). In ComputeNormals.fx change
"p_uv2 = floor(p_uv2 + 0.5);" to "p_uv2 = floor(p_uv2 + 0.25);".

GPU Raytracing of HyperSphere

First attempt, GPU raytracing of HyperSphere. Got some FPS with a 256x256 window, 32 samples of 2 octaves but quality is much better that aligned quads. Trying to use nice colormaps or HDR cubemaps. Highly pixel unit intensive, number of pixel units on the GPU is clearly the bottleneck (SLi / CrossFire friendly).

GPU Geometry Clipmaps Done

http://www.youtube.com/watch?v=qw-gomauW84

http://www.gamedev.net/community/forums/topic.asp?topic_id=439770

Demo

Finish ! Instead of normal maps size 512, i use 256 because it looks better. i also notice that this technique don't like much pikes ( RidgeMF ) but i think that's the way they compute the average of coarser level with only 2 tex fetch. On other terrains ( Turbulence ) morphing is hardly visible.

GPU Geometry Clipmaps Normals

Normals done on render phase


Normals with normal maps and morphing


I tryed the suggestion of computing normals during the render phase without the help of normals map. Sometimes we can see transition regions because there is no morphing and there is a drop of FPS. In a high speed game this approach could be a good idea. With normals maps and morphing it's looks better but still hard to find a way to update normals maps.

GPU Geometry Clipmaps WIP

i have optimized vertex cache hit of triangle strips and i got a boost of 10 Fps ( + 25 % ). I discovered pixel artefacts in the middle of grids ( not T-Junctions ) and post about it on gamedev for help, http://www.gamedev.net/community/forums/topic.asp?topic_id=437850. Normals update don't work yet, just a matter of time.

Edit : No more T-Junctions and pixel artefacts, those were Mipfilter artefacts. Normals are now correct but i will have to use the last row and column to get correct normals for clipmap n=255. Thinking about a way to manage this.

GPU Geometry Clipmaps WIP

I finish coding instancing, min clipmap level, outer degenerate triangles. I am working on normals but shading is ugly even with twice the resolution of clipmaps. I also saw some pixel problems, may be i don't remove T-junction correctly.






Edit : I correct T-Junctions 's problem and normals but shading seems blured. Not enough resolution i guess.

GPU Geometry Clipmaps WIP

I finished writing frustum culling and cleaned some c++ & shader code. Next step, generate normals on the fly, better terrain texturing, optimize a bit frustum culling and draw the outer degenerate triangles.



Grid Size 255, 8 Levels on a 6200 !

GPU Geometry Clipmaps WIP

I made some progress, now the average of coarser works. I need to rewrite my update function because coordinates system is all messed up.



Edit : i finally finished coding GPU Geometry Clipmaps and it works !!! pfiouh ... Now it's polishing time.

GPU Geometry Clipmaps

I received a new 6200 with SM 3.0 and i just restarted working on my implementation of GPU geometry clipmaps "Terrain Rendering Using GPU-Based GeometryClipmaps". As you can see in the screenshot, i have problems during the update with the coordinates system and the average of the coarser elevation map. There is a lack of information in the paper, the shader code on the GPU gems II and the demo doesn't give explanations of how it works.

Edit : After a few tries, i almost fix it but i still get errors when uv coordinates cross the boundary of the texture.

Aerial perspective

Today, i coded the Aerial perspective given in the ONeil GPU Gems II chapter. It looks quite nice but need some GPU power. That's why i want to use another technique but seems that it's hard to mix different techniques, one for skycolors and another for Aerial perspective.

Realtime rendering of atmosphere scattering

I am going to talk about what i tryed to code in the past few days, SkyColors for a SkyDome. There is some papers about it, seems that there is not as much research on it as terrain rendering.

I started with A. J. Preetham's publications : "A Practical Analytic Model for Daylight" and "Rendering Outdoor Light Scattering in Real Time". I tryed to code the equations given at the end of the second paper but didn't get what i expected. Those equations give a luminance and chromaticity color sample in Yxy Space and need to be converted into RGB space, this is something that is not described in the paper and that the reader must find out.

After a few searches, you can understand this by reading "A Practical Analytic Model for Daylight" and finding "Day light sky color" that explain how to get RGB colors from Yxy Space. So, in the PS you must convert "Lin" and "Fex" values before using them. With that i finally got a blue sky and i played a bit with parameters but didn't got good results.

I gave up Preetham papers and looked for something else... and i found "Real Time Rendering of Atmospheric Scattering Effects for Flight Simulators". At the end of the paper, the autor give the code so i tryed it and got better results for skycolors. The code also has some features like and automatic Henyey Greensein's G value computed with the camera 's Y and the theta angle between sun and it's zenith. I also got some problems : during night the skydome is white and the sun is too big during day, even for a little ESun value. There is also some blanks in the code that i didn't fill : some variables a set in the C++ code that don't exist in the FX effect file, etc ... i didn't found how to contact the author and my post about his paper on gamedev didn't got feedback ( i guess nobody tryed to get it working ). Since i couldn't make it work properly i searched for others technique.

And came up with ONeil optimisations article about "Display of The Earth Taking into Account Atmospheric Scattering" on gamedev. I discovered that ONeil had written a article on Atmospheric Scattering for Gpu Gems II book, so i download the source of the chapter 16 on NVIDIA website. I convert his CG SkyFromAtmosphere shader and tryed it, but like many others people only the top of the dome had skycolors. After a few looks in his code i found that he used a special ModelMatrix that set the camera at origin, with the Y value equal to the InnerRadius and subtract camera's position from translation values of others objects ModelMatrix. At last, i finally got something realist and nice to watch.

Even if his method give pretty good results i didn't stop searching and also found "Real-Time Atmospheric Effects in Games" that decribe how they have done the atmopshere scattering and haze effect in the CryEngine2 that seems quite easy to implement and costless but that need SM 3.0 graphic card because it uses FP32 textures.