Learning strict OpenGL3

1.- To upload data you use glBufferData :), but to specify the layout of the data, you can use generic vertex attributes.
2.- They're making it more programmable/generic at the cost of making it more hard to study. Just kill the Fixed Function Pipeline and all functions you named should be removed.
3.- Also AFAIK they're trying to make GL drivers simpler.

Quote:

Original post by Halifax2 First question: Why does OGL3 have glOrtho, glTranslate, glRotate, glScale, and the like, deprecated? It takes out all the matrix functionality as well by removing glMatrixMode, and other things. So they want you to manage your own matrices? That just doesn't make sense to me, and I don't know why they couldn't have kept that.

Because calling those function was 'slow' and was done in software anyway, as well as modifiy all manner of state. It is better to compute things yourself and then upload the final matrices to your shaders. It removes the CPU overhead of tracking state as well.

Not that it matters, because in GL3.0 these functions still exist, they will just be removed at 'some point' unless you use the 'foreward' context.

Quote:

Second question: They deprecated glColorPointer, glVertexPointer, glIndexPointer, and other things such as that, so how are you supposed to upload data to VBOs? Is there any way, with the current specification, that you can even render anything at all? How are you supposed to draw something?

You submit things by using the various GLSL API pointer functions. Instead of using the built in aliases you define your own varyings and hook your inputs into them.

Again, in GL3.0 these things do still exist however, see above statement.

Quote:

Third question: Is OGL3 just making things a s***-load harder? I mean honestly, why do they put the managing of almost everything on the user. Why should we have to manage the matrices, matrix stack, drawing, lights, materials, and everything like that. I guess it's good if you are writing a specific application, but won't the development of engines become increasingly more difficult?

Things are moved to the user because they have more information about the problem domain and can also remove redudant CPU overhead, such as state tracking.
As for managing all those things, here's the dirty secret; if you wanted any sort of performance you should have been doing this yourself already.

Good engine development is no harder than it already was simply because you should have been doing these things yourself if you want something even halfway decent. Even an 'engine' (which is probably going to be shit anyway unless you've made some games first) needs to manage these things with GL2.x, it's just people didn't and well.. see comment about things being 'shit'.

Quote:

Overall, they could have done better, even with the deprecation model, in my opinion.

Yes, they could have produced LP and life would be better.

As it is there is a 'testing' forward context which you shouldn't run your apps on and a vague plan to remove things when the vendors feel like it.

Quote:

Original post by HuntsMan 3.- Also AFAIK they're trying to make GL drivers simpler.

Apart from where they haven't because GL3.0 still supports GL2.1 and downwards, so currently GL3.0 has made things more complicated.

If you want to replace the matrix function, I have glhlib (LGPL)
http://www.geocities.com/vmelkon/glhlibrary.html

Search for glhLoadIdentityf2 and the rest in the header file.

I'm sure there are tons of other libraries as well. Yahoo is your friend!

Quote:

Original post by V-man If you want to replace the matrix function, I have glhlib (LGPL) http://www.geocities.com/vmelkon/glhlibrary.html Search for glhLoadIdentityf2 and the rest in the header file. I'm sure there are tons of other libraries as well. Yahoo is your friend!

Hey, thanks. I will definitely be turning to a library instead of reinventing the wheel.

But at any rate, something is still befuddling me at this point. Phantom points out the fact that I should be using vertex shaders, and pixel shaders to render my graphics in place of the fixed function pipeline.

Now let's say that I have a mesh with 6 vertices or so, and it is uploaded to the GPU in a VBO. Do I have to manually send the vertices individually to the vertex shader. And if so, doesn't that defeat the purpose of a VBO since you would have to copy the vertex to client memory, and then send it.

If that isn't what I have to do, then how do I specify the vertices, in which the shader should operate on, without the use of the fixed-function pipeline.

Now I realize the fact that OpenGL3 is just a deprecation model, I get it. But I would like to conform to that model by using strictly OpenGL3 non-deprecated functions, to be future-proof. So that is why I am trying to conform to the strict specification.

Without glVertexPointer and whatnot, use glVertexAttribPointer(http://www.opengl.org/sdk/docs/man/xhtml/glVertexAttribPointer.xml).

Quote:

Original post by phantom Apart from where they haven't because GL3.0 still supports GL2.1 and downwards, so currently GL3.0 has made things more complicated.

Yes, because the two code paths are obviously intertwined like sweaty lovers, and the logical thing to have done would have been to throw out all 2.1 functionality entirely. Right.

OGL3.0 has enough legitimate faults. There's no need to add spurious ones to the list. [smile]

So if the driver matrix stuff is deprecated, can someone recommend a free, optimized vectorized (SSE) matrix library to use instead?

Bullet has an SSE math library you could use.

sony also have one, google it

though dont be surprised if a lot of coded functions in sse2 are actually slower than plain c code, due to the data conversion