Shaders are simple text-based files that is used by both the compiler (q3map2), and the engine (darkplaces/quake3). They contain instructions for both of these things in relation to specific textures, telling whether or not the texture moves, whether it's a liquid, how to blend the texture, etc. Darkplaces (nexuiz's engine) is only able to interpret a smaller set of instructions from the shaders than Quake3 (which the shader system was originally created for), and thus less needs to be explained.
A large part of the shader system that people have trouble with is how GTKRadiant and Q3map2 work with them. I'll start with GTKRadiant, as it's interaction with shaders is relatively irrelevant.
GTKRadiant:
Radiant uses the shaders in a two basic ways:
-to display specific transparencies on textures such as slime and water
-to denote which textures have an accompanying shader
It looks for shaders in the /scripts/ directory of your nexuiz or quake3 base folder (either /data/ or /baseq3/), and it specifically checks a file called shaderlist.txt for a listing of texture and shader directories.
For example, if you had some textures inside of /textures/test/ that you wanted displayed, you would open up shaderlist.txt and add test to the list. Then, under the textures tab in GTKRadiant, test would show up in the list of directories.
Now, on to q3map2:
Q3map2 is what compiles maps for nexuiz. Part of it's job is to make sure the engine recognizes which textures are lava/water/slime, which brushes are transparent, etc. To do this, it needs to load shaders when it is compiling. It, like Radiant, looks for shaders inside of the /scripts/ directory, and also references shaderlist.txt.
For example:
If you had textures/test/slime.tga applied to a brush, and had a shader that described that texture as being slime inside of scripts/test.shader, then you would want to add test to the list inside of shaderlist.txt. Q3map2 would then read shaderlist.txt, see test listed, check /scripts/test.shader for any textures that had special properties, and then properly flag any brushes that had slime.tga applied to them as being a slimey liquid.
Now, on to the actual shaders, with a few specific examples that apply to nexuiz:
Example 1: Lava/Slime/Water shaders
Lets say you want a slime texture somewhere in your map. What you need first is a slime texture. Let's name it slime1.tga and place it inside of /textures/liquids/. So you should now have:
textures/liquids/slime1.tga
Now, let's write the shader. First off, open notepad, or whatever text editor you want to use. Copy and paste the following inside:
- Code: Select all
textures/liquids/slime1
{
qer_editorimage textures/liquids/slime1.tga
q3map_lightimage textures/liquids/slime1.tga
q3map_globaltexture
qer_trans .5
surfaceparm noimpact
surfaceparm slime
surfaceparm nolightmap
surfaceparm trans
q3map_surfacelight 100
tessSize 32
cull disable
{
map textures/liquids/slime1.tga
}
}
Save this file as liquids.shader inside of your /scripts/ directory. You should now have two files:
textures/liquids/slime1.tga
and
scripts/liquids.shader
We now need to modify shaderlist.txt, which should be inside of your /scripts/ directory. Open it up, and add liquids to the list, if it is not already there.
Now, open up GTKRadiant, and load the liquids texture selection. You should have a texture called slime1 with a white outline around it. This tells you that the shader is being recognized by Radiant. Assign this texture to a brush, and compile. Q3map2 should recognize the shader and flag the surfaces that use the texture as being slime.
--I'll add more examples for transparency, and explain what each part of the shader does at a later time, I'm too tired from typing ATM
--
Hope this helps, feel free to ask questions, and we can compile a FAQ.
