What do you want in GLU?

OpenGL
1

I have not started a thread recently, so I though I would get people thinking on what they might like in a new GLU lib:

  1. bool gluIsExtensionSupported(const char *); - Check if an extension is supported. May seem dumb but prevents lots of silly miskakes with the extension string I have seen. (eg. Only doing sub-string matches, copying the string to pixed point areas etc) Also a wgl/egl version for platform extensions?

  2. bool gluIsVersionSupported(GLenum versionType, GLuint majorVersion, GLuint minorVersion); - Check if the version is supported. versionType can be GLU_OPENGL_VERSION, GLU_GLSL_VERSION etc…
    This should also catch some silly mistakes (like with the OpenGL 2.0 fiasco)

  3. Basic matrix Multiply/Translate/Scale/Transpose that was in OpenGL1.0 fixed function. Would be nice to have a few more math ops in there - vector3/4 and quaternions? Does not have to be fancy - just basic ops that cen be used when you don’t have a math lib?

Also curious of how people think GLU should be distributed with applications (like D3DX) or should be an installed system component?
(I prefer distributed with the app - at least on Windows)

2

Is GLU even something that can be extended?

3

I would like the new GLU to contain the layered immediate mode and some algebra manipulation functions. Basically the same sqrt[-1] said. Also, I would like the idea of custom (optimized) GLU implementations. Every machine should have a GLU library installed, but nothing should prevent an application of using an own GLU.

4

Originally posted by sqrt[-1]:
Also curious of how people think GLU should be distributed with applications (like D3DX) or should be an installed system component?
(I prefer distributed with the app - at least on Windows)
It is profoundly unlikely that Microsoft would agree to distribute a new GLU library, much less update it in the future (the same problem as with opengl32.dll today), so the possible avenues of distribution on Windows seem limited to (1) enduser download from opengl.org (2) package with ICDs (3) package with apps. There is no way to prevent (2) and (3) from happening, but we hope to focus on (1), to help minimize the number of obsolete and/or forked versions of the library in the wild. On Linux the situation is paradoxically both less controllable, and more likely to stay up to date, IMO, as long as we establish a good feed to the major distributions :slight_smile:

Comments on what should go in a new GLU are great - keep them coming!

5

Originally posted by Korval:
Is GLU even something that can be extended?
Shouldn’t be a problem, for the longs peak GLU that is.

I would like to see a few functions to create and bind VBO’s in a quick and easy way, especially if immediate mode is being layered.
something like this (not sure about exact syntax though).

gluCreateVBO(&vboVertics, verticArray, sizeof(verticArray));

gluBindVBO(GL_VERTEX_ARRAY,3,vboVertics);

6

but we hope to focus on (1), to help minimize the number of obsolete and/or forked versions of the library in the wild.
So you’re actually going to try to distribute a library? Good luck making that build on all those platforms.

In any case, there’s pretty much 2 ways to go with GLU for Longs Peak. One way is to wrap (very) commonly used features of LP-GL. The other way is to expose constructs that are being lost in Longs Peak (matrix stacks, simple shaders, etc).

I think a little of both is in order.

The simplifying wrapper functions should only create attribute objects. They should not create the actual finished object. The primary reason for this is that it allows someone to use extensions on that attribute object without giving up the nicety of the GLU function.

The two main areas where one would want to re-expose features for LP would be in terms of a couple of very simple, easy-to-use shaders (matrix transform with single texture with a uniform blend color, single color with matrix, variable color and position with a matrix, etc) and perhaps some kind of matrix stack object that can be used to produce matrices for said shaders. Matrix stacks should have standard GL-like matrix functions (rotate, translate, scale, projection, ortho, etc) and have a maximum length defined at stack creation time.

Both of the previous features are pretty simple to write, but would be of tremendous help, particularly just to get something simple up and running. Or for fonts and that sort of thing.

I don’t see a need for bothering to GLU vertex buffer creation. It’s simple enough as it is (like allocating memory). Further, if you were going to make vertex data simpler, I’d suggest getting immediate mode working, which is well beyond GLU.

And GLU should not be dealing with extensions at all. Nor should it be providing more generalized vector math operations (unless it’s going C++. There’s no point in a vector math library without C++).

7

Just a minor hint. Perhaps you could virtualize a thing or two it it’s allready a layer on top of OpenGL.
An example would be to emulate larger stacks. Quite easy to implement.
On the other hand I doubt anyone needs more than 32 matrices in modelview stack. That’s why it’s a “minor hint”. I’m posting it anyway. Perhaps it will give you some other interesting ideas.

And GLU should not be dealing with extensions at all
Yes. Unless it supports extensions fully (therefore becoming library like GLEW or GLEE) it makes no sense to provide partial solution since you still need to load functions and for that you would use an extension loading library which allready provides functions to test if extension is available.
As for testing OpenGL version - on Windows you have to load function pointers anyway so it’s still a job for extension loading library.

(unless it’s going C++. There’s no point in a vector math library without C++).
That’s right. One could implement vector library in C and other languages that aren’t object oriented, but no one would use it in C++ or Java so it makes no sense to add functionality that would be used by few.
On the other hand it could be convenient to have an object oriented vector math library distributed with GLU. Glu.h could contain additional #include only processed by C++ compilers (use #ifdef). In other languages it would be even simplier - no need to test if object oriented programming is supported in java packages, right? :slight_smile:
That’s branching though - GLU would have different functionality depending on programming language, but at least one is a subset of another.

Anyway, if there will be a vector support in GLU I wouldn’t like it to be too simple. Constructors, basic operators and some math functions are a must. Swizzlers would be welcome, but not by the means of methods, but operators. But that’s a bit fancy I guess… (well, I did it anyway in my framework)

8

One idea I’ll throw out there: would it make things better or worse if GLU was distributed as open source code vs. the traditional dll?

If it’s a layer anyway, I don’t imagine there would be anything proprietary or dangerous (e.g., not subject to GL error-checking) included, would there? And the immediate benefit is that end users need not ever touch GLU. Only developers need know about it.

I can imagine it resulting in a few GLU forks in time. But it would also make language-specific API easier to support – an easily ported version of GLU for each language people care about (GLU-C++ etc…) gives the best assistance for each language. And an official repository could hold the various flavors that might come up, so we developers can see what fits. I imagine extensions support might also become easier if a more frequently updated GLU-as-source folded that in too.

If it does include things like vector libraries, I agree C++ is a must, but templatizing the classes is also beneficial, which leans towards having more of GLU statically compiled into your app anyway.

That’s the only downside for me personally – a slightly bigger app/install size, since I currently don’t have to count the GLU32.DLL. But if the end user ever has to deal with GLU pain, then I’d rather bloat my official executable size a little to prevent problems.

So is the price of having more than one GLU out there too much to get the benefit of a really flexible/open GLU with no DLL issues for end users?

9

Originally posted by k_szczech:
That’s right. One could implement vector library in C and other languages that aren’t object oriented, but no one would use it in C++ or Java so it makes no sense to add functionality that would be used by few.
As i see it we only need a few simple extra things regarding matrix math in GLU (besides the ones we already have), multiplications, transpose and inverse, nothing fancy just so that you can take the return from glGetFloatv(GL_MODELVIEW_MATRIX, …); multiply it with another matrix you got the same way and then upload it again without having to resort to an external math library.
What we don’t need is an entire vector/matrix math library in glu, that is for others to fiddle with.

10

Originally posted by Korval:
And GLU should not be dealing with extensions at all. Nor should it be providing more generalized vector math operations (unless it’s going C++. There’s no point in a vector math library without C++).
I think open source is the way to go. There are many platforms and many languages to support.
Go ahead and make C++ classes. The majority of the people are C++ users, and then some java and C#

It should be made with beginners in mind.
I’m not likely to use it.

I think that provision must be made to use >GL 1.1 functionality. It’s time to move on from the basics crap

11

It should be made with beginners in mind.
I’m not likely to use it.
I totally agree on both counts, except I might actually use some of it IF it contains stuff like vector/math. I have my own, but there’s an added benefit if many libs built on GL can start using the same basic types, or at least the same API for those types. [see “generic functions in C++” for why.]

As for Jon’s previous comment on another thread that he and others on the ARB may not be C++ whizzes, I’d suggest having an ARB member simply be the “owner” of the sourceforge project(s), but ask for community volunteers to help design/code for the various languages. I’d be happy to help with the C++ variant, if needed.

Some overall guidance from the ARB would help to make the various language bindings conform to each other just enough to simplify the man pages. But the leg work can be outsourced pretty easily, IMO.

My goal is simply to get better C++ support in a more standard way, kind of like how STL isn’t right for everyone or every purpose, but it’s a huge accelerator for many people. For the C++ side of things, I’m thinking of this as a GLSTL GLU analog.

12

Also don’t forget we gotta add Kurt Akeley’s Lotus to GLU. Been waiting for that since '94.

http://www.opengl.org/about/arb/meeting_notes/notes/minutes_12_94.txt