PDA

View Full Version : GLU considered important



baerentzen
01-25-2010, 06:23 AM
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 :-)

- Andreas

Groovounet
01-25-2010, 06:42 AM
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.

Alfonse Reinheart
01-25-2010, 11:31 AM
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.

Groovounet
01-25-2010, 11:36 AM
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

baerentzen
01-25-2010, 02:34 PM
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.

Alfonse Reinheart
01-25-2010, 05:05 PM
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.

Dark Photon
01-25-2010, 05:26 PM
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.
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.

baerentzen
01-26-2010, 02:31 AM
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.

ZbuffeR
01-26-2010, 03:50 AM
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

Stephen A
01-26-2010, 04:52 AM
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.)

baerentzen
01-26-2010, 05:33 AM
[...] the only value is putting everything in one place [...] 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.

Brolingstanz
01-26-2010, 07:23 AM
...

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

...

Heiko
01-26-2010, 07:32 AM
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?
Check the FAQ at the bottom of this page:
http://developer.nvidia.com/object/opengl_3_driver.html

Dark Photon
01-26-2010, 07:43 AM
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?
Check the FAQ at the bottom of this page:
http://developer.nvidia.com/object/opengl_3_driver.html
Also, see slides 32-38 here:
* OpenGL 3.2 and More (NVidia, Kilgard, 9/30/09, GPU Tech Conference) (http://www.slideshare.net/Mark_Kilgard/opengl-32-and-more)

kRogue
01-27-2010, 02:34 PM
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.

V-man
01-27-2010, 09:41 PM
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.

Brolingstanz
01-28-2010, 02:37 AM
namespaces are our friends. gooood namespace. :-)

Groovounet
01-28-2010, 04:00 AM
Huuummm

glLoadIdentityf
gluPerspective

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

V-man
01-28-2010, 06:54 AM
ok, fine. I like the "namespaces" of GL and GLU. You are in my heart. I will always love you.

Stephen A
01-28-2010, 10:01 AM
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).

Brolingstanz
01-28-2010, 10:56 AM
Hey there's all sorts of cool stuff in glu.h, like matrix helper funcions, mipmapping utilities, quadrics, various prefab shapes, nurbs and tessellation - what every GL coder needs to hit the ground running.

Stephen A
01-28-2010, 11:28 AM
But it's missing the really useful stuff, like image decoders, model loaders, real modern OpenGL support (it's immediate-mode only...) That's stuff you get out of the box in D3DX and it's what would *really* help beginner GL coders.

Besides, I wouldn't say quadrics, nurbs and tessellation as beginner stuff either.

Brolingstanz
01-28-2010, 11:58 AM
Well, far be it for me to stand in the way of progress.

baerentzen
01-28-2010, 04:04 PM
It seems that many (not all) would think of a new GLU as an advantage if (and only if) it is installed with the OpenGL API.

However, some interesting issues have turned up in the discussion:

As was pointed out, NVIDIA plans to retain the deprecated parts of OpenGL indefinitely since, obviously, NVIDIA's customers rely on these deprecated features and don't care to rewrite their applications. Moreover, many deprecated features are useful and, in fact, frustration with deprecation was also really what motivated this thread. I thought that things would really go away, and, for my money, display lists are the best way to do retained mode graphics, and I rather like accessing OpenGL matrix state in shaders. etc. etc.

On the other hand: If deprecated features like display lists and glRotate etc. were to migrate to GLU, we would have a nice division between a CPU bound API and a hw driver interface, namely the core profile API.

But, and this is the problem, if the compatibility profile is retained by major vendors, it means that the new GLU and the compatibility profile would provide two different ways of doing the same things. That is potentially confusing and a reason not to move compatibility profile parts of the API to GLU.

Stephen A mentioned another issue that I think is important: The direct3D crowd have asset loading tools in their standard library. Such features in glu would without doubt be of great use to many people. We all implement need loaders for assets, and a one stop standard solution would clearly be an advantage. Just like the STL is a great advantage to C++ programmers because we can rely on it. Excuse me for belaboring the point, but it is really the only one :-)

Thus, one strategy could be:

- Incorporate new features in GLU. For instance asset loading capabilities. However, do _not_ include the matrix stuff and display lists and whatnot from the OpenGL compatibility profile.

- Make it clear that nobody is _really_ going to throw out the deprecated features. For instance by calling the compatibility profile the "extended" profile :-)

V-man
01-29-2010, 05:56 AM
I don't think Khronos will do all that, if that's what this thread is about. I don't think it will be included in drivers either, if this is what the thread is about.
If this thread is about, "me, I want to extend GLU"
GLU is filed under the SGI license http://oss.sgi.com/projects/FreeB
Software License B, Version 1.1

and if you go into it, read section 2.1

1.License Grant and Restrictions.
2.1.SGI License Grant. Subject to the terms of this License and any third party intellectual property claims, for the duration of intellectual property protections inherent in the Original Code, SGI hereby grants Recipient a worldwide, royalty-free, non-exclusive license, to do the following: (i) under copyrights Licensable by SGI, to reproduce, distribute, create derivative works from, and, to the extent applicable, display and perform the Original Code and/or any Modifications provided by SGI alone and/or as part of a Larger Work; and (ii) under any Licensable Patents, to make, have made, use, sell, offer for sale, import and/or otherwise transfer the Original Code and/or any Modifications provided by SGI. Recipient accepts the terms and conditions of this License by undertaking any of the aforementioned actions. The patent license shall apply to the Covered Code if, at the time any related Modification is added, such addition of the Modification causes such combination to be covered by the Licensed Patents. The patent license in Section 2.1(ii) shall not apply to any other combinations that include the Modification. No patent license is provided under SGI Patents for infringements of SGI Patents by Modifications not provided by SGI or combinations of Original Code and Modifications not provided by SGI.

baerentzen
01-30-2010, 02:49 PM
I don't think Khronos will do all that, if that's what this thread is about. I don't think it will be included in drivers either, if this is what the thread is about.
If this thread is about, "me, I want to extend GLU"


Just to clarify:

This thread was about making a suggestion for a future release of OpenGL: A new GLU that matches the new GL - as well as discussing what should go into a new GLU. A bit frivolous, no doubt.

I do not want to extend GLU (but wouldn't mind helping). Were I to do so, it would be yet another homegrown library that people could never rely on being compiled for, much less installed on, their target platform. To ensure that it is something to be relied on, a new GLU would need to have a spec (or interface) approved by the ARB just like the old one.

However, it is probably not likely that an updated GLU will be written as long as we essentially have to GLs: core and compatibility.

Anyhow, I learnt something and still believe a new GLU would be desirable, should target the core, and might be instrumental in luring many people from compatibility to core.

thanks

Andreas

Brolingstanz
02-01-2010, 10:29 AM
As was pointed out, NVIDIA plans to retain the deprecated parts of OpenGL indefinitely since, obviously, NVIDIA's customers rely on these deprecated features and don't care to rewrite their applications. Moreover, many deprecated features are useful and, in fact, frustration with deprecation was also really what motivated this thread. I thought that things would really go away, and, for my money, display lists are the best way to do retained mode graphics, and I rather like accessing OpenGL matrix state in shaders. etc. etc.

I think it unlikely any perceived frustration was ever really about deprecation for the sake of a cleaner API (though that’s always nice), but rather deprecation for the sake of more reliable drivers overall; the idea being that if the API gets a cleanup drivers will suddenly become easier to write and maintain and therefore less prone to bugs.

Anyways, clearly vendors with a conspicuous history of stability are excluded from this line of reasoning. If, say, NVIDIA sees fit to maintain support for this or that then that’s their business; but that in no way impinges on the API as it stands or its ability to move forward. This after all is one of the pillars of deprecation to begin with, to allow NVIDIA or anyone else to do this sort of thing.

Alfonse Reinheart
02-01-2010, 11:23 AM
Anyways, clearly vendors with a conspicuous history of stability are excluded from this line of reasoning.

If every OpenGL 3.2 application requires the compatibility profile, then no IHV will be able to not implement the compatibility profile. At which point, there is little practical benefit from the core/compatibility split.

Brolingstanz
02-01-2010, 11:56 AM
In my view the market should decide such things.

If the market favors compatibility, so be it. If on the other hand start-up XYZ produces product “SaucySoft” that no one alive can live without and that product just so happens to use the core profile exclusively, then (start-up) vendor ABC may be inclined to throw more/all resources at ensuring the core profile is up to snuff.

Vendors want the software people use to shine on their hardware; it’s then just a matter of what software people are using and on what hardware...