Don't worry I've briefly seen some code that demonstrates how to build matrices and with all the maths we did last year I have no excuse not to have it covered

One step at a time is best.

Indeed! ..Replace glTranslate() with glUniform3f() - Done

In C++, the choice between matrix[16] and matrix[4][4] comes down to which you like better. matrix[1][1] in the second is the same offset as matrix[4] in the first. The important thing to remember for openGL is that it is column-major in its memory layout (so array element 0 (or [0][0]) is row 0, column 0, but element 1 (or [0][1]) is row 1, column 0.

Sounds complicated, but something I'm eager to tackle - can't not really! This is port of call number one methinks as I have no replacement for the deprecated stack, and the one we use at university belongs to my tutor, so can't really use that.

using view/projection matrices you copied out of the stack with glGetFloatv

... I'll enquire my tutor and some sample codes about this - possibly need those matrices first?

work on building full model transforms (translation*rotation*scale) as well as your own view/projection calculations

I can do all these calculations in the vertex shader methinks, I just need to get the matrices in as uniforms

Basically, I need to figure out how to get the uniforms I need and how to pass them to the shader ( pretty sure I know this/have done this before ), make the shader class a bit more static so I can say "Give shader" in the GLModels Init, and then test!

I'll come back in a few days and let you know how far I've gotten, I've got a few beneficial labs in the weel that will be helpful with this.

Thank you my friend!

Okay, I have the shaders working - I can see a white aeroplane, with the colour just hardcoded into the shader for now.

I'm also in the process of replacing anything that can be replaced with GLM, with GLM, which is how I'm getting uniform matrices into the shader.. ( Anything on the runtime side of loading the model that is - so animation / transformations and such )

The problem I'm having at the mo is finding a decent camera tutorial
- the camera I have at the moment is locked to look at the model while zooming in and out and moving around it, and it makes use of Fixed Function bits and bobs..

Does anybody have a favourite (GLM ?) camera tutorial..?

A quick final question.. what is the difference between these two frustum calls? They produce different results..


GLdouble fW, fH;
fH = tan( (fovY / 2) / (180 * gl_PI) ) * zNear;
fH = tan( fovY / 360 * gl_PI ) * zNear;
fW = fH * aspect;

//glm::frustum(-fW, fW, -fH, fH, zNear, zFar);
glFrustum( -fW, fW, -fH, fH, zNear, zFar ); // <- deprecated


What i posted before was wrong, so here is something right:
http://gamedev.stackexchange.com/questions/12726/opengl-es-2-0-understanding-perspective-projection-matrix

Hmm... thanks for the nudge

i think you need 2 glfrustum calls (one for each Z-plane), but i could be wrong

That is completely wrong.

glm::frustum probably creates a perspective frustum directly for you with both planes
it could also create 6 normalized planes internally that you could do frustum culling with, such as bool glm::pointInFrustum(x, y, z)
(but i dont know the specifics)

I have no real clue what you are talking about.

All glFrustum did was creating a projection matrix that maps a capped world-space pyramid into [-1,+1]^3 and then implicitly calling glMultMatrix with that matrix (see the documentation). The reason glFrustum is deprecated is because modern OpenGL is no longer responsible for having a static projection/modelview matrix and applying it - you are now responsible for generating the matrices and sending them to your shaders as needed.
glm::frustum is identical to glFrustum as far as the creation of the matrix goes. Instead of multiplying it onto a global state that no longer exists, it returns that matrix as a glm::mat4 though so you can send it to your shaders.