Procedural Generation

Background

A little bit of background before we dive right into projecting our textures onto 3d objects:

So far, we have only been working with one kind of shader program: Fragment shaders. A full shader program is comprised of both a Vertex and a Fragment shader. I can't do a good job explaining how these two things work in tandem, thankfully, there's a few animations that do it much better than I could explain Here. The two animations to look at are the one near the top, just under the first block of code, and another one further down, with a triangle with very jagged, pixelated edges.

The primary differences between the 'vertex' and 'fragment' shaders are:

1. The vertex shader processes verticies
2. The fragment shader processes pixels
3. The fragment shader (typically) runs more times, and does more work

In the last 'paper', most of the examples were simply fragment shaders, running for every pixel in a canvas object. Behind that, there was a vertex shader, which didn't do much, just to make the entire canvas be used.

In this 'paper', we are moving on to write shaders for the Unity3d game engine. Shaders for this platform are a bit different, and come in many varieties. One method of producing shaders allows for controlling the legacy 'Fixed Function' pipeline. This is a bit less useful for us, since we want to be able to write more complex programs, rather than just telling the graphics card how to sample and blend texture images. We will be focusing on using Surface Shaders. This kind of shader works a bit differently than what we have been doing so far.

Unity's surface shader expects more than just a single color as output, instead, it expects a much larger struct, containing more information about the pixel.

    fixed3 Albedo;      // base (diffuse or specular) color
    fixed3 Specular;    // specular color
    fixed3 Normal;      // tangent space normal, if written
    half3 Emission
    half Metallic;      // 0=non-metal, 1=metal
    half Smoothness;    // 0=rough, 1=smooth
    half Occlusion;     // occlusion (default 1)
    fixed Alpha;        // alpha for transparencies

They also provide a version that takes also has a 'fixed3 Specular' property for specular highlight color. This struct is then used by a lighting function to produce the actual color of the pixel.

1. Albedo is the primary output for surfaces, which is what recieves the light.
2. Specular controls the color of specular reflections. By default, this is just white (100% of whatever light is being reflected)
3. The Emission property is light that is always present (Emitted by the surface), and used for glows.
4. Metallic and Smoothness properties determine the general reflectiveness of the surface, both to light sources and to the ambient environment reflections.
5. Occulsion determines how exposed that part of the surface is to light. This adds to the appearance of depth on the surface.
6. Alpha has no use for opaque surfaces, but can be used to either fade transparent surfaces, Or 'clip' pixels off of partial surfaces, like leaves.

Our 'surface' shader writes to these properties of a struct, and then that struct is unpacked and processed by a lighting function.

Unity's shader system is pretty extensible, and even allows for custom user lighting functions. The lighting function is what actually does what our fragment shaders were doing previously (determining a single color).

However, the presence of other properties gives us other places where we can provide details to make the surfaces have more detail.

For example, besides the Albedo property, we could vary the Metallic and Smoothness properties based on our noise functions, as well the Occulsion, Normal, and Emissive properties.

Unity's pipeline also does a lot of other useful stuff, like providing different information into the fragment/surface shaders, through a user-defined struct (Input) which can hold whatever information is needed, as well as allowing users to provide information themselves through custom vertex functions, as well as automatically compiling a number of different variants of the surface shader for different 'passes', and in different rendering modes. It also creates a way to pipe information about the shader for each 'material' that uses that shader program.

We use this system to grab the worldspace coordinates of the pixel that is being rendered, (The 'worldPos' field in the 'Input' struct) and we use that information to sample the noise fields to build the texture.

Unfortunately, Unity has retired their Web Player plugin, and doesn't properly support complex shaders in their WebGL pipeline, yet. So, there's no graceful way to embed these examples into the pages this time. Instead, there will be embedded images or videos.

Also, much of the stuff that has been done, has been ported to Nvidia Cg, (C for Graphics). Most of the common functions have been separated into cginclude files, similar to headers.

CGIncludes

1. noiseprims.cginc - Holds the hash and basic noise functions
2. fbm.cginc - Holds the fractal noise function
3. voroni.cginc - Holds the voroni noise functions
4. fbmnormal.cginc - Holds a helper function to generate normals for surfaces
5. procheight.cginc - Holds a helper function to parallax surfaces

For starters, lets look at a 3d-projection of the camo created in the last 'paper':

Camo Surface Shader Code

Wow, that was a huge amount of stuff. It starts with the properties block. This defines what data is piped into the shader from the engine, allowing people other than the programmer to define things about the shader. Each of the lines in this section corrospond to a variable defined below (the variables starting with _). Then there's a bunch of #include directives pointing to some of the cginc files listed above, and some other compile directive stuff. Below, towards the bottom, the last few lines assign to the surface outputs. The middle part is still relatively the same.

The surface produced by this shader (with default settings) looks like the following:

Lookin pretty good. Another benefit from using procedural textures, is it's extremely easy to modify what the surface looks like.

Changing shader properties

(Click to expand)

So, changing the properties changes the noise fields, or how the samples are used to generate the texture. The parameters that can be piped into shaders are pretty limitless, as are the kinds of things that one can do with the shaders.

Heres a bunch of other, similar effects I've written using the same noise primitives and CGIncludes. The first two, 'Marble' and 'Digital Brain', I didn't come up with myself, like with the camo pattern, but the rest are all creations of my own. The Camo, Marble, and Tech effects I wrote to get my bearings in the world of making shaders. I then used similar techniques to create the other effects.

Click one to show more info about it.

inline float3 parallax3d(Input IN, float3 h) {
    const float3 nrm = normalize(IN.wNormal);
    const float hv = h * _Parallax - _Parallax * _Bias;
    const float3 eye = normalize(IN.viewDir);
    float3 dir = eye - nrm * dot(eye, nrm) / dot(nrm, nrm);
    return hv * -dir;
}

Here are the shaders applied to some models that were graciously given to public domain by 'Yughues' of Open Game Art: