haegarr

Let aside whether using quaternions makes sense in your use case, IMO your code snippet shows a construction flaw:

...
D3DXVec3TransformCoord(&forward, &forward, &matYaw); D3DXVec3TransformCoord(&right, &right, &matYaw); //Apply the yaw transformation to the relevant vectors
D3DXVec3TransformCoord(&forward, &forward, &matPitch); D3DXVec3TransformCoord(&up, &up, &matPitch); //Apply the pitch transformation to the relevant vectors
D3DXVec3TransformCoord(&right, &right, &matRoll); D3DXVec3TransformCoord(&up, &up, &matRoll); //Apply the roll transformation to the relevant vectors

OrientationMatrix *= matPitch*matYaw*matRoll; //Adjust the orientation matrix

The 3 row vectors of a rotation (row) matrix already define the side, up, and forward vectors of the local frame w.r.t. the parental frame. That means that your vectors right, forward, and up are logically part of your OrientationMatrix.

Now, you compute the new OrientationMatrix as:

  OrientationMatrix_n+1 = OrientationMatrix_n * matPitch * matYaw * matRoll

But you compute the new vectors as:

  OrientationVectors_n+1 = OrientationVectors_n * matYaw * matPitch * matRoll

That is obviously not the same when remembering that matrix multiplications isn't commutative. Hence the both orientation representations you use will be different, although logically they should be the same.

I've read a bit about them and it seems like they hold 4 values only - an axis and an angle.

Yes: Quaternions are defined by 4 scalars. No: They don't hold an axis and an angle. There is another rotation representation that is called "axis/angle representation" and that actually hold, well, an axis and an angle. IMHO it is best not to try to interpret some geometric meaning into quaternions; look at them as being a mathematical construct in your toolbox.

In fact, each representation has some degree of freedom: In 3D, a rotation matrix has 9, a quaternion has 4, an axis/angle has 4. Because rotation only has 3, you need to enforce some constraints on the representations, or else your representation doesn't mean a pure rotation.

In the case of rotation matrices the column/row vectors are pairwise orthogonal and each one is a unit vector. Hence the process of "re-ortho-normalization", which carries both orthogonalization as well as normalization in its name.

In the case of quaternions they need to be of unit length. Hence, to be precise, one has to talk about "unit-quaternions" and not just quaternions when referring to pure rotation.

Because of this, quaternions are not less prone to numerical errors per se, but they are more stable in that numerical imprecision has less effect on still representing a useable rotation. So re-normalisating quaternions needs to be done less often, and ensuring that single constraint is less work than ensuring the 6 constraints on rotation matrices.

That said, using quaternions and re-normalization (from time to time) and on-the-fly to-matrix conversion would be sufficient for sure.

What I don't understand is how I can use a quaternion to hold the entire orientation of my object?

The problem of lacking a geometrical interpretation suitable for humans, doesn't mean that unit-quaternions don't work. A unit-quaternions "holds the entire orientation" by its nature. Use conversions from or into, resp., other rotation representations where meaningful.

Sorry for confusion. A position is an absolute co-ordinate tuple, with respect to a reference point, while a translation is a relative one, just with a direction and distance. Similarly, an orientation matrix is absolute, while a rotation matrix is relative. Computationally there is no difference between an absolute or relative matrix. It is just a question of interpretation.

So, start with the identity matrix as the orientation. This means "rotate to, err, ... as is". Then multiply that with a rotation matrix. This means "rotate by, e.g., 10° yaw". You yield in a new orientation matrix. Multiply that by with another rotation matrix. This means "rotate by, e.g., 5° pitch". You yield in a new orientation matrix. And so on.

A story is a sequence of events happening in the view (to be understood in a wider sense) of the player. To ensure that the player notices the events, they are usually not running detached but being enabled by requirements on the world state, and perhaps being triggered by the player. During happening and at its end, an event often alters the world state, so being able to enable or disable other (not yet happened) events. This way a sequence or even branches can be defined.

The world state is the entirety of variables describing, err, the state in which the game world is. E.g. a boolean flag for the life/death of an opponent belonging to the story, a counter for how often the player has hit a target, a flag whether or not a specific NPC has told the player about the hidden secret, ... whatever.

Triggers can be any action a player is able to perform. Colliding with a collision volume can be used as a location based trigger, or the death by shot of an NPC can be a trigger. On the other hand, the expiration of a timer can be a trigger, too, e.g. allowing for deferred events. Triggers can be implemented as a mechanism which alters the world state.

The player usually needs be hinted at how to trigger enabled events, or else s/he may not realize what to do next. How to do this depends on the type and style of the game. Briefings, books, journals, gossip, talks, ... by NPCs, a companion, the HUD, ... and so on. This can also be implemented as events in the way described above.

There isn't necessarily the need to explicitly track the current chapter in the story. The world state already reflects this.

As Tasche already explained, is a pure rotation matrix required to be ortho-normal. It is possible to interpolate rotations without using quaternions, but following Dave's argumentation (in this PDF located on its famous Geometric Tools site), performancewise it is a slightly less effective way.

Well, looking a the interpolation methods slerp and nlerp, both have their advantages as well as disadvantages. nlerp is faster to compute (always good) and is commutative (less problematic when arranging animation tracks). But it lacks linearity in the interpolated angle, or, in other words, constant angular velocity. In the extreme case the resulting quaternion will vanish. That are the reasons why nlerp should be used with relatively small difference angles only.

I want 2 VBOs but how? If I bind one buffer and then the next will the first buffer not be unbound? Or is it enough to bind the buffer, set the vertex attrib pointers and then unbind it again before the draw call?

With a little bit of clean-up, what's about the hopefully-now-considering-all-caveats-solution:

Matrix4x4 createView( Vector3* pos, Vector3* target, Vector3* up )
{
   Matrix4x4 cameraMat;
   Matrix4x4 view;

   Vector3 vX;
   Vector3 vY;
   Vector3 vZ;

   // computing vZ as the unit vector to look along
   vZ = sub(pos, target);
   normalise(&vZ);

   // computing vX being orthogonal on the plane of up and vZ; considering
   // its place in the ortho-normal basis later, this means up x vZ
   vX = crossProd(up, &vZ);
   normalise(&vX);

   // computing vY being orthogonal on the plane of vZ and vX; considering
   // its place in the ortho-normal basis later, this means vZ x vX
   vY = crossProd(&vZ, &vX);
   normalise(&vY);

   // building basis ...
   setColv(&cameraMat, 0, &vX, 0.0f);
   setColv(&cameraMat, 1, &vY, 0.0f);
   setColv(&cameraMat, 2, &vZ, 0.0f);
   // ... and injecting position
   setColv(&cameraMat, 3, pos, 1.0f);

   // inverting camera matrix to yield in the view matrix
   view = inverseMat4(&cameraMat);

   return view;
}

void setColumnV( Matrix4x4* m, int colNum, Vector3* v, float w )
{
   int index = colNum * 4 + 0;
   m->m.m1[index] = v->x;
   m->m.m1[++index] = v->y;
   m->m.m1[++index] = v->z;
   m->m.m1[++index] = w;
}

1. Thanks, I will rename it to "target"
2. I guess so

3. Because i'm using C I can't overload operators.

4. It should be fine, here's the code:

5. A little further down in the function I call setEqual which initialises the left parameter to the right parameter; In this cals rowY gets set to the up vector.

6. I'll need to change this because my rowX is currently the cross of up and rowZ.

7. I think I might be treating rows as columns because opengl is column-major.

8. Brain exploded! So it should just be called the view matrix then?

If you mean you want 2 buffers, the vertices, and lets say colors to tell you the color of the vertex (you only need a boolean or something like that but i thought it would be nice to be able to use different colors etc. for other things) you can probably do it using a VAO

Indeed is it possible to pass the geometric vertex attributes in one VBO (still sticking to VBOs here because the OP mentioned them explicitly) and the color attribute in another one, assembling them on the GPU to yield in the full featured vertex. This is more a question of how the selection is encoded when sighted from the GPU side. For example, the selection can be processed on the CPU in a way that writes the color in dependence to the selection state into the 2nd VBO. This would allow to load just the color to the graphics card instead of the entire vertex data. However, whether this makes sense depends on the purpose of the selection: In an editor it is probable that the geometry is changed on the selected vertices. Hence loading the geometry as well may be done anyway, so that splitting into 2 VBOs may introduce needless work.

... If the named attribute variable is not an active attribute in the specified program object or if name starts with the reserved prefix "gl_", a value of -1 is returned.