Much to say about Lighting and Shaders

Published April 12, 2009
Advertisement
I am beginning to finalize the lighting model for Geist3D. With more powerful graphics hardware coming online all the time it is becoming feasible to perform more rendering passes to compute realistic effects such as shadow maps or deferred lighting. For now, I will try to do everything in one pass, but architect for multiple passes in the future. I have been following Ysaneya thread on this topic and it seems that he has already decided to include both shadow mapping and deferred lighting in his engine. I will trust his judgement, and it won't be long until I follow his footsteps in this regard.

As usual, this article is interlaced with a few of the latest screenshots. You can also download an executable here. According to some reports it didn't run on ATI cards, but I think I fixed that now. Soon I will get a 4890 and develop on an ATI platform for a while. That should sort things out.

There is also a download for the editor at the Geist3D site, but it does not contain the latest changes. For anyone interested, all of the shaders are accessible via the GUI, if you can find your way around it. I am hoping that some shader gurus will point out some improvements. There are certainly lots to be had.





At this point, there will be two rendering passes. The object-space pass renders the 3D scene into a series of frame buffers that will contain color, normals, and depth. The screen-space pass will then further process the frame buffers to perform HDR and bloom, depth of field, motion blur and maybe ambient occlusion culling. At first there will definitely be HDR and bloom and I will add the other effects over time. I have already implemented bloom and HDR effects in the past, so it shouldn't be a difficult to add them again. The main problem will be to nicely integrate the screen space shading pipeline with the editor. I always try to build a user interface for all the components in the engine. It is more work, but it will make the tool more versatile. I hope that once (and if) Larrabee takes hold and real time ray tracing comes along, most of this work won't be in vein.

Cleary, there will not be just one lighting model for all object since there are so many different artifacts in the environment. I will therefore break it down by category.

Space ships, Characters and Objects in general
After digging around at gamedev and looking at the odd GDC presentation for the past couple of years, it has pretty much become clear to me that other than triangles and vertex normals, every object should contain diffuse colors, normal maps, a specular component, a displacement component and potentially an occlusion component, or a self-illumination value. All of this information should fit into 2 texture maps with RGBA channels.

Since the lighting calculations are all done in tangent space, it is only necessary to store the x-y components of the normal, since the z component is always positive. The actual normal can then be reconstructed in the pixel shader. So, here is how I would suggest to assign the components of the two textures.

MAP1
R - diffuse X
G - diffuse Y
B - diffuse Z
A - displacement

MAP2
R - normal X
G - normal Y
B - ambient occlusion
A - specular


I know it is a lot to ask of an artist to create these types of textures, but maybe I can write some software to combine different textures and bake them together. I am not quite sure which components can be computed automatically. I think you can create normal maps from diffuse maps, and specular and displacement maps from the normal map. But I am really not certain about that; maybe its time that I actually start learning how to use a modeling tool. The ambient occlusion component is difficult, as the surrounding geometry must be known to compute the self-shadowing of a pixel. I am also considering implementing screen space ambient occlusion culling, once I changed the shaders to collect depth information for each pixels during the object-space rendering pass. So, maybe we can skip the occlusion component and add the Z value of the normal back in. In any case, ambient occlusion adds quite a bit of realism.

For metallic objects like spaceships, I will use anisotropic lighting to add a special metallic look. It is quite simple to implement and adds a nice touch.



Planet
The planet shaders are much more specialized and really do not concern artists much as there is little that can be imported, other than the planet texture packs. All of the other parameters are changed within the confines of the editor. The shaders for the planet are certainly not finalized and I will still improve them as time goes on. But, I do like what I see so far. Here is breakdown of the components making up the planets:

Atmospheric scattering
This is a tough one and requires some pretty heavy shaders. I have a pretty good handle now on the physics involved, but the equations cannot be computed in real time. O'Neils demos and articles certainly help a lot! Yet, there is a lot of fudging that must go on there... This will require more trial and error.

Clouds
For now, there are already Cirrus clouds but I definitely want to implement volumetric clouds which you can fly into as well. This will add quite a bit of realism and make areal battles so much more fun. The shaders for these clouds also need a lot more work and the lighting calculations have to tie in with the atmospheric scattering. Obviously, the cloud color is quite dependent on time of day. Plus, the volumetric clouds will require yet another planet wide LOD scheme, which I assume is different from the one for the terrain patches, the fauna and the collision tree. Here we go, yet another structure...

Water
For some reason water just eludes me. I see so many nice demos on the web, but I haven't been able to properly recreate them yet. Most realistic water demos use environment maps to determine the reflections that come of the water. I think that it would be difficult to create an environment map for a planet if it is possible at all. They would certainly have to be viewpoint dependent and would thus have to be computed on the fly. Right now I am already using atmospheric scattering to determine the reflection color, which has made the water much more realistic than before. I am thinking that once I have added shadow maps, there will be enough information to make realistic reflections. However, I yet still have to get ripples right :)

Trees
I am happy with the trees so far. The shaders certainly need more work, since I haven't paid too much attention to them when I added the trees. I also still have to improve the transition a bit between the geometric trees and the billboards. Plus, I haven't even begun to explore the algorithm that generates the geometry of the trees. Soon I will tie in the parameters with slope, elevation and the global noise function and the there will be different trees in different regions. I will also add grass asap...

Surface
I am happy with texturing the planet surface using the texture packs and slope/elevation blending. It would probably be a good idea to use normal mapping as well here. Also, the surface still pops a lot, especially with low level of detail setting, so geo-mipmapping is in the pipeline. Plus, I am still thinking about a completely procedural planet texturing method, but the GPU performance still isn't there yet.




So, this is basically it. I realized this is not all about lighting but most of it is relevant.
Previous Entry Many different things...
Next Entry Ambient Occlusion
0 likes 0 comments

Comments

Nobody has left a comment. You can be the first!
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement
Advertisement