Doom3world

Quick and Dirty Material Shader Primer

Introduction

In Doom 3 textures are usually composed of several images. These images are blended using different techniques to form a material. These materials are what you see as "textures" in game.

What these images do is define the asthetics of a surface. By combining the efforts of multiple images, each reacting differently to the light surrounding it, you can convey more realism than by using a single image.

The problem with using multiple images is that you need a way to associate them with one another. This is where material shaders come into play.

A material shader is nothing more than a list of commands enclosed in curly brackets with a given name. These commands define what images to use, where to locate them, how they should behave, and how the surface should react to different events in game.

Naming Convention

If you've ever used Doom 3's level editor, you've probably seen the media browser and how it appears to be a directory tree. If you take anything away from this tutorial please note that this menu while it is a directory tree, is not a reflection of actual directories on your hard drive or inside pak files.

In order to help explain this I'm going to have to throw a material shader in your face real quick.

Here is a material shader found in vehicles.mtr...



Now what's important to note here is the very first line. It says models/mapobjects/buggy/buggy. This is the name of the material. Yes, I am aware that there are forward slashes and it looks like it's pointing to a directory.

And to help prove my point we're going to look for this mysterious directory. First, it says models so that means we should look in pak002.pk4. Now try to browse to models\mapobjects\buggy\buggy.

What's that? There is no buggy directory? Well that can't be right because clearly models/mapobjects/buggy/buggy is a path because it has slashes. Now you can search the other pak files if you want but I'm telling you right now that you're not going to find a buggy directory anywhere unless you're a smart ass and create one yourself.

So, now you've got to be wondering, if models/mapobjects/buggy/buggy is a material name then why are there slashes?

Well, I'll explain that with an example. Remember how the media browser displays a directory tree? Well, if you were to open the editor and go to the media browser. Then browse to models/mapobjects/ you'd see that in the media browser a buggy folder exists and inside this folder is a material named buggy. Coinsidence?

Note: If you have the clean shaders pak that you won't find this shader in the editor.

So, while models/mapobjects/buggy/buggy does not point to a directory inside the pak files it does point to a location inside the media browser.

What does this mean? That you can name your material shaders whatever the hell you want. I can name a material shader foo/dee/dum/wee and it won't matter if my images are stored in the models, or textures folder. All the shader name applies to is the location of the material in the media browser.

Stages and Curly Brackets

Now that we know how to name a material shader we need to define where the shader begins and ends. Let's look at that buggy shader again...



If you look at the shader above you'll see two curly brackets. These brackets define where models/mapobjects/buggy/buggy begins and ends. Opening curly brackets define the start and closing curly brackets define the end.

Now, in this material shader there are three stages. What are stages? Well, you can think of them as layers in Photoshop where each layer could act as it's own separate image. They are in a stack and in some cases the order in which you code them has an effect on the outcome.

For instance, if I had a opaque image on one stage and an image with an alpha blend on another, I would have to ensure that the alpha blended stage was the top most stage so you could see through the transparent parts to the opaque stage below. If it were the other way around, I would not be able to see the alpha blended stage because the opaque stage would obscure it.

The good news is that the three most common blend modes do not have to be in a certain order to render properly.

Don't breathe a sigh of relief yet. There is more to talk about in regards to stages but we'll get back to that later.

Three Most Common Blend Modes

Now that we can name a material shader and understand the basic structure we can actually start with the important stuff, blend modes. And since this is just a primer we're only going to bother with the three most common. They are diffusemap, bumpmap, and specularmap.

Diffuse maps define the color of a surface. Diffuse maps do not effect lighting.

Normal maps define the slope of a surface. Normal maps are the most influential in regards to how light effects a surface.

Specular maps define the specular intensity and color of highlights on a surface. Brightness effects the intensity. Hue and saturation effects color.

As for how to use these blend modes let's yet again look at an example shader...



Now you can see above that each command diffusemap, specularmap, and bumpmap is followed by a reference to an image file. These file paths are relative to the Doom 3 base directory, a mod directory, or the structure of a pak file. In this case they refer to pak002.pk4 because that is the pak with a models folder.

Just to wrap this section up I want to spend a bit of time on the command qer_editorimage. It's not a blend mode but it's format is the same. So, if it's not a blend mode then why is it important?

Well, the editor relies on this command so it knows what to display on the face of your brushes in the camera window. If you leave it out, like it is missing from this shader, then whenever you apply a new material to a brush it will be solid black.

What image you point it to is not important since it has no effect in game but generally it's a good idea to point it at the diffuse map just for the sake of asthetics.

Stages with Special Parameters

Here's an example shader I wrote using what we've talked about up to this point...



Let's say I want my specular map to scroll. Well, the command for that is called translate. But where would I put this command? How would the game know what stage I want to apply this effect to?

Well, without adding new curly brackets it won't. But there's more to it then just wrapping the specularmap command in a set of curly brackets.

Here's how my shader would look after adding the translate command to the specularmap stage...



So, what's happening here is a curly bracket defines where this new stage starts. Then it's followed by a blend command that informs the game that this stage will be a specular map stage. Then it's followed by a map command that tells the game what image I intend to use as my specular map. And finally I have my translate command followed by a closing bracket to let the game know that this is the end of the specular stage.

General Material Parameters

The last thing I want to talk about is general material parameters. These are commands that do not affect individual stages but rather the entire material as a whole.

For instance, one of these parameters is metal, and if I added it to my example material it would look like this...



What this parameter does is tell the game that when this material is shot it should react as if it were made of metal.

One thing to keep in mind though is that we are not limited to defining the behavior of a material with these commands. There are also commands that effect the way a material is rendered.

An example is the command twosided. This command is best used with decals when you want both sides to be rendered. An example would be all those non-patch hanging wires you see in game. Those are just decals that are set to be two sided.

Conclusion

Now you should have a pretty good idea how to write your own material shaders.

Granted, it's not going to be anything complex but the whole point of this tutorial is just to get the most basic of questions answered and to fill the need for a primer since the SDK is taking longer than I expected.

If you spend a little time examining Doom 3's existing shaders then figuring out what other commands do should be a breeze. And if it's not, the SDK is on the way and there should be a shader manual included.

Thanks, rich. I could really use this, as you know.

Boredom + Visio = Confusing graph:

http://www.doom3reference.com/images/models_materials.gif

Thanks, Rich! Most of my questions have been answered!

The only problem I have now is getting my own texture to display at a size of 256 x 512. I noticed near the top is a quick display of a texture with a rendered dimension of 512 x 512. I'm missing an .lwo file (or .ase, etc.). I have no idea how to create those files. Is there a way I can not need an .lwo?

Btw, when I added the renderbump thing in my .mtr, the door texture appears as black nothingness:



...(don't worry, I don't have my hard drive directories confused with my media browser paths) I'm obviously missing stuff, like an .lwo file (or the like).

What are the dimensions of your images? And what do you mean by a size of 256x512? Are you refering to units in game or image resolution?

And what do you mean you're missing an LWO/ASE file? Are we talking about a texture for a map or a model?

LWO and ASE files are model file formats. LWO is Lightwave 3D and ASE is 3DSMAX.

You don't need either to create textures and I'm not sure where you got the idea that you did.



Renderbump is used to render a normal map for use with a low poly model.

Unless your making a texture for a model you have no use for it.

Sorry, I did a terrible job explaining my problem.

The actual picture is 286 x 511, but when I mentioned 256x512 (I meant to say 64x128), I was referring to units in the editor. When I used the texture on a brush, the picture was "stretched" out to like 256x256, or something. I want the texture to appear at a size of 64x128. Why won't it?

Sorry again about my crappy inexperience. I only misinterpretted one of the example material shaders you displayed. I thought it was weird that I was using .ase and .lwo in association with a simple texture.

The images need to have a resolution that is a power of two.

2,4,8,16,32,64,128,256,512,1024

Anything inbetween will be resized to match.

Your image is 286 x 511. Doom 3 will rescale this image. Whether it would scale it up, down, or to the closest match, I'm not sure. In the end, your texture is going to be 256 x 256, 512 x 512, or 256 x 512 ingame.

Mac hates this analogy but based on Doom 3's vanilla textures your looking at a scale of 2 pixels for every unit in game.

This means for a brush that is 64x128 units, an image that is 128x256 would fit it perfectly.

Now, keep in mind you are not limited to making textures to Doom 3's specifications. If you want you can use higher resolution images by instructing the game to scale the texture down.

The way this is done is by using the scale keyword in your material shader.

So say you wanted to double the resolution of your texture to 256x512 but squeeze it into the same space as a 128x256 texture. Here's an example of what your shader would look like...

Good work rich. Sorry to be nitpicking but there's a few things I'd like to comment on for completeness' sake:



Yes of course because models/mapobjects/buggy/buggy is a broken material shader. A broken shader is a shader that refers to one or more inexistent assets (TGA files).

In this case: models/md5/vehicles/buggy/buggy_local.tga

If you search in the pak002.pk4 file, you will see it's not there. The TGA file for the diffuse map models/mapobjects/base/chairs/chair1_bmp.tga does exist however but it's a solid grey texture. Since the same texture is also used for the specular map, there would effectively be no specular effects as a result.

Bottom line: a model or brush with this shader applied to it would render with a plain, flat solid grey in the game. Not very useful even if the buggy model mesh (models/md5/vehicles/buggy/buggy.lwo) did exist (but it doesn't of course)



Yes, absolutely correct in technical terms. However I think that from a practical point of view, it's important for game designers and mod creators to assign names to shaders which are relevant to their intended use. It's not any harder to choose a logical, orderly name for them than to name them "whatever the hell you want". But the payoff in terms of orderliness and "confusion free" use for the map designers is tremendous.

For example:
If you intend to create a shader meant to be used to skin a model mesh or for oriented particle effects, it's not really a good idea to choose a name that begins with textures/... It will still work fine but that will cause it to appear in the Textures tree of the media window, thus confusing users into thinking that the shader is meant to be used for applying to world geometry.

There can be exceptions however. If the said shader works fine on map brushes and patch meshes, then there's no problem. If though, the shader has stages with parameters incompatible with brush geometry like "vertexcolor" or oriented sprites for example, then naming that shader textures/.... is really a bad idea because it won't look right when applied on brushes.

Sorry if I bring this up but I'm very partial to this. The designers at Id (remember, they're only human and everybody can make mistakes) mis-named a few of their shaders this way and it caused me great headaches when cleaning up the textures/... material files (and sadly, it is likely to cause confusion for newbie Doom3 mappers forever). Please try and learn from this and not repeat the same mistakes. Bottom line is that one should try and exercise good judgment when naming new shaders.

The TGA file assets for your shaders however, those can reside anywhere the hell you want because the map editor does not see TGA files directly. It sees ONLY material names to fill the media window with.

cheers for that info rich_is_bored, looking forward to putting it into practice at some stage.

Just a quick question which I didnt see the need for me to post a new thread, how do I use just a black and white heightmap and not a heightmap + a normal map?

You'd define your bumpmap stage like so...

thanks

after reading this explanation i don't understand what specular maps are anymore and i've been explaining them to other people for ages now.

i thought the brightness and colors in specular maps affected the brightness and color of specular highlights. i thought Doom3 uses constant glossiness without using textures to vary it and this is the main reason i decided not to buy this game.

For an explanation of the specular "factor" used in D3 read this:

http://www.iddevnet.com/doom3/lighting.php

dude after reading that i know even less what a specular map is. so a specular map is grayscale now? how the hell are you supposed to do gold then? don't tell me id software actually wrote this.

d3 reads in rgb for specular maps. I'm sure there are some that only use grey though.

You're right, I reworded the terminology...



Better?



No. It's RGB just like everything else. I certainly don't remember saying that specular maps were greyscale but if so, please point out where the confusion is so I can correct it.

You'd do gold by drawing a yellow/orange tinted specular map.

And no, id didn't write this. I did in an attempt to provide a more in depth explanation.

But hey, I'm not a professional. I don't get paid for my work and the tutorials submitted here don't go through an editor. The occasional use of incorrect terminology is expected. That's why I rely on comments and such to revise and correct our documentation.

no i was not saying that you said that specular maps were greyscale i was saying that that site Mordenkainen pointed out said it.

Whiskey Tango Foxtrot?!

(ie, )

We shouldn't use this thread to talk about this other issue. Continue the talk about glossiness here please:
http://www.doom3world.org/phpbb2/viewto ... 4477#74477