Understanding OpenGL

Asked 12 years, 5 months ago Modified 12 years, 5 months ago Viewed 3k times

I have some fundamental points/questions about OpenGL, not all involving code but concepts as well. I
would be grateful if you could answer, affirm or expand on any of them. I warn you, some might be
15 naive, so please bear with me.

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.

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?
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.

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() . 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.

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? 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).

c++ c opengl

Share Improve this question Follow asked Nov 1, 2011 at 15:25

Doddy
1,311 1 17 31

2 This question is sometimes a bit vague, and should probably be split up into several different questions. – korona
Nov 1, 2011 at 15:31

Oh, my apologies; found an answer to (4) – Doddy Nov 1, 2011 at 15:44

2 Answers Sorted by: Highest score (default)

\ 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
19 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.

Share Improve this answer Follow edited Nov 1, 2011 at 20:33 answered Nov 1, 2011 at 15:43
datenwolf
161k 13 188 303

2 Thank you for taking the time to write this concise answer. I've now started reading the freeglut source code to find
out other unknowns! I would recommend others, who are curious, to also do this. – Doddy Nov 1, 2011 at 19:22

You can pass class instance methods to callbacks after you bind an instance with std::bind(&Foo::callback,
&instanceoffoo) afaik. – WorldSEnder Dec 13, 2014 at 1:31

1 @WorldSEnder: std::bind creates a C++ callable object. Essentially a class instance where the operator() is
coalescing the instance with the pointer to member to call it. But it ends you up with exactly the same problem you
started before, you just slapped a layer of the same problem on top of it: You have a C++ class instance and some
function to call with that instance. Now if you could pass a user defined void* for GLUT to pass into the
callbacks. But then you'd not need that std::bind, you'd just dynamic_cast<…>(ptr)->method(…) and be done
with it. – datenwolf Dec 13, 2014 at 2:37

stackoverflow.com/questions/13238050/… may solve this – WorldSEnder Dec 13, 2014 at 2:44

1 @WorldSEnder: Well, a possible solution. But you're still stuck in thinking C++. Think dirtier, don't try to solve this
with C++. And also not with C. It's time to do "bad" things, like creating code at runtime. Have a look at LibFFCall
and hopefully you'll see what I mean. Or DynCall which is the BSD equivalent. – datenwolf Dec 13, 2014 at 11:14

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.
6
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

Share Improve this answer Follow answered Nov 1, 2011 at 15:43

Martin
282 2 6