Understanding OpenGL

\ 1. I understand that OpenGL is just a standard, as opposed to a piece of software. For example, 'getting' OpenGL actually involves getting a third-party implementation which doesn't necessarily have to be endorsed by Khronos.

Indeed.

\ 2. OpenGL usually refers to the combination of the GL utilities (GLU) and the GL utilities toolkit (GLUT). They have methods beginning with glu and glut, resp. and the 'basic' OpenGL methods, that begin with simply gl, are implemented by those that make graphics drivers, i.e. NVIDIA?

No. OpenGL is just the functions beginning with gl…. Everything else (GLU, GLUT) are third party libraries, not covered by OpenGL.

\ 3. I assume that glut methods are OS-specific helpers, for example glutKeyboardFunc() has to be, to interpret the keyboard. So if I wanted a more powerful alternative way to interpret keyboard input, I would just use the OS API. OpenGL itself is purely about graphics, but glut has this sort of thing since graphics is not much without real-time human control.

Correct. GLUT is a very minimal framework, so using something else is strongly recommended.

\ 4. It seems to me that glu methods may be identical to calling a series of lower-level gl methods. One example I would like to quote is glOrtho() and gluPerspective().

I think you refer to gluOrtho2D but yes, you're correct. glOrtho is a true OpenGL-1 function. In some way, gluOrtho2D is one of the most useless functions ever:

void gluOrtho2D(GLfloat left, GLfloat right, GLfloat bottom, GLfloat top){    glOrtho(left, right, bottom, top, -1, 1);}

They seem to me to have similar ways of working, but calculating perspective may be more complex, so gluPerspective() is for convenience, but might just resolve to some gl methods.

Right again, but it's actually quite simple:

gluPrespective(GLfloat fov, GLfloat aspect, GLfloat near, GLfloat far){    GLfloat a = 0.5 * atan(fov);    glFrustum(-a*near, a*near, -a*near/aspect, a*near/aspect, near, far);}

Starting with OpenGL-3 core, the whole matrix manipulation stuff has been removed. In any serious application it's of little use, since you'll manage the matrices yourself anyway.

\ 5. I have studied basic OpenGL using freeglut at university, and I keep having this vision of a 'hardcore' way of using OpenGL, using only low-level methods. I don't know if this is a totally naive thought, but is there a 'professional' way of writing OpenGL, to get out its maximum functionality? Like, presumably, game developers wouldn't use glutPostRedisplay() for example, right?

Yes this is possible and most game engines indeed do all the grunt work themself. There is libSDL, which also covers OpenGL. Personally I prefer GLFW or doing the stuff myself, indeed. However this does not change the way one uses OpenGL itself. But this is just infrastructure, and it's mostly just writing boilerplate code. As a beginner you gain only very little by not using an established framework. If your program makes heavy use of GUI widgets, then using Qt or GTK, with its embedded OpenGL widget is a reasonable choice.

However some projects are very hardcore, and implement the whole GUI with OpenGL, too. Blender is the most extreme example, and I love it.

It seems too easy and convenient, like it hides a lot of what is going on. I suspect this is also true for C++ since GLUT callbacks aren't friendly with methods in namespaces (as I've seen in other questions).

GLUT callbacks are okay with namespaces (a namespace is just a C++ compilation time thing). But what's not possible is passing class instance methods as GLUT/C callbacks.

You seem to have a pretty good notion of OpenGL and the tookit. Not sure what's more to tell. I guess (5) is really where one can comment on.

Depending what type of application you are building you are right in thinking that some will choose to build their application only using the native GL calls.

For example, if you build a single document app under windows that has an OpenGl view but also the standard menus and toolbars, there is a strong chance you will want to go straight for c++ and what you call "low level" api.

However, if you build a low paced game in full screen mode, there is no real reason why you should not use Glut or any other toolkit for that matter if it ease the development of your app.

The fact you use GLut or low level calls directly alone doesn't make the app better or worst :)

hope it help