If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Plus the approach to including the C++ support by mixing the operator overloads right into the C struct is just bad.

The way we dealt with it was that the core library was C but then we supplied C++ headers that subclassed the C structs (which IIRC is the approach that D3DX uses). That seems to work OK, but I don't use the C++ stuff so it's not actually really been tested that much (I find 3D math code written using the C functions is a lot clearer), my library is also just bog standard, non-optimized C, optimizing is on the list of things to do

Comment

And you know where it's all going to lead. Replacing crappy doesn't work 2d lcd with crappy doesn't work 3d lcd. I don't know about you but I'm DYING to go back to where you paid 450 bucks for a piece of junk that breaks 3 years later.

Comment

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 better or for worse, a lot of people use C++ for OpenGL programming. A lot of people, myself included, also use C. My goal is to provide broad developer support. Providing both rich C and C++ interfaces is the way I have chosen to do that. IMO, operator overloads for actual math functions is the only thing they are good for. Being able to write vector and matrix operations as 'v_eye = M_vp * v_obj' to transform a vertex from object space to eye space using a model-view matrix is very natural and clean code. It also allows you to write C++ code that looks almost identical to your GLSL code. That by itself is very compelling, I think.

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.

There are two primary goals for this project. One goal is to help people get into OpenGL faster. With all of the basic matrix functionality removed in OpenGL 3.1, the OpenGL learning curve is much steeper than it used to be, and it has always been fairly steep. The other primary goal is to provide high-performance interfaces for common sorts of graphics "grunt work." The current code base does not provide for this, but I think it is fairly straightforward to evolve it towards that goal.

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.

Since this is intended to be a statically linked library, I'm not too worried about feature creep. We can add whatever interfaces people need. I could definitely use help with portability. I'm primarily using this library on Linux, and my students use it on Windows. The Windows build gets a lot less exercise, and has been rough at times. The API is intentionally modeled after OpenGL itself. Given my years (almost 10!) on the ARB, I should be able to stick to that. I chose the BSD license specifically so that it could remain as a statically linked library that commercial apps could use.

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

This is an area that I'm much less interested in so far. I've been using SDL for my graphics class, and it has worked well. I believe that there is utility in this, but I think it will mostly be filled by EGL and OpenKODE. I've got my fingers crossed anyway.

Comment

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

It looks like you have some functionality that I don't have yet. I'd accept patches to implement, say, the matrix stack and quaternions. I put a structure in glu3.h for a matrix stack, but there is no implementation yet. I'm going to post about that on the glu3-devel list. Thanks for reminding me.