GLU considered important

Dear OpenGL Programmers,

I have skimmed the new spec and looked at some of the presentations and other material about 3.2. It seems to me that it is a good idea to get rid of all of the not-so hardware related stuff like matrix algebra and OpenGL state wich may or may not be needed in a shader. It makes the spec more compact and clear and gives GL a lighter foot print.

The unfortunate effect is that we will all need to write some code to do things that were previously handled by GL. Now, someone will probably tell me that it is much better to write it yourself and that nobody needs glFrustum or glRotate anyways …

True … in a way … but right now with old-style OpenGL, writing a hello OpenGL world using fixed function shading is extremely easy!! I would argue that that the learning curve is becoming much, much steeper, and saying hello to the post 3.0 OpenGL world is far less trivial.

The main idea in this posting is that we could deal with this by making GLU richer.

GLU already contains many of the functions that have no relation to hardware. It should simply absorb more stuff from OpenGL. glRotate -> gluRotate. Of course, since the default OpenGL state does not exist any more, we need to explicitly transfer the matrix as a uniform, but that could be solved in many ways. GLU could do much more - it might for instance contain some strings for simple default shaders, so that newbies could get started quickly. When parametric surfaces start showing up, GLU could also absorb that easily.

In short, it seems to me that the recent changes to OpenGL are brilliant, provided that GLU absorbs much of what we jettison from the core library. Otherwise, we are leaving many people behind. These will then rely on libraries written by various developers who like to put their stuff online, but that is not as good as an “anointed” utility library which is likely to have more widespread acceptance. GLU is everywhere as it is.

Unfortunately, it seems the GLU spec is from 98, and I cannot find anyone writing about how much it needs to be updated and soon too. Does that mean you guys don’t agree? have I overlooked something? Or is GLU something neglected that needs to be given more priority (as I think :slight_smile:

  • Andreas

It makes a lot sense to me and I think you hare right: a GLU 2.0 would be great!

I don’t use GLU anymore because it is so obsolete. However, there is a lot of things that belong to the CPU side and GLU I think.

Is it a priority? I don’t know. I get used to not using it and I like to work this way so that the not portable layer stay tight. There are a lot of case where this is not relevant and where GLU could be very useful.

GLU is not a specification. It is a library. As such, someone needs to write it.

Khronos does not have a programming staff (or if they do, it is not particularly large). In order to get a test suite for OpenCL, they had to contract it out to others. So they simply don’t have the people to add anything to GLU.

Furthermore, GLU is just a library, like so many others that already exist. However “anointed” it may be, it is still just a library.

GLU isn’t going to get improved. So you should look to other solutions to your problems.

I quite agree with you Alfonse but there is a specification. I would just say, it’s not as formal than the OpenGL spec… or something.

http://www.opengl.org/documentation/specs/glu/glu1_3.pdf

Alfonse, you seem a little dismissive… That is fine, but let me point out that I am not looking for a solution to any particular problem of my own. I am merely, meekly trying to discuss a route which I think would make OpenGL more useful and, in particular, more accessible. Incidentally, it seems to be the route taken by D3D which has a large utility library not in the core API as far as I have understood.

You made an important point: We cannot expect Khronos to develop GLU2.0. That is probably true. You also pointed out that GLU is a library rather than a spec. Although GLU does seem to have some sort of spec, I think that you are also right that it is important to distinguish between a spec and a library.

It is, of course, a GLU 2.0 library we need. Something we could rely on being installed or at the very least supported on any platform supporting the normal (as opposed to ES) OpenGL.

It should probably be an open source initiative, and hopefully one that would be sponsored by the members of Khronos…

However, I think at this point it is more important to discuss the need for a GLU 2.0. It is my impression that since OpenGL 3.2 does not know the notion of a normal, a hello OpenGL world program drawing, say, a shaded tetrahedron would be a big effort.

If you are maintaining a large code base, the lack of a standard utility library is probably not much of an issue. But for people new to graphics programming and people with small projects, I do believe it is a problem. A big problem, in fact.

Incidentally, it seems to be the route taken by D3D which has a large utility library not in the core API as far as I have understood.

D3D is managed by Microsoft. They are staffed primarily by programmers. So they can build and maintain a large utility library that is not in the core API.

OpenGL has no similar body to do so.

If you are maintaining a large code base, the lack of a standard utility library is probably not much of an issue. But for people new to graphics programming and people with small projects, I do believe it is a problem. A big problem, in fact.

Your belief that it is a problem hinges on the belief that “deprecation” is something real and legitimate. That somebody is going to actually implement 3.2 core without the 3.2 compatibility also being available.

This is not going to happen. NVIDIA has seen to it.

So feel free to use all of those bits of OpenGL that are marked deprecated.

Agreed, that would be nice. The “anointed” (as Alfonse put it) and available-everywhere library. Providing a canonical set of matrix routines for examples programs and tutorials, for instance. Ensures that simple tutorials stay simple and similar. As-is, GLSL 1.4+ tutorials have a lot of useless “baggage” they have to bring with them to do much.

But there is the practical development/maintenance issue mentioned.

I’d be willing to help with development of something like this, but I can see where it’d go. We’d all have our own ideas how it should work and what the interface would be. Lots of wrangling. To quell alot of that, I’d say it should be a C library (like GLU) with maybe a thin C++ wrapper, designed for convenience, and source freely available under a MIT-type license, not unlike GLUT.

Though maybe somebody’s already done this.

Having this library provide a shader generation library that supports generating shaders for the entire fixed-function pipeline (or most of it anyway) would be useful too, and educational. Training wheels for coaxing folks off the FFP and this GLU++ layer.

It is true that MS has an advantage when it comes to writing libraries. I never said this would be an easy endeavor which Khronos should just take upon itself and as Dark Photon points out, there could be lots of wrangling ahead. It would probably have to be a community effort. I just feel that a canonical/anointed/standard library would hold tremendous benefits for all OpenGL users.

Alfonse, what is your source for the interesting information that deprecated stuff is going to stay in OpenGL? How precisely has NVIDIA “seen to” that?

It does somewhat mitigate the problem, but still I think there could be enormous advantages to a GLU which is built on top of the core OpenGL library with e.g.

  • matrix code (transformations and perspective).
  • Light sources.
  • standard GLSL shader (that can see the matrices and light sources as uniforms)
  • parametric surfaces.
  • polygon tesselation.
  • simulated immediate mode and display lists.

One advantage would be that we could, in fact, at some future point get rid of the compatibility profile. Another would be that since GLU 2.0 (or whatever it should be called)
wouldn’t have to look exactly like the OpenGL compatibility mode, it could be made better and more efficient.

The GLM lib is already a start, for the math, matrices, etc :
http://glm.g-truc.net/about.html
http://glm.g-truc.net/code.html

I don’t want to put a dumper to such efforts, but unless this GLU 2.0 is installed on all platforms by default (maybe distributed along with OpenGL drivers?) it won’t be a real GLU replacement.

In fact, you can already find libraries that implement all of the above, so the only value is putting everything in one place (I’m not saying that the value of this is small, but the main advantage of GLU is that you can rely on it being preinstalled everywhere.)

I could not agree more. This is precisely why I think this hypothetical effort needs to have some kind of formal “blessing” as the successor to the more or less obsolete GLU 1.3.

Only if the library is perceived, essentially, as the CPU counterpart to the OpenGL drivers, is it likely to be installed almost everywhere.

GLU is great for starters and every API needs a way to get folks in and coding as quickly as possible, as part of good public relations.

But again who’s going to finance, code and maintain it? And besides the expense, what form should it take and who’s to decide? Part of the quagmire going forward is that more and more traditionally “CPU” related tasks are being offloaded to compute. So in trying to please everyone chances are you’ll please no one, besides the beginners that have little or no initial choice; likely the very same folks that’ll be the one’s saying “oh yeah, that new GLU is great… for beginners. But what you really want to do is…”. ;-D

Besides, am I missing something here? Isn’t part of the fun of learning to program figuring this stuff out for yourself? Sure we all need help getting our feet wet, but nowadays the net is bristling with so much content all you really need is a page with all the relevant links provided (if I’m not mistaken such pages already exist, e.g. Real-Time Rendering, etc.).

Check the FAQ at the bottom of this page:
http://developer.nvidia.com/object/opengl_3_driver.html

Check the FAQ at the bottom of this page:
http://developer.nvidia.com/object/opengl_3_driver.html [/QUOTE]
Also, see slides 32-38 here:

The matrix ops are nice to have (back), but the bigger things from GLU for many are NURBS and tessellation. The tessellation of non-convex polygons is worth while having and GLU has that, implementing your own tessellator is bit of pain.

It would have been a good idea a long time ago. Since everyone has their own solution now, would you start using something new for your future projects?

GLU is preinstalled on systems? Who cares. A DLL doesn’t need installation.

And the point that someone already made : style. Everyone has their own style. Mine is
float matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, x, y, z);

I don’t like GLM. Does it have to have namespaces? GL doesn’t have a namespace and neither does GLU.

namespaces are our friends. gooood namespace. :slight_smile:

Huuummm

glLoadIdentityf
gluPerspective

GL and GLU don’t don’t have namespace? Oo
These are namespaces for the C language.

ok, fine. I like the “namespaces” of GL and GLU. You are in my heart. I will always love you.

GLU is preinstalled on systems? Who cares. A DLL doesn’t need installation.

If you are targeting 32bit Windows, fine. If you are going cross-platform, you’ll need builds for 32bit and 64bit version of Windows, Linux, Mac OS X at the very least. Extra pain if you are going for non-x86 CPUs, too, and double extra if you are not using C or C++ (great, now you have to introduce an ugly non-portable dependency into your C#/Python/whatever build).

GLU doesn’t suffer from this, it’s already there when you need it. Too bad it’s useless nowadays.

In any case the only remotely useful part of GLU is the NURBS and tessellation stuff. NURBS are trivial to re-implement by hand - tessellation not so much. Does anyone know of any permissive, open-source projects that implement this? I’ve only been able to find GPL/LGPL ones, which are very useful (to me, at least).