Monday, April 16, 2007

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.

Sunday, April 8, 2007

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 -" 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...