lhyanor.org

Since modern graphics hardware is able to render to multiple targets, the rendering process can be splitted into more than one pass. Deferre d shading is a name for the idea to split the rendering process into 2 (or more) passes.

A first pass is needed for the pixelwise calculation of the geometry, where all the information to shade the geometry is calculated and stored into buffers  (render targets) on a per pixel level (normals, positions, unlit texture color, et cetera).

The actual shading is done in a second pass (or more, one for each light source in the scene), where the buffers can be read and the shading from each light source be calculated from them.

This way, it is possible to separate the material properties completely from the properties of the light, and account for them in different rendering passes. This reduces shader complexity, since if we want to add another light source type, we just have to write another lighting shader, and dont have to touch the material shaders.

These shaders were authored in AMD Rendermonkey, which I used to get a first hold on HLSL. The Rendermonkey project file is available for download here.

Shadow Mapping is a simple technique to archive dynamic shadows in realtime rendering. The idea is to render a geometry that will possibly occlude itself or another geometry in a first pass from the viewpoint of the light source. The vertex shader has to transform the vertices into light-projection space and the pixel shader has to store the z-value of the projected fragments into a depth buffer.

In the following real rendering pass, each fragment's coordinates are again transformed into the shadow map space, and their depth values are compared. To avoid artefacts, there has to be an adjustable bias that avoids self shadowing of lit fragments.

This way, the decision if a certain fragment is lit by the light source reduces to one simple branch:

if ((shadowPos.z / zMax - zBias) > tex2D(ShadowMap, hom_to_texcoords(shadowPos)).r) lit = false;

If the fragment is lit, we draw the lambertian term, otherwise, only ambient light is rendered.

Normal Mapping is a bump mapping technique where the derivation of the (per pixel) surface normal) to the per vertex or per triangle normal is encoded into the rgb channels of a texture. This is often called DOT3 bump mapping.

To calculate the correct displacement in tangent space, the shader has to be supplied with a basis that spans the tangent space.

A common basis are the normal vector, the tangent vector and the binormal vector at each surface vertex point. The normal vector and the tangent vector has to be calculated before rendering and has to be supplied to the shader. The binormal vector can be calculated via a cross product of the normal and the tangent vector.

A vertex structure that holds the information needed for the vertex shader could look like this:

struct vsInput { float4 Position : POSITION0; float3 Normal : NORMAL0; float3 Tangent: TANGENT; float2 texCoords : TEXCOORD0; };

where texCoords denotes the texture coordinates to look up the texture and the normal map.

Recently, I've been working on a loader for the md5 format that is used in id Software's Doom 3 ego shooter.

A good starting point for understanding the format specification was this, although the implementation given there is not complete.

The md5mesh format contains a bone model given by a tree of joints, where each joints position and orientation is given relative to its parent. Th e vertex positions have to be constructed from the contributions of weights, that are assigned to these joints (and their coordinates relative to them).

The md5anim format contains keyframes of the skeleton animation, and the bone model can be constructed by interpolation between keyframes at each point in time.

My loader offers all these functionality now, although the rendering is limited to simple shading using the OpenGL fixed function pipeline and simple texture mapping. (Sorry, no normal maps yet :( )