Here's the doomguy with a modified head in a cut scene.  

Your own head in Doom 3

Here's something amusing to try: putting your own head on the Doom guy. Extract the file playerhead.tga from pak002.pak. Take some digital pictures of your own head (or someone else's), straight from the front looking into the camera and from the side. Make sure you have good lighting, it's best if there are no shadows.

Now using these photographs, create a texture map that is aligned with the playerhead texture. Make sure the eye, mouth and ear are at the right place. In Photoshop, the liquefy tool comes in very handy here and you can use the original texture as a semi-transparent layer for guidance. Of course, that's going to distort your features. Hopefully your head shape is not too dissimilar from the doom guy. Use the clone tool and smudge tool to fill in the gaps.

Now extract playerhead.dds from pak001.pak and paste your new texture in there. The DDS format supports mipmapping by including smaller versions of the image to use at greater viewing distances. The smaller textures also need to be replaced.

Then put the modified playerhead.dds into pak001.pak. You may want to make a backup first. Extracting and inserting is perhaps easier if you temporarily rename the pak file to zip while you're doing this. You may also want to replace the playerhead.tga in pak002.pak, I think that's only used in ultra quality mode.

If you start the a new game you should be able to see your own head in the mirror in the bathroom near the kitchen and also in the cutscenes.

Scary head 

Got Normal Mapping working...

Writing and debugging GLSL programs is a lot harder than you might expect. A typical vertex or fragment program is only perhaps 10 or 20 lines, but it took me ages to get my normal mapping shader working correctly.

The C-like syntax is of course easy and the new keywords aren't that difficult to understand either. One thing that you need to be very aware of, though, is to keep track of which variables are in which space. Variables can be in object space (=modelling space), world space, eye space, clipping space and, when you're doing tangent-space Normal mapping, tangent-space (= surface space). For my normal mapper I needed the light position, eye position and vertex position in model space and then converted these to tangent-space via a TBN matrix.

And of course it's hard to debug these little programs. You can't step through them in a debugger and you can't insert printf statements, because they're all executed on the GPU. Here's a debugging tip: it's sometimes useful to output intermediate values via gl_FragColor. For example, the incoming texture maps to make sure you're passing the correct textures. Or the light vector to tell whether it's pointing to the light (and that it stays pointing to the light when your viewing angle changes).

But anyway, I've got the normal mapping working now for Doom 3 models. The texture with "_local" extension is used as the normal map and the "_d" texture is used as diffuse map.
Adding the specular map ("_s" extension) was a piece of cake.

Here is a shot of pinky which highlights the added detail that is not in the mesh itself.


Pinky under red specular lighting

GLSL support

I've been holding off vertex and pixel shader support for a long time. I had already added materials, such as used in Quake 3. These allow for texture blending, alpha testing, animated textures and lots of tricks. But the technology du jour must surely be pixel shaders. And for a lot of cool effects, pixel shaders (a.k.a. fragment shaders) are the way to go.

There are quite a few competing technologies for this at the moment: Cg, ATI's ARB extensions, HLSL, GLSL and some more. No doubt, a few of these will be disappearing soon. I don't have experience with any of them, but GLSL looked the most attractive to me at this point. It's vendor independent, it's very similar to C rather than to assembly and it's directed at OpenGL. In fact, it has been officially included in the OpenGL 2.0 standard, just a few days ago I believe.

Incorporating GLSL into an existing engine has been remarkably easy. I can now run GLSL sample shaders after two evenings of coding. The tutorials and code at clockworkcoders.com has been very useful. Both for understanding how to write (simple) shaders and providing samples as for demonstrating what (C++) code you need to make this work. (Beware though for a terminology mixup in the code with regard to GLSL terminology: program objects are modeled by a class called ShaderObject and shader objects are called ShaderProgram). There are some good resources at ATI, Nvidia and 3dlabs.

From an engine user standpoint the shaders appear as an extension of the existing (Quake 3 like) materials technology. Some new keywords were introduced which you can use in a material definition to load vertex and pixels shaders and set uniform variables. ("Uniform" variables, in GLSL jargon, are parameters that are passed from the application to the vertex or fragment shader. Another type, "varying" variables, are passed from the vertex shader to the fragment shader. Another type, "attributes", are passed from application to vertex shader per vertex)

I've now got a demo running with shaded teapots using all the shaders from the tutorials at clockworkcoders.com except the multi-textured one (tut 8). Adding multi-texturing shouldn't be so hard. More challenging will be to add attributes, i.e. extra values which are passed for each vertex. Specifically to do it in such a way you won't need to change the engine when you want a new effect. Yet for Normal mapping, we'll be needing this feature because the application will need to provide a tangent (and perhaps a binormal) per vertex.

Doom 3 models

This is an exciting point in the development of GUTS, my home-brew game engine.

Last week, I added support for the animated models in the Doom 3 file format (md5mesh and md5anim). I got most of the information I needed from the forums at doom3world.org and from looking at the files themselves. They're fairly similar to the Milkshape ascii format, which was already supported. I can now load the meshes and the animations, you don't even need to extract them from the .pk4 file. The addlibrary command can be used to add a zipped archives (which is what pk4 files are, just like the pak files in Quake) to the search path. I've added a short overview of the technology and a demo for download to the website.

What is not implemented yet is the Normal mapping, which gives Doom 3 models such extraordinary detail. But I'm working on it....

My first blog....

Alrighty... Let's see how this blog thing works. I type in some rubbish here and pretty soon it will be for all the web to see. Ah, the advances of modern technology....