Errata

The method in Matrix.hpp for multiplying two Matrices with signature:

Matrix4 operator * (const Matrix4& b) const

is implemented incorrectly. The result it gives for A * B is actually B * A (which is different because matrices don't commute).

In Quaternion.hpp, in the method with signature:

Quaternion::Slerp(T t, const QuaternionT<T>& v1) const

there is an error in the 'use linear interoplation for small angles' edge case. It results in Slerp doing animation backwards for small angles.

The line which reads:

QuaternionT<T> result = v1 + (*this - v1).Scaled(t);

should actually be:

QuaternionT<T> result = *this + (v1 - *this).Scaled(t);

Confirmed previous submission:

Its serious as the example will not run.

Linking in the OpenGL and Quartz Libraries:

The paragraph tells you to load OpenGLES.framework and QuartzCore.framework but since we started with OpenGL template they were already loaded. However,

I needed to explicitly load CoreGraphics.framework for CGRectGetWidth() and CGRectGetWidth() to work.
?

In that example GLView.h imports IRenderingEngine.hpp, but at its time GLView.h is imported by the app Delegate so inserting c++ code in a pure objective-c class and bringing in an error at the 'virtual' keyword of "struct IRenderingEngine* createRenderer1();"
I also submitted the case to the Apple Developer Forum where I was suggested to substitute the import with a forward struct declaration. Ref: EAGL rendering API a.

The LinearTween function as written has the opposite behavior as the charts in Figure 2.15.

It currently is printed as follows:

--- return t * start + (1 - t) * end;

This causes the value to tween from end to start as t goes from 0 to 1. Instead, it should be listed as this:

--- return (1 - t) * start + t * end;

This correction will allow the tween to go from start to end as t goes from 0 to 1 which is the expected behavior as reinforced by the graphic in Figure 2.15.

Please note that the QuadraticEaseIn function and the QuadraticEaseInOut function (Example 2-4) also rely on this function, so all three do not work properly as a result of this error.

Just the same mistake in linear tweening equation (should be read as "return (1-t)*start + t*end;", as Adam Behringer already mentioned), but i have it in ePUB edition.

After making the changes to RenderingEngine1 and RenderingEngine2 the rotate functionality became impaired.

i.e. OnFingerDown did not rotate to the new touchpoint
and moving did not match where you were touching.

... WireframeSkeleton project from this book's example code (available at http://oreilly.com/catalog/9780596804831)

should read http://examples.oreilly.com/9780596804831/
or
http://my.safaribooksonline.com/9781449388133?bookview=overview

However the WireframeSkeleton is not part of the example code!

Visual visual;
The address of this struct
is being passed to IRenderingEngine::Render as the address of a vector.

The directions state: "Example 4-10 shows the new Initialize method (unchanged portions are replaced with ellipses for brevity)."

Then code example is written as such:

void RenderingEngine::Initialize(const vector<ISurface*> &surfaces) {
vector<ISurface*>::const_iterator surface;
for (surface = surfaces.begin(); surface != surfaces.end(); ++surface) {

// Create 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);
}


Though this is a huge problem, because within this area, there should have been an ellipse as well:

// Create a new VBO for the indices if needed.
...
}

// ellipses should have been placed here

// Set up various GL state.

Following those instructions explicitly leads you to omit:

// Extract width and height from the color buffer.
int width, height;
glGetRenderbufferParameterivOES(GL_RENDERBUFFER_OES, GL_RENDERBUFFER_WIDTH_OES, &width);
glGetRenderbufferParameterivOES(GL_RENDERBUFFER_OES, GL_RENDERBUFFER_HEIGHT_OES, &height);

// Create a depth buffer that has the same size as the color buffer.
glGenRenderbuffersOES(1, &m_depthRenderbuffer);
glBindRenderbufferOES(GL_RENDERBUFFER_OES, m_depthRenderbuffer);
glRenderbufferStorageOES(GL_RENDERBUFFER_OES, GL_DEPTH_COMPONENT16_OES, width, height);

// Create the framebuffer object.
GLuint frameBuffer;
glGenFramebuffersOES(1, &frameBuffer);
glBindFramebufferOES(GL_FRAMEBUFFER_OES, frameBuffer);
glFramebufferRenderbufferOES(GL_FRAMEBUFFER_OES, GL_COLOR_ATTACHMENT0_OES, GL_RENDERBUFFER_OES, m_colorRenderbuffer);
glFramebufferRenderbufferOES(GL_FRAMEBUFFER_OES, GL_DEPTH_ATTACHMENT_OES, GL_RENDERBUFFER_OES, m_depthRenderbuffer);
glBindRenderbufferOES(GL_RENDERBUFFER_OES, m_colorRenderbuffer);


Which in absence makes the program draw a blank magenta screen.

This is a serious technical problem, since, though I found a quick fix to the issue, I don't know if this is the appropriate way to handle this now. I'm under the impression that we should no longer use the colorRenderbuffer since our implementation of the light sourcee; this code is clearly using the colorRenderbuffer.

What should be done here?

SimpleLighting.Vert
has three attributes
and seven uniforms

but RenderingEngine::Initialize
// extract the handles to attributes and uniforms

extracts six attributes
and four uniforms

the names are also 'out of sync' with the shader.

Review of the sample code ObjViewer
reveals the printed Initialize method to be incorrect.

Just noticed rowland shepard also reported this - here a few details on how to change to code so it works.

See Example 4-15 (SimpleLighting.vert) - it defines AmbientMaterial, SpecularMaterial and Shininess as uniform. On page 150, these three are incorrectly added to the attributehandles (instead of the uniformhandles struct). It should look like this:

struct UniformHandles
{
GLuint Modelview;
GLuint Projection;
GLuint NormalMatrix;
GLuint LightPosition;

GLint Ambient;
GLint Specular;
GLint Shininess;
};

struct AttributeHandles
{
GLint Position;
GLint Normal;
GLint Diffuse;
};

At the bottom of page 151 (continued of page 152) the relevant code should be changed to:

// Extract the handles to attributes and uniforms.
<...>
m_uniforms.Ambient=glGetUniformLocation(program, "AmbientMaterial");
m_uniforms.Specular=glGetUniformLocation(program,"SpecularMaterial");
m_uniforms.Shininess=glGetUniformLocation(program, "Shininess");

<...>

// and don't forget that it's not an attribute but a uniform now -
// so we have to change the gl-call also

// Set up some default material parameters.
glUniform3f(m_uniforms.Ambient, 0.04f, 0.04f, 0.04f);
glUniform3f(m_uniforms.Specular, 0.5, 0.5, 0.5);
glUniform1f(m_uniforms.Shininess, 50);


... after these changes, you'll see the specular white spot :)

Says Example 2-6 shows 'RenderingEngine1.cpp', should be 'RenderingEngine1.h' since it is the declaration not the definition.

Also the definition of Vertex is moved from the .cpp file, where it was in prior examples, to the .h file which (I believe, but I could be wrong) would conflict with the Vertex declaration in RenderingEngine2.h. Granted the paragraph above says the definition of Vertex is "moved higher up in the file" but that's hardly the case since it is in fact moved to the header file.

The function

Vector4<T> operator * (const Vector4<T>& b) const

Is multiplying incorrectly. It is setup to multiply column vectors, and not row vectors. i.e. It is multiplying Av and not vA.

This does not work as expected

mat4 m = mat4::Translate(2,3,4)
vec4 u = vec4(2,2,2,1)
vec4 v = m * u

v = 2,2,2,19

This function should be

Vector4<T> operator * (const Vector4<T>& b) const
{

Vector4<T> v;
v.x = x.x * b.x + y.x * b.y + z.x * b.z + w.x * b.w;
v.y = x.y * b.x + y.y * b.y + z.y * b.z + w.y * b.w;
v.z = x.z * b.x + y.z * b.y + z.z * b.z + w.z * b.w;
v.w = x.w * b.x + y.w * b.y + z.w * b.z + w.w * b.w;

return v;
}

The matrix library assumes row-major with row-ordering (i.e. transposed ordering rather than canonical). That's fine except that the library only provides an overload for matrix*vector, but not vector*matrix. However, in a row-major system, you can only multiply a vector to the left of a matrix (as the book itself explains early on). To require a vector on the right side of a matrix in a row-major library is a serious source of confusion and bugs. It's not clear if the calculation is actually doing what is expected.