7
\$\begingroup\$

I've started learning how to use OpenGL a while back, using the OpenGL SuperBible, Fifth Edition, and I've had people arguing about the fact that the book doesn't really teach how to use OpenGL but instead it teaches how to use two of the wrapper libraries related to it, glut and glTools.

I've also been told that glut should never be used for full-blown projects, but there was no valid reason supplied with the argument.

My question is why, and when should I not use the glTools/glut libraries, and what should I use instead?

\$\endgroup\$

2 Answers 2

8
\$\begingroup\$

GLTools and GLUT are not the same thing. GLUT is responsible for dealing with things outside of OpenGL. GLUT creates and manages a window and an OpenGL context; the actual stuff that goes on within that context (aka: OpenGL) is not GLUT's responsibility.

Maik already covered the reasons why you don't see GLUT in serious applications. GLTools is another matter.

GLTools is just a framework, a wrapper around OpenGL stuff. There are many reasons not to use it in serious work:

  1. It's inefficient. If performance matters, you're going to want to sidestep it.
  2. It's not very good. Take the GLShaderManager for example. It either loads the shaders or returns 0. If there is a compiler/linker error, it gives no information on this. Yes, it writes the log to stderr, but not everyone has stderr piped to somewhere that is visible. Exceptions are rather harder to ignore.

I've had people arguing about the fact that the book doesn't really teach how to use OpenGL but instead it teaches how to use two of the wrapper libraries related to it

This is an aside, but generally the problem with regard to this is quite simple. 5th teaches you to use the framework before explaining what that framework is doing. So you learn how to use its mesh loading, how to use its perspective matrix generation code, its default shaders, etc, all before learning what a shader is, what vertex attributes are, and so forth.

It's basically fixed-function programming for the first part of the book. It just uses its own fixed-function code rather than OpenGL's.

It's not that it uses a framework that's the problem. The problem is that it uses the framework to hide details that haven't been explained, rather than to hide details that are unimportant to the current lesson. After you've seen the shader loading code a few times, you don't need to see it again, so it can be a library function.

A better way to structure the book would have been to use the pieces of the framework after showing the underlying OpenGL calls that the framework is doing. The standard set of shaders are fine, but it should use them only after the user has seen shaders in action manually. The same goes for mesh loading and handling, textures, etc.

\$\endgroup\$
2
  • \$\begingroup\$ Thank you very much, very exhaustive and insightful answer. \$\endgroup\$
    – kettlepot
    Commented Jul 20, 2011 at 18:16
  • \$\begingroup\$ I have the same feeling about the GLTools. It didn't explain what the library does, making me confused in the beginning. I was trying to figure what the heck the "stock shaders" were. Then I realized that those are created by the authors. All of a sudden, the interests in the book is significantly reduced. You suggestion in reconstructing the book is quite good. \$\endgroup\$ Commented May 11, 2016 at 8:33
3
\$\begingroup\$

The argument against glut in big projects is that you don't have access to the application loop, so you can't change it to fit your needs. All it has are some callbacks which are triggered from glut, but you don't have much control about it.

However, the purpose of glut is to create demos and test apps easily and cross platform, without the need to deal with ugly OS code to create windows, its just a question of some lines of code using glut.

\$\endgroup\$
8
  • \$\begingroup\$ Is it possible that using glut could harm portability also? \$\endgroup\$ Commented Jul 20, 2011 at 13:20
  • 1
    \$\begingroup\$ @3nixios Glut claims it "works across all PC and workstation OS platforms". If those are your target platforms, you're safe portability wise \$\endgroup\$ Commented Jul 20, 2011 at 13:37
  • \$\begingroup\$ I was indeed thinking about any platform not supported by GLUT. I was wondering what kind of an impact a late in the day change of target could have. \$\endgroup\$ Commented Jul 20, 2011 at 13:44
  • 1
    \$\begingroup\$ @3nixios a late change from PC/workstations to mobiles is practically impossible without rewriting a lot of code AND assets. GLUT will be your smallest problem, if you try anyway :) \$\endgroup\$ Commented Jul 20, 2011 at 14:03
  • \$\begingroup\$ Oh nevermind... \$\endgroup\$ Commented Jul 20, 2011 at 14:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .