+ Reply to Thread
Results 1 to 2 of 2

Thread: Creating Your Own Shader - The Basics

  1. #1
    Senior Member cityy is on a distinguished road
    Join Date
    Aug 2010
    Location
    Germany
    Posts
    220

    Creating Your Own Shader - The Basics

    As I mentioned in my videos already, QuakeLive differentiates between two different materials, namely textures and shaders.
    As opposed to textures, shaders are not just simple images but script files that assign specific properties to textures (i.e. water, lava, flares, lamps, jumppads, grates).

    Getting deeper into map making you will get to the point of modifying existing QuakeLive shaders (i.e. create a alternative color version of a banner or simular) or creating your own. In order to do this, you need to learn how to create your own shader file (no worries, it's not hard).

    1. Creating Your Shader File

    A shader file is nothing more than a simple text file with the file suffix changed to .shader. To create your shader file, navigate to the scripts\ folder inside wolfcamql\baseq3\ and create a new text file using the name of your current project (i.e. I named the shader file for cure ct_cure.shader).
    As you might have noticed all of my shaders use the prefix ct_ which is nothing more than an abbreviation for "cityy" and a measure to group all my shaders. Giving your project materials a prefix with an underscore will cause GTKradiant to automatically group them in the texture browser (just like base_wall/floor/light, gothic_wall/floor/light etc.) and is a great way to keep yourself organized.

    NOTE: Pay attention to the difference between a shader and a shader file - shaders are contents of the shader file, they include a path, global directives and stages (see "4. How Are Shaders Structured")

    2. Adding Your Shader To The Shaderlist

    The shaderlist communicates with GTKradiant and q3map2 (the map compiler) to let them know what shader files they are supposed to load.
    That's why your shader has to be listed in the shaderlist in order to be recognized by GTKradiant/q3map2. Look for the shaderlist.txt file inside wolfcam\baseq3\scripts\ and open it with a text editor of your choice. Finally, add the name of your shader below the others (for cure, I added ct_cure to the shaderlist).

    3. Creating Your Material Folder

    Creating your own shader often goes with using your own or modified QuakeLive textures. For the purpose of self organization you manage those textures in your own material folder which should have the same name as your .shader file (e.g. the material folder for cure is called ct_cure). Put your material folder into wolfcam\baseq3\textures.

    4. How Are Shaders Structured

    Shader files are basically lists of shader directives, they are not algorithms and are in no way related to traditional programming (c, c++ etc.) - shader files are much more like CSS (Cascading Style Sheets) documents, a list of directives being defined through parameters and values.
    If you are new to shaders, keep in mind that they are easier to handle than it looks but also be aware of the fact that there is no guide, tutorial or video that will make you a shader expert in 24 hours.
    The best way to get into shaders is getting an idea about what result you want to achieve, find an existing shader in QL that does exactly what you want or something simular and eventually grab that shader and copy its contents over to your own file.
    The common shader structure looks like this:

    Code:
    textures/mymap/exampleshader
    {
        GLOBAL DIRECTIVES
        {
                STAGE 1
        }  
        {
                STAGE 2
        } 
    }
    Explanation:

    - 1st line: textures/mymap/exampleshader - this sets the path and name of your shader, in this example the shader "exampleshader" would appear in the "mymap" folder in the texture browser. For the shader path you usually stick to the same name as you gave your shader file (e.g. in the case of cure it would be "ct_cure.shader" with the path "textures/ct_cure/exampleshader")
    - the first curly bracket ({) opens the global directives of the shader which commonly include surfaceparameters (e.g. nonsolid, nomarks), "q3map_"- and light parameters as well as the stages
    - stages: managed by curly brackets inside the main stage, you have to imagine sub stages like texture layers of your shader - e.g. if you look at the base jumppad, sub stage 1 would contain the actual pad texture while sub stage 2 would contain the semi transparent blend texture (glow/swoosh effect) - NOTE: Stages are layered back to front. Ingame, the first stage is always "at the very bottom" of your shader
    - note that the global directives affect the entire shader in its properties while the stages only affect the individual layers

    As said above, the best method for startes is to work off existing QuakeLive shaders. Pak00.pk3 contains most of the basic QuakeLive shaders, so if you decrypt and unpack it you will have a good repository to work off from.

    5. Advancing With the Shader Manual

    Copy pasting existing shaders and understanding their structure is one thing but understanding what those parameters actually do is another. You can be a good map maker without understanding too much of the shader topic but at some point you will find yourself wanting to understand what all this is about to be able to create new things resulting from your own imagination. That's where the ShaderManual comes into play. The ShaderManual is the official Q3map2 shader documentation and covers every shader parameter available.
    Personally, I also started with copy/pasting shaders but eventually, when I wanted to achieve a certain effect with a shader I started looking into the manual, checking out what all those blendFuncs and tcmods are doing. The Manual is the bible of shader editing and of great importance during editing sessions.
    You can access the shader manual on multiple websites (use the link above or just search for it via google), access it through GTKradiant (help menu) or what I recommend, save yourself a local copy.

    If anyone has specific questions regarding this, feel free to ask.
    Last edited by cityy; 06-06-2013 at 09:54 AM.

  2. #2
    Member Obsidian is on a distinguished road
    Join Date
    Aug 2010
    Posts
    32
    Good tutorial, cityy.

    Additional tips:

    You can think of shaders as just a fancy list of properties that you want your surface to have. I would like my surface to be: transparent, visible from two sides, and non-solid. I want to use texture-A on the first layer, with texture-B glowing on top, and finally topped with a lightmap. The only tricky part is that this list has to be formatted a certain way with specific directives...

    Code:
    this/is/my/texture/name
    {
        cull none //visible from both sides
        surfaceparm trans
        surfaceparm nonsolid
        {
            map this/is/texture-A.tga
        }
        {
            map this/is/texture-B.tga
            blendFunc add
        }
        {
            map $lightmap
            blendFunc filter
        }
    }
    As you can see, it's relatively straightforward and reads pretty much like our list. We can add other stuff to the shader like a waveform to the glow texture to make it fade in and out, and maybe a tcMod directive to make it spin or something. There are no "if" statements or other functions in programming languages.

    Another great way to start learning to use shaders (and what I still do to test newly written shaders) is to create a really basic test map, just a square room with a few blocks sitting in it. Create a new shader, and apply it to one of the blocks. You can make some small changes to the shader and see what changes they make to the block in-game. Experiment, trial-and-error, and repeat. It's the only way to get an understanding of what each directive actually does.

    I recommend that most beginners start with stage based directives and particularly learn about blendFuncs and tcMod stuff. It's where you can easily start seeing the benefits of cool shader effects. Many of the q3map_ directives can be a bit more confusing and you may not be able to see the changes as visually.

    Note that changes to global directives will require you to recompile a map. On the other hand, if you make changes to just one of the stages in a shader, you can see the changes in-game without recompiling. Just reload the map or type in the console /vid_restart.

    Learning to create shaders is much easier these days now that there is a unified reference manual. I had to dig through various readme's and source code to try and figure what some directives did, ran trial and error tests, and I wrote my findings down as notes. These notes were eventually appended to the manual and that's how we now have the shader manual.

    Happy shader writing.

+ Reply to Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts