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

3 comments:

Dragon89 said...

Hey

Some source would be nice on this one...

Dragon89 said...

just a thought.. but wouldnt it be a speed up if you rendered the sky to a cube and then rendered it as a skybox in run time? since the sky is assumed to be infinitively far away this shouldnt affect the end result... then u would only update the skybox when the sun is moving... this would be very few updates(if any at all) since the sun moves relatively slow...

all u have to do then in real time is the aerial perspective rendering on the terrain...

FilouGK said...

Yup, faster as a cubemap, no shader needed. Debugging purpose kept me away from doing it, still in dev.