Opinion Poll: GLU in production code


I’d like to get some opinions on the performance/image size penalties for using GLU in production code.

I hate using abstracted toolkits and high level APIs. As a windows developer by trade, this makes me somewhat of a hypocrite, but nonetheless, I stand by my philosophy.

At most, the only OpenGL header/lib/dll I want to link with is OpenGL32. The idea of using GLUT makes me shiver and glaux seems redundant, but where does glu fit in with all of this? I use gluPerspective() more than I’d like to admit, especially since I can get the same results with a few careful matrix operations.

Every time I include glu.h, a voice inside my head tells me I don’t care about NURBS, teapots, and simplified callbacks. While tesselations are attractive, and I’m assuming that gluSphere is optimized in more ways than I’d be able to code by hand, the question still reamins: should I be using this library in production code?

I’d really appreciate it someone could shed some light on the subject. Maybe I’m just being too anal


[This message has been edited by lpVoid (edited 02-06-2001).]

I do not really understand your problem: if you need tesselation, use GLU ! If you need gluLookAt, use GLU ! If you need perspective, use GLU !

Of course, you can do everything by yourself… You could even rewrite OpenGL (look at MESA !) but why reinventing the wheel all the time ???

Best regards.


It’s more of a best-practice/methodology opinion than a problem.

Basically, if I’m only using about 2-5% of the features found in the GLU library, is it worth using? While I know I’m sacrificing image size, am I sacrificing performance as well by using it? I guess a few simple benchmarks will give me that answer, but what I’m really looking for is how you all feel about using it.

GLU seems to provide a lot of hassle-free and platform independant utilities. In my experience, this usually resolves to slower performance. I don’t want to easily port my app to unix/linux and I don’t give a care about ease of coding and overloaded entry-points. What I want is optimized code for one platform, with absolute streamlining and control over every single bit of RAM. Linking to bloated and user-friendly libs usually results in more page-swapping that the programmer realizes, and this is what I’m hoping to avoid.

Another question: Is gluPerspective() faster/slower than glFrustum() and friends?

I guess the bottom line is that you wouldn’t write Quake using GLUT, but would you use glu? ( again, I could just dumpbin to find the answer, but I’m at work right now and that’s not something I want laying around on my HD )


[This message has been edited by lpVoid (edited 02-06-2001).]

You think about performance when using glu functions? Think about its functionality, and then try to guess how to achieve that. Look at etc. seem rather good, where I would avoid that tesselation (AFAIK it tesselates concave polygons). Sphere may be optimized, but I would put them as strips in a display list. NURBS are really nice curved surfaces, but I’d avoid to use it until it is in hardware. Usually I bet you should use your own functions for the latter ones, since then you’ve got the hand on all abstract optimizations, where glu code has to be general in some way.
After all, consider the glu to have a) supporting functions (gluLookAt for example) and b) cool easy to implement features (where their general case is probably faster written than you can, but general)

i understand your problem/question, 'cause i had/have nearly the same thoughts. i like it clear and compact as possible. if i code a 3d engine at nearly the same abstraction level like glu is, i hate it to mix different styles of writing code. so i do not use glu, because all stuff i would use, i can do myself with my own datastructs and less overhead of the function calls. btw i learn a lot doing this stuff again.

gluPerspective uses glFrustum. it first converts the parameters into the values needed by glFrustum and then calls it.

Good to know someone feels the same way I do about this. I agree with not wanting mixed styles as well. It seems like we’re all working towards that “perfect system”, and the fewer 3rd party components, the better.

I even prefer to write a model converter/importer over using any COTS solution. After a while, you get to be an expert cut-and-paster, but you still have complete control over all of your code.

In the last few months, I’ve been paying more and more attention to clock cycles and the number of instructions a function generates. Something like gluXXX really bugs the hell out of me because no matter what, I’ll never be able to alter it’s performance. This is a fact of life for a lot of code, but this is where the question of what is fluff and what is necessary really begins.


[This message has been edited by lpVoid (edited 02-06-2001).]

Profile, profile, profile!

if(app->GetPerforance() == ACCEPTABLE && app->GetImageSize() == ACCEPTABLE)
//ToDo. Write your own!


  • Nutty

You are really putting too much pressure on yourself

If your application isn’t finish and you are using some glu fonctions, then I am sure you have other stuff to do than re-writing utility fonctions. So don’t worry about it until you are finished.

Now, if your application is finished and a glufonction is your bottleneck then rewrite it!!!

You should always first code for simplicity and readability. We(programmers) are bad at finding bottlenecks just by looking at the code.

Some also look at performance of their program in debug mode!! Bad idea.

Think about it, is gluPerspective, which you probably call once or twice per frame really going to slow down your program?

Now, if program size also matters, then you could have another reason to write your own if you are only using gluPerspective. But again, you need to wait for a complete release compiled build to know whether the size is too big or not.

[This message has been edited by Gorg (edited 02-06-2001).]

I can think of one instance of when you would want to avoid using glu. And that’s when you want your app to support 3dfx minigl. Those mini implementations do not support any glu functions. I know that GLQuake avoided using glu (and I’d assume Quake2 and Quake3 do too).

That is definately sound advice.

Profiling as we speak, and the performance hit is virtually non-existant. However, by disassembling the executable, I’ve noticed that glu functions do indeed create many more MOV instructions than the pure gl functions do, which is no surprise. But as long as you keep division out of the call you shouldn’t have much to worry about.

You’re right, though, that there are more dominant bottlenecks to worry about than the glu functions, which aren’t really bottlenecks at all.

gluPerspective isn’t a function that needs to be called very often, and usually dosen’t require interactivity unless you’re simulating a zoom. So, thanks to all the responses, I’m comming to the conclusion that if it makes my life easier and keeps my hair one shade less grayer, use GLU.


[This message has been edited by lpVoid (edited 02-06-2001).]