• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
  • entries
  • comments
  • views

Shader Templates - Simple But Useful

Sign in to follow this  
Followers 0


For the longest time I've struggled with how I wanted to handle materials in my graphics framework. When searching around for existing solutions I found basically two things.

A: Shaders with strict inputs:
A single shader that had specific inputs that were textures, floats, etc etc.

B: Node based shaders:
Crazy flexible graphical editors for materials constructed from graphs of various building block elements.

'A' wasn't flexible enough for me, and 'B' seemed like something way to big and time consuming to properly create myself.

So I decided on something somewhat inbetween...

I built a GLSL preprocessor templated shader generator. It takes in GLSL code with extra markup. Instead of specifying inputs as strictly typed GLSL uniform variables. I tell the generator the input names and the desired final data type (float, vec2, vec3, vec4). Then a set of inputs is given to the generator and it creates a shader that samples the textures, looks up values, and makes sure there's a variable with the requested name that contains the appropriate value.

It's easier to show what I mean... Here's my Blinn-Phong material shader template.


#version 140#include "shaders/brdf/blinnphong.hglsl"#include "shaders/brdf/NormalMapping.hglsl"<%input vec4 DiffuseColor%><%input vec4 SpecularColor%><%input float SpecularPower%><%input float SpecularIntensity%><%input vec3 NormalMap optional%><%input vec4 Emissive optional%>in vec2 TextureCoordinate;in vec3 GeometryNormal;in vec3 GeometryTangent;<%definitions%>void ShadePrep (){ <%init%>}vec4 ConstantShading(vec4 AmbientLight){ vec4 result = AmbientLight * DiffuseColor; <%ifis not Emissive: None%> result += Emissive; <%endif%> return result;}vec4 Shade (vec3 LightDir, vec3 ViewDir, vec3 LightColor, float Attenuation){ vec3 normal = normalize(GeometryNormal); <%ifis NormalMap: Texture %> normal = NormalMapping(normal,normalize(GeometryTangent),NormalMap); <%endif%> return BlinnPhong (LightDir, ViewDir, LightColor, Attenuation, normal, DiffuseColor, SpecularColor, SpecularPower, SpecularIntensity);}
<%input ... %> : Specifies input names and desired types to the generator. Some inputs can be optional, the generator won't raise an error if these aren't supplied.

<%definitions%> : This tells the generator where to define extra variables it may need. While technically redundant because the extra variables could be placed where the <%input%> tag is, I wrote it with the <%definitions%> tag and didn't bother to remove it.

<%init%> : This tells the generator where to put the code that's needed to get the proper final value, such as sampling a texture.

<%ifis ...%> : This lets the generator do different things based on the types of input you supply. In the above shader I add an extra line of code to transform the normal if a NormalMap texture is supplied. I also apply an Emissive term if the shader is supplied one.

Input Sets

Sets can be constructed in code, or loaded from file. The file contains text like this:DiffuseColor tex("sword/diffuse.png")SpecularPower 6.0SpecularIntensity tex("sword/specular.png").rSpecularColor color(255,255,255)NormalMap tex("sword/normal.png")Emissive tex("sword/glow.png")
It's pretty easy to tell what this does. The generator takes the input set, and generates a shader which can utilize it. You might notice I specify a swizzle for SpecularIntensity. You can pick different channels out of a texture for a certain input, if you specify the same texture twice it's smart enough to only sample it once and swizzle the sample in the shader.

When I plug those inputs in, this is what it generates (I fixed the whitespace up though...)#version 140#include "shaders/brdf/blinnphong.hglsl"#include "shaders/brdf/NormalMapping.hglsl"uniform sampler2D Texture_0;uniform vec4 SpecularColor;uniform float SpecularPower;uniform sampler2D Texture_4;uniform sampler2D Texture_2;uniform sampler2D Texture_1;in vec2 TextureCoordinate;in vec3 GeometryNormal;in vec3 GeometryTangent;vec4 DiffuseColor;vec4 Emissive;vec3 NormalMap;float SpecularIntensity;void ShadePrep (){ vec4 Sample0 = texture2D(Texture_0, TextureCoordinate); DiffuseColor = Sample0.xyzw; vec4 Sample1 = texture2D(Texture_1, TextureCoordinate); Emissive = Sample1.xyzw; vec4 Sample2 = texture2D(Texture_2, TextureCoordinate); NormalMap = Sample2.xyz; vec4 Sample4 = texture2D(Texture_4, TextureCoordinate); SpecularIntensity = Sample4.x;}vec4 ConstantShading(vec4 AmbientLight){ vec4 result = AmbientLight * DiffuseColor; result += Emissive; return result;}vec4 Shade (vec3 LightDir, vec3 ViewDir, vec3 LightColor, float Attenuation){ vec3 normal = normalize(GeometryNormal); normal = NormalMapping(normal,normalize(GeometryTangent),NormalMap); return BlinnPhong (LightDir, ViewDir, LightColor, Attenuation, normal, DiffuseColor, SpecularColor, SpecularPower, SpecularIntensity);}
These are just simple inputs, but you can do more interesting things with it as well. For particle systems I can connect the material inputs to values passed in from the particle data. For instance getting a index for an array of different particle textures. If you wanted an animated texture you can have an input type represent all the frames and switch between them.

Additionally the input sets generate a hash code (probably)unique to the generated shader, so if you have similar input sets that use the same generated shader, it's only created once. I was also hoping to cache the compiled shader binaries. However, even in the latest OpenGL the spec says that glShaderBinary must be supported but there doesn't have to exist a format to save them in. So it's pretty useless and disappointing, it's possible to cache the linked programs though.

It was fairly easy to implement, allows decent flexibility, and cuts down on the time I have to spend writing little differences in shaders. There's obviously a lot of improvements I could make (as with anything) but I'm getting a lot of mileage out of it's current state.

What do you think? I'd love some feedback.

Also, Obligatory Progress Screenshot:

Sign in to follow this  
Followers 0


Quite a nice concept you have here, I like the pseudo-dynamic aspect of it.

I have a somewhat similar setup which revolves around using pre-processor macros and compiling the shader with different configurations ('sets' in your case).


Does it also work for non-uniforms (e.g. you wanted to fetch DiffuseColor not from a texture, but from the vertex colour itself) or is your vertex input pretty much static for the moment ?


Anyway, thanks for sharing, this has given ideas to push my own design further. 


Share this comment

Link to comment

I added a new "input type" for vertex attributes because I needed them for particle effects. Individual particle information is stored in a VBO so it has to be passed in through the vertex shader.


So if my vertex shader has 

out vec4 VertexColor;

In my material file I can type 

Color vertex_input("VertexColor")

And the generator will create 

in vec4 VertexColor;
vec4 Color;


Color = VertexColor;

Which adds an extra step, but I could add a check to see if the desired name and the input name are the same to only generate an input variable.


It's pretty easy with my implementation to add new ways of accepting input since it just involves deriving from a base input class and writing a handful of methods.


Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now