GLU3 1.0 Expected In About One Month
Phoronix: GLU3 1.0 Expected In About One Month
Going back to last April, Intel's Ian Romanick has been working on GLU3 and yesterday afternoon on his blog he has announced some changes. The GLU3 code-base has moved to a new FreeDesktop.org Git repository, there is now a project mailing list, and he expects to finally release GLU3 1.0 within one month or so...
Could someone be so kind and explain me what exactly is GLU library? Thanks!
Based on the name I expect a GLU replacement solely for OpenGL 3 and higher.
that's what it looks like. but what is glu? is it a competitor to glew?
ah, reporting news on topic that wasn't previously discussed, without any introduction to the subject. what's the point?
i don't want to sound annoying, but that's what i've seen a couple of times on phoronix already.
Well, let me chime in and ask what the heck GLU3 exactly is/does/replaces/...
Neither the article nor the blog give away those secrets.
I have no idea what any of this is about, but hey, at least it's not some rant.
OK, here's a bit more explanation:
The GLU or GL utility library is supplied alongside OpenGL to provide higher level functions (e.g. rendering Quadrics objects (spheres etc.), helper functions like gluPerspective etc.)
When OpenGL 3.0 came out it pretty much deprecated most of what GLu was based on. For example, the matrix stack was deprecated, and so GLu became pretty useless in a GL 3.x context.
I assume that GLU3 is the replacement for the original GLU, it looks like it has a load of math functions and replacement code for the deprecated matrix stack. This is really good news because I had to go out and develop my own math library ( http://www.kazade.co.uk/kazmath/ *) and this would have saved me that trouble
* Although if you are interested in it look at the bzr code in launchpad not the downloads
[quote]this would have saved me that trouble/quote]
Only if you have very low-end needs. I posted to Ian before about why his C++ wrappers are a bad idea (and yes, I am a C++ fan, not one of those C-only whiners) and why committing to that API is going to limit potential optimization work in the future. Plus the approach to including the C++ support by mixing the operator overloads right into the C struct is just bad.
For me personally (and Ian probably disagrees, and that's fine) I'd rather just see GLU disappear and see a nice open library (really open, not GPL) for high-end 2D/3D matrix math get endorsed instead. A library that is just a small core C API that can easily be heavily optimized with compiler vector intrinsics for x86/amd64/ppc/arm (all current compilers have a very hard time getting this right with C++ operator overloads, hence why it's not even worth it to support them). Give it all the usual 2D/3D matrix math along with the 3D projection calculation stuff, a matrix stack, etc. And yes, 2D is important. Most desktop apps are still 2D and even a lot of very popular games are entirely 2D (World of Goo comes to mind as one of the better examples, not to mention most of the handheld games), and 3x3 matrices take less space and time to use when you don't need the third dimension.
Most of the libraries out these that claim to fill that niche either suffer from severe feature creep, aren't portable, have alien API styles, are incomplete, or have offensive licensing.
I'd also really like to see a new GLUT that doesn't suck so hard. Something with an event loop the programmer actually has control over. I know we have SDL, but it has some other drawbracks regarding its other components (its input component causes issues on Windows with DirectInput and XInput, its audio system is borderline unusable, and its 2D drawing library literally _is_ unusable).