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.
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.
Well, far be it for me to stand in the way of progress.
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
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.
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
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.
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.
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…