inalogic

Collaboration between teammates is necessary in any software development project. Game development is no different. Textures artists, level designers and modelers have an impact on polygon counts, graphics memory usage and shader performance. Just like programmers influence how art data is rendered on screen. Although programmers and artists can have different training background, it is essential that they find ways to make a good game in a context where features and deadlines can change fast.

Here is the problem. Many times, I have found myself unable to give artists better control over the game during runtime. Why do they need to control runtime? Well, artists need to control things like atmospheric and weather effects, shading quality, and rendering fidelity. If you have done graphics programing on the Xbox 360 or the PS3 you know that they don't render things quite the same (not that one is better than the other). And because your lighting looks good on your PC doesn't mean it will be the same on console (it maybe turn out to be darker or lighter than you expected). As a programmer, I can always use a debugger or directly change the code until a feature is exactly as I want it to be. However artists may not have the technical expertise to do that. And yet, it is best that someone with an artistic vision be the final judge of the game rendering quality. For all those reasons, artists (and anyone involved in the approval of the game) need to be empower in controlling some of the game parameters at runtime and all this within some boundaries defined by programmers (you don't want the denominator of a division set to zero during program execution!).

Here is how I think you can give artists more control over a program's runtime.

• The code (and data) is always the most up to date piece of any game production. Code changes faster than it takes to update a wiki page and during a crunch period, no one has time to update the documentation.
• If you don't have the manpower, you don't want your programmers to improvise themselves as tool developers. It takes times to validate and get a tool ready for production and then to maintain it. Plus, you need very good knowledge of user interface design otherwise your tool won't perform correctly and you would have wasted resources building something that no one can use correctly.
• You want this to be easy for everybody. To entrust artists over the program runtime, you don't want them to be more like programmers, nor do you want your programmers to be more like artists. If you can manage a balance between programmers and artists expertise then you create a process that further invites collaboration between them.

This is what it looks like in practice. Let your programmers use and API to expose the code inputs parameters to artists. Like this:

    // Initialize parameter system.
    uiTool.Initialize();
    // A checkbox
    uiCheckBox* param1 = uiTool.CheckBox("Param1", false);
    // A spinbox with values within [-20, 20].
    uiSpinBox* param2 = uiTool.SpinBox("Param2", 0, 1, -20, 20);

Then, you provide your artists with a client user interface that can connect, through network, to the program at runtime. When the client tool is connected to the program, its user interface exposes widgets that are linked to the exposed parameters in the code. Artists can then interact with the program in realtime.

Parameters in the client interface as defined in the code.

The APIs provided to programmers let them create variables that are reflected as user interface widget in the client interface. The API contains a server that is open to receive connection from the artists client interface. This way, artists get and interface with widgets component they can understand. And the programmers gets simple C++ class objects he can manipulate.

The server and the client communicate through XML data packets. When the client interact with a widget, an XML data packet is created and transmitted over to the server to be interpreted. Then the C++ objects associated to the widget is updated. The programmers controls the frequency of objects update and the range of their values.

It is simple to create sections of parameters and organize them in a way that is intuitive to artists. And because the tool widgets exist only during runtime, maintaining it is easy; you don't have another piece of code to maintain outside of your main engine. If you don't create C++ parameter objects in the code, they will not show up in the artists tool.

Parameters arranged in a tree structure.

Game development is dynamic process; features can change as the game progresses. This tool technology saves you the time and resources you need to write and maintain tools during production. The tools you create are always up to date with the code. And programmers can quickly provide artists with the right tools they need to get the job done.

There are risks associated with releasing a program that uses what I call an "open shader". An open shader is a disclosed shader file that is used by a program. Because your clients can read and change the file content, your program must handle whatever change is made to the file. It must also handle the case when the shader file is delete or misplaced. If your program fails when your clients make an error in the shader file (and they will), then you have a serious problem. Your program security and reliability is compromised. It doesn't matter that your client did a mistake when she tried to assign a vector4 to a vector3 in the shader code! If you have ever written a shader then you knew this was bound to happen. I do this type of mistake many times in the course of developing a shader. But it just feels wrong when your program fails because it couldn't handle an incorrect input.

How do you release a program with open shader files? Simple! Implement a fallback shader! When your program fail to compile a shader then redirect it to use another shader that you know "can never fail" (in theory!). That shader should never be open to your clients. It should remain undisclosed so no one can easily temper with it. And the best way to do that is to embed it in your program executable.

In my programs, I have a shader embedded with the source code. It looks like this.

TCHAR gPinkShader[] = TEXT(
"[Vertex Shader]                        \n\
#version 110                            \n\
                                        \n\
uniform mat4 ObjectMatrix;              \n\
uniform mat4 CameraMatrix;              \n\
uniform mat4 ProjectionMatrix;          \n\
                                        \n\
void main()                             \n\
{                                       \n\
    gl_Position = ProjectionMatrix * CameraMatrix * ObjectMatrix * gl_Vertex;   \n\
}                                       \n\
                                        \n\
[Fragment Shader]                       \n\
#version 110                            \n\
                                        \n\
void main()                             \n\
{                                       \n\
    gl_FragColor = vec4(1.0, 0.0, 1.0, 1.0);    \n\
}");

What this shader does is, it render every fragment with a solid pink color. Truth is, the color is more like magenta but I believe "Pink Shader" is more telling. When I see this color in my rendering, chances are, there is something wrong with the shader (in addition, it doesn't hurt to display a message telling you the shader is wrong... something I don't do yet). So, be careful or you too might see pink when you modify the shader file of a program from inalogic!

Here is something to download. It is a simple program featuring a 3D object and some controls to modify the shading of the object. Always a good exercise for me to go back to basics with a Phong shader. The program let you several parameters of the shader. You can adjust the colors and the specular exponent of the object material.

This is how you control the 3D view:

• Click and drag the mouse left button: rotate the view around the object.
• Click and drag the mouse right button: move the view away or closer to the 3D object.

I had to go through many details before releasing a program that works outside of my programming environment. I tested it on the following system:

• Vista 64 + Geforce 8800 GTX
• Vista 64 + Radeon HD 4670
• Windows XP + Geforce 6600 AGP

There is one thing though! You have to install Microsoft Visual C++ 2008 Redistributable Package (x86). The program needs Visual Studio 2008 CRT libraries to run. Since Windows XP and Vista supports side-by-side assemblies, it is not enough to just put msvcrt90.dll into the program's executable directory. The DLL's manifest have to be in the right location. Installing Visual 2008 Redistributable Package will do just that for you.

Phong lighting demo.

The program is easy to use. Just play with the controls. Also you may change the shader file PhongShader.glsl that is in the directory Data/Shader. If you do, no need to restart the program to see your changes. Just press the reload shader button on the interface. Should you make an error in the shader code, you will see pink! Enjoy!

[Update]: A new version of this demo is available. This latest version fixes some issues related to OpenGL 2.1 when the drivers supports OpenGL 3.0.

I used to fail my programs whenever glGetUniformLocation returns -1 as the location for a shader uniform parameter. When glGetUniformLocation returns -1 it means that it could not find the parameter in your compiled shader program. I was forcing the program to stop so I can investigate what the issue was. Look at this fragment shader right here. See something wrong?

varying vec3 Normal;
uniform vec3 LightVector;
void main()
{
    vec3 N = normalize(Normal);
    vec3 L = normalize(LightVector);
 
    // Diffuse component
    vec4 Id = vec4(1.0, 1.0, 1.0, 1.0) * max(dot(L, N), 0.0);
    // Assign a constant vector to gl_FragColor. This causes LightVector to be
    // removed from the compiled version of the shader.
    gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0);
}

There is nothing wrong with this code. However, calling glGetUniformLocation(prog, "LightVector") returns -1. Why?

Thing is, glGetUniformLocation behaves correctly. LightVector is declared in the shader code but is not used causing the shader compiler to optimize it away. Even if some instructions in the shader use LightVector, if they don't contribute to the shader final result(here gl_FragColor gets the final result) then they will be removed from the compiled code (the program that will be executed by the GPU). Indeed, there is no point in assigning a location to a uniform parameter that isn't used, just like there is no point in computing instructions that won't influence the final result. There is only a limited number of uniform locations available so it make sense for the shader compiler to avoid wasting this type of resource.

A few days ago, I was writing a shader program and my code was failing on glGetUniformLocation because it was returning -1 for a shader parameter. It took me some time to found that I was doing something wrong. The shader code was correct. There was one uniform parameter that was declared but not used in the code. I knew about this type of problem. I even have a solution implemented in my source code where I let glGetUniformLocation return -1 without halting the program. But the solution wasn't enabled. And so, I wasted time looking for something that wasn't there!

From now on, I let glGetUniformLocation return -1. However, I make sure that every time I call something like glUniformXYZ, that the parameter location is valid. It should be greater or equal to zero.