Something to watch out for with depth buffers is Z-fighting, which is a visual artifact that occurs when overlapping triangles have depths that are too close to each other (see Figure 4.2, “Z Fighting in the Möbius Strip”).

Figure 4.2. Z Fighting in the Möbius Strip

Recall that the projection matrix defines a viewing frustum bounded by six planes (the section called “Setting the Projection Transform”). The two planes that are perpendicular to the viewing direction are called the near plane and far plane. In ES 1.1, these planes are arguments to the glOrtho or glPerspective functions; in ES 2.0, they're passed to a custom function like the mat4::Frustum method in the C++ vector library from Appendix A, C++ Vector Library.

It turns out that if the near plane is too close to the camera, or if the far plane is too distant, this can cause precision issues that result in Z-fighting. However this is only one possible cause for Z-fighting; there are many more. Take a look at the following list of suggestions if you ever see artifacts like the ones in Figure 4.2, “Z Fighting in the Möbius Strip”.

You might recall that normals are one of the pre-defined vertex attributes in OpenGL ES 1.1. They can be enabled like this:

// OpenGL ES 1.1
glEnableClientState(GL_NORMAL_ARRAY);
glNormalPointer(GL_FLOAT, stride, offset);
glEnable(GL_NORMALIZE);

// OpenGL ES 2.0
glEnableVertexAttribArray(myNormalSlot);
glVertexAttribPointer(myNormalSlot, 3, GL_FLOAT, normalize, stride, offset);

I snuck in something new in the above snippet: the GL_NORMALIZE state in ES 1.1, and the normalize argument in ES 2.0. Both are used to control whether or not OpenGL processes your normal vectors to make them unit length. If you already know that your normals are unit length, do not turn this feature on; it incurs a performance hit.

Even though OpenGL ES 1.1 can perform much of the lighting math on your behalf, it does not compute surface normals for you. At first this may seem rather ungracious on OpenGL's part, but as you'll see later, stipulating the normals yourself give you the power to render interesting effects. While the mathematical notion of a normal is well-defined, the OpenGL notion of a normal is simply another input with discretionary values, much like color and position. Mathematicians live in an ideal world of smooth surfaces, but graphics programmers live in a world of triangles. If you were to make the normals in every triangle point in the exact direction that the triangle is facing, your model would looked faceted and artificial; every triangle would have a uniform color. By supplying normals yourself, you can make your model seem smooth, faceted, or even bumpy, as we'll see later.

We scoff at mathematicians for living in an artificially ideal world, but we can't dismiss the math behind normals; we need it to come up with sensible values in the first place. Central to the mathematical notion of a normal is the concept of a tangent plane, depicted in Figure 4.5, “Normal Vector with Tangent Plane”.

Figure 4.5. Normal Vector with Tangent Plane

The diagram in Figure 4.5, “Normal Vector with Tangent Plane” is, in itself, perhaps the best definition of the tangent plane that I can give you without going into calculus. It's the plane that "just touches" your surface at a given point P. Think like a mathematician: for them, a plane is minimally defined with three points. So, imagine three points at random positions on your surface, then create a plane that contains them all. Slowly move the three points towards each other; just before the three points converge, the plane they define is the tangent plane.

The tangent plane can also be defined with tangent and binormal vectors (u and v in Figure 4.5, “Normal Vector with Tangent Plane”), which are easiest to define within the context of a parametric surface. Each of these correspond to a dimension of the domain; we'll make use of this when we add normals to our ParametricSurface class.

Finding two vectors in the tangent plane is usually fairly easy. For example, you can take any two sides of a triangle; the two vectors need not be at right angles to each other. Simply take their cross product and unitize the result. For parametric surfaces, the procedure can be summarized with the following pseudocode:

p = Evaluate(s, t)
u = Evaluate(s + ds, t) - p
v = Evaluate(s, t + dt) - p
N = Normalize(u × v)

Don't be frightened by the cross product, I'll give you a brief refresher. The cross product always generates a vector perpendicular to its two input vectors. You can visualize the cross product of A with B using your right hand. Point your index finger in the direction of A, then point your middle finger towards B; your thumb now points in the direction of A×B (pronounced "A cross B", not "A times B"). See Figure 4.6, “Right-Hand Rule”.

Figure 4.6. Right-Hand Rule

Here's the relevant snippet from our C++ library (see Appendix A, C++ Vector Library for a full listing):

template <typename T>
struct Vector3 {
    // ...
    Vector3 Cross(const Vector3& v) const
    {
        return Vector3(y * v.z - z * v.y,
                       z * v.x - x * v.z,
                       x * v.y - y * v.x);
    }
    // ...
    T x, y, z;
};

Let's not lose focus on why we're generating normals in the first place: they're required for the lighting algorithms that we cover later in this chapter. Recall from Chapter 2, Math and Metaphors that vertex position can live in different spaces: object space, world space, and so on. Normal vectors can live in these different spaces too; it turns out that lighting in the vertex shader is often performed in eye space. (There are certain conditions in which it can be done in object space, but that's a discussion for another day.)

So, we need to transform our normals to eye space. Since vertex positions get transformed by the model-view matrix to bring them into eye space, it follows that normal vectors get transformed the same way, right? Wrong! Actually, wrong sometimes. This is one of the tricker concepts in graphics to understand, so bear with me.

Look at the heart shape in Figure 4.7, “Normal Transforms” and consider the surface normal at a point in the upper-left quadrant (depicted with an arrow). The figure on the far left is the original shape and the middle figure shows what happens after we translate, rotate, and uniformly shrink the heart. The transformation for the normal vector is almost the same as the model's transformation; the only difference is that it's a vector and therefore doesn't require translation. Removing translation from a 4x4 transformation matrix is easy. Simply extract the upper-left 3x3 matrix and you're done.

Figure 4.7. Normal Transforms

Now take a look at the figure on the far right, which shows what happens when stretching the model only along its x-axis. In this case, if we were to apply the upper 3x3 of the model-view matrix to the normal vector, we'd get an incorrect result; the normal would no longer be perpendicular to the surface. This shows that simply extracting the upper-left 3x3 matrix from the model-view matrix doesn't always suffice. I won't bore you with the math, but it can be shown that the correct transform for normal vectors is actually the inverse-transpose of the model-view matrix, which is the result of two operations: first an inverse, then a transpose.

The inverse matrix of M is denoted M^-1; it's the matrix that results in the identity matrix when multiplied with the original matrix. Inverse matrices are somewhat non-trivial to compute, so again I'll refrain from boring you with the math. The transpose matrix, on the other hand, is easy to derive; simply swap the rows and columns of the matrix such that M[i][j] becomes M[j][i].

Transposes are denoted M^T, so the proper transform for normal vectors looks like this:

Don't forget the middle shape in Figure 4.7, “Normal Transforms”; it shows that, at least in some cases, the upper 3x3 of the original model-view matrix can be used to transform the normal vector. In this case, the matrix just happens to be equal to its own inverse-transpose; such matrices are called orthogonal. Rigid body transformations like rotation and uniform scale always result in orthogonal matrices.

Why did I bore you with all this mumbo jumbo about inverses and normal transforms? Two reasons. In ES 1.1, keeping non-uniform scale out of your matrix helps performance because OpenGL can avoid computing the inverse-transpose of the model-view. Secondly, for ES 2.0, you need to understand nitty-gritty details like this anyway to write sensible lighting shaders!

Enough academic babble; let's get back to coding. Since our goal here is to add lighting to Model Viewer, we need to implement the generation of normal vectors. Let's tweak ISurface in Interfaces.hpp by adding a flags parameter to GenerateVertices, as seen in Example 4.7, “Modifying ISurface with Support for Normals”. New or modified lines are shown in bold.

enum VertexFlags {
    VertexFlagsNormals = 1 << 0,
    VertexFlagsTexCoords = 1 << 1,
};

struct ISurface {
    virtual int GetVertexCount() const = 0;
    virtual int GetLineIndexCount() const = 0;
    virtual int GetTriangleIndexCount() const = 0;
    virtual void GenerateVertices(vector<float>& vertices,
                                  unsigned char flags = 0) const = 0;
    virtual void GenerateLineIndices(vector<unsigned short>& indices) const = 0;
    virtual void 
      GenerateTriangleIndices(vector<unsigned short>& indices) const = 0;
    virtual ~ISurface() {}
};

The argument we added to GenerateVertices could have been a boolean instead of a bit mask, but we'll eventually want to feed additional vertex attributes to OpenGL, such as texture coordinates. For now, just ignore the VertexFlagsTexCoords flag; it'll come in handy in the next chapter.

Next we need to open ParametricSurface.hpp and make the complementary change to the class declaration of ParametricSurface, as seen in Example 4.8, “ParametricSurface Class Declaration”. We'll also add a new protected method called InvertNormal, which derived classes can optionally override.

class ParametricSurface : public ISurface {
public:
    int GetVertexCount() const;
    int GetLineIndexCount() const;
    int GetTriangleIndexCount() const;
    void GenerateVertices(vector<float>& vertices, unsigned char flags) const;
    void GenerateLineIndices(vector<unsigned short>& indices) const;
    void GenerateTriangleIndices(vector<unsigned short>& indices) const;
protected:
    void SetInterval(const ParametricInterval& interval);
    virtual vec3 Evaluate(const vec2& domain) const = 0;
    virtual bool InvertNormal(const vec2& domain) const { return false; }
private:
    vec2 ComputeDomain(float i, float j) const;
    vec2 m_upperBound;
    ivec2 m_slices;
    ivec2 m_divisions;
};

Next let's open ParametericSurface.cpp and replace the implementation of GenerateVertices, as seen in Example 4.9, “Adding Normals to ParametricSurface::GenerateVertices”.

void ParametricSurface::GenerateVertices(vector<float>& vertices,
                                         unsigned char flags) const
{
    int floatsPerVertex = 3;
    if (flags & VertexFlagsNormals)
        floatsPerVertex += 3;

    vertices.resize(GetVertexCount() * floatsPerVertex);
    float* attribute = (float*) &vertices[0];

    for (int j = 0; j < m_divisions.y; j++) {
        for (int i = 0; i < m_divisions.x; i++) {

            // Compute Position
            vec2 domain = ComputeDomain(i, j);
            vec3 range = Evaluate(domain);
            attribute = range.Write(attribute);

            // Compute Normal
            if (flags & VertexFlagsNormals) {
                float s = i, t = j;

                // Nudge the point if the normal is indeterminate.
                if (i == 0) s += 0.01f;
                if (i == m_divisions.x - 1) s -= 0.01f;
                if (j == 0) t += 0.01f;
                if (j == m_divisions.y - 1) t -= 0.01f;
                
                // Compute the tangents and their cross product.
                vec3 p = Evaluate(ComputeDomain(s, t));
                vec3 u = Evaluate(ComputeDomain(s + 0.01f, t)) - p;
                vec3 v = Evaluate(ComputeDomain(s, t + 0.01f)) - p;
                vec3 normal = u.Cross(v).Normalized();
                if (InvertNormal(domain))
                    normal = -normal;
                attribute = normal.Write(attribute);
            }
        }
    }
}

This completes the changes to ParametricSurface. You should be able to build Model Viewer at this point, but it will look the same since we have yet to put the normal vectors to good use. That comes next.

Realistic ambient lighting, with the soft, muted shadows that it conjures up, can be very complex to render (you can see an example of ambient occlusion in the section called “Baked Lighting”), but ambient lighting in the context of OpenGL usually refers to something far more trivial: a solid, uniform color. Calling this "lighting" is questionable since its intensity is not impacted by the position of the light source or the orientation of the surface, but it is often combined with the other lighting models to produce a brighter surface.

The most common form of real-time lighting is diffuse lighting, which varies its brightness according to the angle between the surface and the light source. Also known as lambertian reflection, this form of lighting is predominant because it's simple to compute, and it adequately conveys depth to the human eye. Figure 4.9, “Diffuse Lighting” shows how diffuse lighting works. In the diagram, L is the unit length vector pointing to the light source, and N is the surface normal, which is a unit-length vector that's perpendicular to the surface. We'll learn how to compute N later in the chapter.

Figure 4.9. Diffuse Lighting

The diffuse factor (known as df in Figure 4.9, “Diffuse Lighting”) lies between 0 and 1 and gets multiplied with the light intensity and material color to produce the final diffuse color, as shown in Equation 4.1, “Diffuse Color”.

Equation 4.1. Diffuse Color

df is computed by taking the dot product of the surface normal with the light direction vector, then clamping the result to a non-negative number, as shown in Equation 4.2, “Diffuse Coefficient”.

Equation 4.2. Diffuse Coefficient

The dot product is another operation that you might need a refresher on. When applied to two unit-length vectors (which is what we're doing for diffuse lighting), you can think of the dot product as a way of measuring the angle between the vectors. If the two vectors are perpendicular to each other, their dot product is zero; if they point away from each other, their dot product is negative. Specifically, the dot product of two unit vectors is the cosine of the angle between them. To see how to compute the dot product, here's a snippet from our C++ vector library (see Appendix A, C++ Vector Library for a complete listing):

template <typename T>
struct Vector3 {
    // ...
    T Dot(const Vector3& v) const
    {
        return x * v.x + y * v.y + z * v.z;
    }
    // ...
    T x, y, z;
};

With OpenGL ES 1.1, the math required for diffuse lighting is done for you behind the scenes; with 2.0, you have to do the math yourself in a shader. You'll learn both methods later in the chapter.

The L vector in Equation 4.2, “Diffuse Coefficient” can be computed like this:

In practice, you can often pretend that the light is so far away that all vertices are at the origin. The above equation then simplifies to:

When you apply this optimization, you're said to be using an infinite light source. Taking each vertex position into account is slower but more accurate; this is a positional light source.

Diffuse lighting is not affected by the position of the camera; the diffuse brightness of a fixed point stays the same, no matter which direction you observe it from. This is in contrast to specular lighting, which moves the area of brightness according to your eye position, as seen in Figure 4.10, “Specular Lighting”. Specular lighting mimics the shiny highlight seen on polished surfaces. Hold a shiny apple in front of you and shift your head to the left and right; you'll see that the apple's shiny spot moves with you. Specular is more costly to compute than diffuse because it uses exponentiation to compute falloff. You choose the exponent according to how you want the material to look; the higher the exponent, the shinier the model.

Figure 4.10. Specular Lighting

The H vector in Figure 4.10, “Specular Lighting” is called the half-angle because it divides the angle between the light and the camera in half. Much like diffuse lighting, the goal is to compute an intensity coefficient (in this case, sf) between 0 and 1. Equation 4.3, “Specular Lighting” shows how to compute sf.

Equation 4.3. Specular Lighting

In practice, you can often pretend that the viewer is infinitely far from the vertex, in which case the E vector is substituted with (0, 0, 1). This technique is called infinite viewer. When E is used, this is called local viewer.

We'll first add lighting to the OpenGL ES 1.1 backend since it's much less involved than the 2.0 variant. Example 4.10, “ES1::RenderingEngine::Initialize” shows the new Initialize method (unchanged portions are replaced with ellipses for brevity).

void RenderingEngine::Initialize(const vector<ISurface*>& surfaces)
{
    vector<ISurface*>::const_iterator surface;
    for (surface = surfaces.begin(); surface != surfaces.end(); ++surface) {
        
        // Create the VBO for the vertices.
        vector<float> vertices;
        (*surface)->GenerateVertices(vertices, VertexFlagsNormals);
        GLuint vertexBuffer;
        glGenBuffers(1, &vertexBuffer);
        glBindBuffer(GL_ARRAY_BUFFER, vertexBuffer);
        glBufferData(GL_ARRAY_BUFFER,
                     vertices.size() * sizeof(vertices[0]),
                     &vertices[0],
                     GL_STATIC_DRAW);
        
        // Create a new VBO for the indices if needed.
        ...
    }

    // Set up various GL state.
    glEnableClientState(GL_VERTEX_ARRAY);
    glEnableClientState(GL_NORMAL_ARRAY);
    glEnable(GL_LIGHTING);
    glEnable(GL_LIGHT0);
    glEnable(GL_DEPTH_TEST);

    // Set up the material properties.
    vec4 specular(0.5f, 0.5f, 0.5f, 1);
    glMaterialfv(GL_FRONT_AND_BACK, GL_SPECULAR, specular.Pointer());
    glMaterialf(GL_FRONT_AND_BACK, GL_SHININESS, 50.0f);

    m_translation = mat4::Translate(0, 0, -7);
}

Example 4.10, “ES1::RenderingEngine::Initialize” uses some new OpenGL functions: glMaterialf and glMaterialfv. These are only useful when lighting is turned on, and they are unique to ES 1.1 — with 2.0 you'd use glVertexAttrib instead. The declarations for these functions are:

void glMaterialf(GLenum face, GLenum pname, GLfloat param);
void glMaterialfv(GLenum face, GLenum pname, const GLfloat *params);

The face parameter is a bit of a carry-over from desktop OpenGL, which allows the back and front sides of a surface to have different material properties. For OpenGL ES, this parameter must always be set to GL_FRONT_AND_BACK.

The pname parameter can be one of:

When lighting is enabled, the final color of the surface is determined at run time, so OpenGL ignores the color attribute that you set with glColor4f or GL_COLOR_ARRAY (see Table 2.2). Since you'd only specify the color attribute when lighting is turned off, it's often referred to as non-lit color.

Next we'll flesh out the Render() method so that it uses normals, as shown in Example 4.11, “ES1::RenderingEngine::Render”. New/changed lines are in boldface. Note that we moved up the call to glMatrixMode; this is explained further in the callouts that follow the listing.

void RenderingEngine::Render(const vector<Visual>& visuals) const
{
    glClearColor(0.5f, 0.5f, 0.5f, 1);
    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
    
    vector<Visual>::const_iterator visual = visuals.begin();
    for (int visualIndex = 0; 
         visual != visuals.end(); 
         ++visual, ++visualIndex) 
    {
        
        // Set the viewport transform.
        ivec2 size = visual->ViewportSize;
        ivec2 lowerLeft = visual->LowerLeft;
        glViewport(lowerLeft.x, lowerLeft.y, size.x, size.y);
        
        // Set the light position.glMatrixMode(GL_MODELVIEW);
        glLoadIdentity();
        vec4 lightPosition(0.25, 0.25, 1, 0);
        glLightfv(GL_LIGHT0, GL_POSITION, lightPosition.Pointer());
        
        // Set the model-view transform.
        mat4 rotation = visual->Orientation.ToMatrix();
        mat4 modelview = rotation * m_translation;
        glLoadMatrixf(modelview.Pointer());
        
        // Set the projection transform.
        float h = 4.0f * size.y / size.x;
        mat4 projection = mat4::Frustum(-2, 2, -h / 2, h / 2, 5, 10);
        glMatrixMode(GL_PROJECTION);
        glLoadMatrixf(projection.Pointer());
        
        // Set the diffuse color.vec3 color = visual->Color * 0.75f;
        vec4 diffuse(color.x, color.y, color.z, 1);
        glMaterialfv(GL_FRONT_AND_BACK, GL_DIFFUSE, diffuse.Pointer());

        // Draw the surface.
        int stride = 2 * sizeof(vec3);
        const Drawable& drawable = m_drawables[visualIndex];
        glBindBuffer(GL_ARRAY_BUFFER, drawable.VertexBuffer);
        glVertexPointer(3, GL_FLOAT, stride, 0);
        const GLvoid* normalOffset = (const GLvoid*) sizeof(vec3);        glNormalPointer(GL_FLOAT, stride, normalOffset);
        glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, drawable.IndexBuffer);
        glDrawElements(GL_TRIANGLES, drawable.IndexCount, GL_UNSIGNED_SHORT, 0);
    }
}

That's it! Figure 4.11, “Model Viewer with Lighting” depicts the app now that lighting has been added. Since we haven't implemented the ES 2.0 renderer yet, you'll need to enable the ForceES1 constant at the top of GLView.mm.

Figure 4.11. Model Viewer with Lighting

Example 4.11, “ES1::RenderingEngine::Render” introduced a new OpenGL function for modifying light parameters, glLightfv:

GL_API void GL_APIENTRY glLightfv(GLenum light, GLenum pname, const GLfloat *params);

The light parameter identifies the light source. Although we're using only one light source in Model Viewer, up to eight are allowed (GL_LIGHT0 - GL_LIGHT7).

The pname argument specifies the light property to modify. OpenGL ES 1.1 supports ten light properties:

You may've noticed that the inside of the cone appears especially dark. This is because the normal vector is facing away from the light source. On third-generation iPhones and iPod Touches, you can enable a feature called two-sided lighting, which inverts the normals on back-facing triangles, allowing them to be lit. It's enabled like this:

glLightModelf(GL_LIGHT_MODEL_TWO_SIDE, GL_TRUE);

Use this function with caution, as it is not supported on older iPhones. One way to avoid two-sided lighting is to re-draw the geometry at a slight offset using flipped normals. This effectively makes your one-sided surface into a two-sided surface. For example, in the case of our cone shape, we could draw another equally-size cone that's just barely "inside" the original cone.

To create the ES 2.0 backend to Model Viewer, let's start with the ES 1.1 variant and make the following changes, some of which should be familiar by now:

Now that the busy work is out of the way, let's add declarations for the uniform handles and attribute handles that are used to communicate with the vertex shader. Since the vertex shader is now much more complex than the simple pass-through program we've been using, let's group the handles into simple sub-structures, as shown in Example 4.16, “ES2::RenderingEngine Structures”. Add this code to RenderingEngine.ES2.cpp, within the namespace declaration, not above it. (The bold part of the listing shows the two lines you must add to the class declaration's private: section.)

#define STRINGIFY(A)  #A
#include "../Shaders/SimpleLighting.vert"
#include "../Shaders/Simple.frag"

struct UniformHandles {
    GLuint Modelview;
    GLuint Projection;
    GLuint NormalMatrix;
    GLuint LightPosition;
};
    
struct AttributeHandles {
    GLint Position;
    GLint Normal;
    GLint Ambient;
    GLint Diffuse;
    GLint Specular;
    GLint Shininess;
};

class RenderingEngine : public IRenderingEngine {
    // ...
    UniformHandles m_uniforms;
    AttributeHandles m_attributes;
};

Next we need to change the Initialize method so that it compiles the shaders, extracts the handles to all the uniforms and attributes, and sets up some default material colors. Replace everything from the comment // Set up various GL state to the end of the method with the contents of Example 4.17, “ES2::RenderingEngine::Initialize()”.

...

// Create the GLSL program.
GLuint program = BuildProgram(SimpleVertexShader, SimpleFragmentShader);
glUseProgram(program);

// Extract the handles to attributes and uniforms.
m_attributes.Position = glGetAttribLocation(program, "Position");
m_attributes.Normal = glGetAttribLocation(program, "Normal");
m_attributes.Ambient = glGetAttribLocation(program, "AmbientMaterial");
m_attributes.Diffuse = glGetAttribLocation(program, "DiffuseMaterial");
m_attributes.Specular = glGetAttribLocation(program, "SpecularMaterial");
m_attributes.Shininess = glGetAttribLocation(program, "Shininess"); 
m_uniforms.Projection = glGetUniformLocation(program, "Projection");
m_uniforms.Modelview = glGetUniformLocation(program, "Modelview");
m_uniforms.NormalMatrix = glGetUniformLocation(program, "NormalMatrix");
m_uniforms.LightPosition = glGetUniformLocation(program, "LightPosition");

// Set up some default material parameters.
glVertexAttrib3f(m_attributes.Ambient, 0.04f, 0.04f, 0.04f);
glVertexAttrib3f(m_attributes.Specular, 0.5, 0.5, 0.5);
glVertexAttrib1f(m_attributes.Shininess, 50);

// Initialize various state.
glEnableVertexAttribArray(m_attributes.Position);
glEnableVertexAttribArray(m_attributes.Normal);
glEnable(GL_DEPTH_TEST);

// Set up transforms.
m_translation = mat4::Translate(0, 0, -7);

Next let's replace the Render() method, shown in Example 4.18, “ES2::RenderingEngine::Render()”.

void RenderingEngine::Render(const vector<Visual>& visuals) const
{
    glClearColor(0, 0.125f, 0.25f, 1);
    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

    vector<Visual>::const_iterator visual = visuals.begin();
    for (int visualIndex = 0; 
         visual != visuals.end(); 
         ++visual, ++visualIndex) {

        // Set the viewport transform.
        ivec2 size = visual->ViewportSize;
        ivec2 lowerLeft = visual->LowerLeft;
        glViewport(lowerLeft.x, lowerLeft.y, size.x, size.y);
        
        // Set the light position.
        vec4 lightPosition(0.25, 0.25, 1, 0);
        glUniform3fv(m_uniforms.LightPosition, 1, lightPosition.Pointer());

        // Set the model-view transform.
        mat4 rotation = visual->Orientation.ToMatrix();
        mat4 modelview = rotation * m_translation;
        glUniformMatrix4fv(m_uniforms.Modelview, 1, 0, modelview.Pointer());
        
        // Set the normal matrix.
        // It's orthogonal, so its Inverse-Transpose is itself!
        mat3 normalMatrix = modelview.ToMat3();
        glUniformMatrix3fv(m_uniforms.NormalMatrix, 1, 
                           0, normalMatrix.Pointer());

        // Set the projection transform.
        float h = 4.0f * size.y / size.x;
        mat4 projectionMatrix = mat4::Frustum(-2, 2, -h / 2, h / 2, 5, 10);
        glUniformMatrix4fv(m_uniforms.Projection, 1, 
                           0, projectionMatrix.Pointer());
        
        // Set the diffuse color.
        vec3 color = visual->Color * 0.75f;
        glVertexAttrib4f(m_attributes.Diffuse, color.x, 
                         color.y, color.z, 1);
        
        // Draw the surface.
        int stride = 2 * sizeof(vec3);
        const GLvoid* offset = (const GLvoid*) sizeof(vec3);
        GLint position = m_attributes.Position;
        GLint normal = m_attributes.Normal;
        const Drawable& drawable = m_drawables[visualIndex];
        glBindBuffer(GL_ARRAY_BUFFER, drawable.VertexBuffer);
        glVertexAttribPointer(position, 3, GL_FLOAT, 
                              GL_FALSE, stride, 0);
        glVertexAttribPointer(normal, 3, GL_FLOAT, GL_FALSE, 
                              stride, offset);
        glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, drawable.IndexBuffer);
        glDrawElements(GL_TRIANGLES, drawable.IndexCount, 
                       GL_UNSIGNED_SHORT, 0);
    }
}

That's it for the ES 2.0 backend! Turn off the ForceES1 switch in GLView.mm and you should see something very similar to the ES 1.1 screenshot shown in Figure 4.11, “Model Viewer with Lighting”.

When a model has coarse tessellation, performing the lighting calculations at the vertex level can result in the loss of specular highlights and other detail, as seen in Figure 4.13, “Tesselation and Lighting. From left to right: infinite tesselation, vertex lighting, and pixel lighting.”.

Figure 4.13. Tesselation and Lighting. From left to right: infinite tesselation, vertex lighting, and pixel lighting.

One technique to counteract this unattractive effect is per-pixel lighting; this is when most (or all) of the lighting algorithm takes place in the fragment shader.

The vertex shader becomes vastly simplified, as shown in Example 4.19, “PixelLighting.vert”. It simply passes the diffuse color and eye-space normal to the fragment shader.

attribute vec4 Position;
attribute vec3 Normal;
attribute vec3 DiffuseMaterial;

uniform mat4 Projection;
uniform mat4 Modelview;
uniform mat3 NormalMatrix;

varying vec3 EyespaceNormal;
varying vec3 Diffuse;

void main(void)
{
    EyespaceNormal = NormalMatrix * Normal;
    Diffuse = DiffuseMaterial;
    gl_Position = Projection * Modelview * Position;
}

The fragment shader now performs the burden of the lighting math, as shown in Example 4.20, “PixelLighting.frag”. The main distinction it has from its per-vertex counterpart (Example 4.15, “SimpleLighting.vert”) is the presence of precision specifiers throughout. We're using lowp for colors, mediump for the varying normal, and highp for the internal math.

varying mediump vec3 EyespaceNormal;
varying lowp vec3 Diffuse;

uniform highp vec3 LightPosition;
uniform highp vec3 AmbientMaterial;
uniform highp vec3 SpecularMaterial;
uniform highp float Shininess;

void main(void)
{
    highp vec3 N = normalize(EyespaceNormal);
    highp vec3 L = normalize(LightPosition);
    highp vec3 E = vec3(0, 0, 1);
    highp vec3 H = normalize(L + E);
    
    highp float df = max(0.0, dot(N, L));
    highp float sf = max(0.0, dot(N, H));
    sf = pow(sf, Shininess);

    lowp vec3 color = AmbientMaterial + df * Diffuse + sf * SpecularMaterial;

    gl_FragColor = vec4(color, 1);
}

Shifting work from the vertex shader to the fragment shader was simple enough, but watch out: we're dealing with the normal vector in a sloppy way. OpenGL performs linear interpolation on each component of each varying. This causes inaccurate results, as you might recall from the coverage of quaternions in Chapter 3, Vertices and Touch Points. Pragmatically speaking, simply re-normalizing the incoming vector is often good enough. We'll cover a more rigorous way of dealing with normals when we present bump mapping in the section called “Bump Mapping and Dot3 Lighting”.

Mimicking the built-in lighting functionality in ES 1.1 gave us a fairly painless segue to the world of GLSL. We could continue mimicking more and more ES 1.1 features, but that would get tiresome. After all, we're upgrading to ES 2.0 to enable new effects, right? Let's leverage shaders to create a simple effect that would otherwise be difficult (if not impossible) to achieve with ES 1.1.

Toon Shading (sometimes Cel Shading) achieves a cartoony effect by limiting gradients to two or three distinct colors, as shown in Figure 4.14, “Toon Shading”.

Figure 4.14. Toon Shading

Assuming you're already using per-pixel lighting, achieving this is actually incredibly simple; just add the boldface lines in Example 4.21, “ToonShading.frag”.

varying mediump vec3 EyespaceNormal;
varying lowp vec3 Diffuse;

uniform highp vec3 LightPosition;
uniform highp vec3 AmbientMaterial;
uniform highp vec3 SpecularMaterial;
uniform highp float Shininess;

void main(void)
{
    highp vec3 N = normalize(EyespaceNormal);
    highp vec3 L = normalize(LightPosition);
    highp vec3 E = vec3(0, 0, 1);
    highp vec3 H = normalize(L + E);
    
    highp float df = max(0.0, dot(N, L));
    highp float sf = max(0.0, dot(N, H));
    sf = pow(sf, Shininess);

    if (df < 0.1) df = 0.0;
    else if (df < 0.3) df = 0.3;
    else if (df < 0.6) df = 0.6;
    else df = 1.0;
    
    sf = step(0.5, sf);

    lowp vec3 color = AmbientMaterial + df * Diffuse + sf * SpecularMaterial;

    gl_FragColor = vec4(color, 1);
}

Note that we'll be loading resources from external files for the first time. Adding file resources to a project is easy in Xcode. Download the two files (micronapalmv2.obj and Ninja.obj) from the examples site and put them on your desktop or Downloads folder.

Create a new folder called "Models" by right-clicking the ModelViewer root in the Overview pane and choose Add→New Group. Right-click the new folder and choose Add→Existing Files. Select the two OBJ files (available from the book's web site) by holding the command key, then click Add. In the next dialog box, check the box labeled "Copy items...", and accept the defaults, then click Add. Done!

The iPhone differs from other platforms in how it handles bundled resources, so it makes sense to create a new interface to shield this from the application engine. Let's call it IResourceManager, shown in Example 4.24, “Adding IResourceManager to Interface.hpp”. For now it has a single method that simply returns the absolute path to the folder that has resource files. This may seem too simple to merit its own interface at the moment, but we'll extend it in future chapters to handle more complex tasks, such as loading in image files. Add these lines and make the change shown in bold to Interface.hpp.

#include <string>
using std::string;

// ...
struct IResourceManager {
    virtual string GetResourcePath() const = 0;
    virtual ~IResourceManager() {}
};

IResourceManager* CreateResourceManager();

IApplicationEngine* CreateApplicationEngine(IRenderingEngine* renderingEngine,
                                            IResourceManager* resourceManager);

// ...

We added a new argument to CreateApplicationEngine to allow the platform-specific layer to pass in its implementation class. In our case the implementation class needs to be a mixture of C++ and Objective C. Add a new C++ file to your Xcode project called ResourceManager.mm (don't create the corresponding .h file), shown in Example 4.25, “ResourceManager implementation”.

#import <UIKit/UIKit.h>
#import <QuartzCore/QuartzCore.h>
#import <string>
#import <iostream>
#import "Interfaces.hpp"

using namespace std;

class ResourceManager : public IResourceManager {
public:
    string GetResourcePath() const
    {
        NSString* bundlePath = [[NSBundle mainBundle] resourcePath];
        return [bundlePath UTF8String];
    }
};

IResourceManager* CreateResourceManager()
{
    return new ResourceManager();
}

/Users/username/Library/Application Support/iPhone Simulator/User/Applications/uuid/ModelViewer.app

/var/mobile/Applications/uuid/ModelViewer.app

The resource manager should be instanced within the GLView class and passed to the application engine. GLView.h has a field called m_resourceManager which gets instanced somewhere in initWithFrame, and gets passed to CreateApplicationEngine. (This is similar to how we're already handling the rendering engine.) So you'll need to do the following:

Next we need to make a few small changes to the application engine per Example 4.26, “Consuming IResourceManager from ApplicationEngine”. The lines in bold show how we're re-using the ISurface interface to avoid changing any code in the rendering engine. Modified/new lines in ApplicationEngine.cpp are shown in bold (make sure you replace the existing assignments to surfaces[0] and surfaces[0] in Initialize):

#include "Interfaces.hpp"
#include "ObjSurface.hpp"

...

class ApplicationEngine : public IApplicationEngine {
public:
    ApplicationEngine(IRenderingEngine* renderingEngine, 
                      IResourceManager* resourceManager);
    ...
private:
    ...
    IResourceManager* m_resourceManager;
};
    
IApplicationEngine* CreateApplicationEngine(IRenderingEngine* renderingEngine, 
                                            IResourceManager* resourceManager)
{
    return new ApplicationEngine(renderingEngine, resourceManager);
}

ApplicationEngine::ApplicationEngine(IRenderingEngine* renderingEngine,
                                     IResourceManager* resourceManager) :
    m_spinning(false),
    m_pressedButton(-1),
    m_renderingEngine(renderingEngine),
    m_resourceManager(resourceManager)
{
...
}

void ApplicationEngine::Initialize(int width, int height)
{
    ...

    string path = m_resourceManager->GetResourcePath();
    surfaces[0] = new ObjSurface(path + "/micronapalmv2.obj");
    surfaces[1] = new ObjSurface(path + "/Ninja.obj");
    surfaces[2] = new Torus(1.4, 0.3);
    surfaces[3] = new TrefoilKnot(1.8f);
    surfaces[4] = new KleinBottle(0.2f);
    surfaces[5] = new MobiusStrip(1);

    ...
}

The next step is creating the ObjSurface class, which implements all the ISurface methods, and is responsible for parsing the OBJ file. This class will be more than just a dumb loader; recall that we want to compute surface normals analytically. Doing so allows us to reduce the size of the app, but at the cost of a slightly longer startup time.

We'll compute the vertex normals by first finding the facet normal of every face, then averaging together the normals from adjoining faces. The C++ implementation of this algorithm is fairly rote, and you can get it from the book's companion website (see the section called “How to Contact Us”); for brevity's sake, pseudocode is shown in Example 4.27, “Pseudocode to Compute Vertex Normals from Facets”.

ivec3 faces[faceCount] = read from OBJ
vec3 positions[vertexCount] = read from OBJ
vec3 normals[vertexCount] = { (0,0,0), (0,0,0), ... }

for each face in faces:
    vec3 a = positions[face.Vertex0]
    vec3 b = positions[face.Vertex1]
    vec3 c = positions[face.Vertex2]
    vec3 facetNormal = (a - b) × (c - b)

    normals[face.Vertex0] += facetNormal
    normals[face.Vertex1] += facetNormal
    normals[face.Vertex2] += facetNormal

for each normal in normals:
    normal = normalize(normal)

The mechanics of loading face indices and vertex positions from the OBJ file is somewhat tedious, so you should download ObjSurface.cpp and ObjSurface.hpp from the book's website (see the section called “How to Contact Us”) and add them to your Xcode project. The ObjSurface constructor is shown in Example 4.28, “ObjSurface Constructor”, which loads in the vertex indices using the fstream facility in C++. Note that I subtracted one from all vertex indices; watch out for the one-based pitfall!

ObjSurface::ObjSurface(const string& name) :
    m_name(name),
    m_faceCount(0),
    m_vertexCount(0)
{
    m_faces.resize(this->GetTriangleIndexCount() / 3);
    ifstream objFile(m_name.c_str());
    vector<ivec3>::iterator face = m_faces.begin();
    while (objFile) {
        char c = objFile.get();
        if (c == 'f') {
            assert(face != m_faces.end() && "parse error");
            objFile >> face->x >> face->y >> face->z;
            *face++ -= ivec3(1, 1, 1);
        }
        objFile.ignore(MaxLineSize, '\n');
    }
    assert(face == m_faces.end() && "parse error");
}