Those of you that have experimented with, or use Direct3D regularly may have noticed that compared to OpenGL you get a lot of stuff "for free". Things like maths classes, support for texture formats and .X files, fonts etc. I've been thinking recently about developing similar functionality for OpenGL in the form of a helper library. A few weeks back I pretty much spontaneously started writing something like this, but I didn't exactly do much design (or even any) and I didnt get very far. What I did do can be found here if you're interested. Now I'm considering tackling this again, this time with a list of features I want to implement from the start and a proper design. What I would like to know is what do people think would be useful in this kind of library? I'd like you to think about what do you find yourselves writing every time you start an OpenGL project, and especially what would save you time if it was already there. Here's a basic list of stuff that I plan to implement but I want far more than this:

• 2D, 3D, 4D Vector classes
• Matrix classes
• Some kind of model support (MS3D?)
• Targa, BMP, (JPEG?) image loading.

Any ideas or thoughts? Luke.

Very few OpenGL developers will want to be tied in to one model format, so I don't think that belongs in a general helper lib. I also think that images should be handled by a dedicated image lib, of which there are many already existing.
Math classes would definitely be welcome, but you might want to include Quaternions as well.
What also might be very welcome is buffer and texture management classes, rather than having to manipulate OpenGL ids directly.

Not to discourage you, but I think you may find that while a lot of Beginners are interested in this functionality, many others will prefer to maintain their own math libs, low-level gl wrappers, etc.

Quote: Not to discourage you, but I think you may find that while a lot of Beginners are interested in this functionality, many others will prefer to maintain their own math libs, low-level gl wrappers, etc.

Well, as NeHe is for beginners, lots of people writing their first few openGL apps (and perhaps first apps ever) will be really glad if they don't have to figure out which lib to use for textures and which for maths and so on..
I think it would be best to have a lib that solves problems of beginners and can do some work for advanced coders, but for really big projects like an engine you should know to write all this by yourself in the way you need it anyways. On the other hand you're right, for most problems there already is a lib which does exactly what you need... Kazade just wants one for all and all for one [wink].

So I think vectors and matrices are a must-have, simple tga or bmp should be enough. Anyone who really needs other image formats should look for a lib like OpenIL.

A simple obj loader should be okay for some simple apps, too, everything further needs a good understanding of graphics programming anyways so just stick to the things which can be used in lots of apps, nothing too specialized like skeletal animation .

Quote: What also might be very welcome is buffer and texture management classes, rather than having to manipulate OpenGL ids directly.

True, that can go one one's nerves.. but as soon as you worry about too many texture or buffer id's you need some handling of your world's objects anyways so you dont need a helper class...

I was thinking perhaps some classes to make it easy to say render to an FBO or RenderBuffer. Also font output is something pretty much everyone needs. I've been looking at the DirectX forum trying to find out if people actually use all that D3DX stuff. From what I can gather, not many professionals use the D3DXMesh stuff, but nearly everyone uses the math and texture loading classes.

Also I thought some kind of easy shader loading might be nice.

[Edited by - Kazade on April 14, 2007 4:43:21 PM]

yeah, I think it'd be helpful to have. Mostly for newbies, but it might be helpful to more advanced users for quick-n-dirty tests or some of the more low-level helpers in general.

I'd be willing to contribute if you're searching for help. I've got a pretty well-rounded, solid matrix/vector/quat library implimented in C++ that could be modified or re-implimented for the lib and I have image loaders for a handfull of the simpler image formats.

I do agree with swiftCoder that different features are best left for their own libs, however, so it might be best to set forth with a consistant design across distinct and separate modules.

Feel free to PM me if you want a hand.

I think there *is* a benefit, particularly for the "GL noobs", in having a unified but modular helper library. There are a bewildering array of options available for many aspects: image loading, model loading, collision, physics, math, etc. Each library has its own features and limitations, formatting style, may have their own dependancies, various levels of documentation and support, and certain combinations of which may not play well together or require a lot of "glue" code before they do. This can be overwelming even for a seasoned OpenGL user setting out to write a game, GL noobs are even worse off.


So, I do see a definate advantage in a system that is modular, yet designed coherantly to work together under a single formatting style, naming convention, documentation set, etc. Although you can never eliminate glue code between the application and the library, eliminating it between libraries could be a real boon.


Also, if you talk to many developers, the DX utility classes do give a big advantage over OpenGL. They don't have to worry about writing a math class that selects optimal routines based on the processor type, they don't have to worry about writing or integrating an image loader of any kind, they don't have to worry that their chosen library's Matrix4x4 is incompatible with their API's Matrix4x4 (as an example, thats not a common situation in practice.)

Games are becoming so big and complicated... Even one less thing that the devs have to worry about is a good thing.

I really do like the idea. And I really share the opinion of ravyne...

"... Even one less thing that the devs have to worry about is a good thing."

Looking forward to see the first downloadable version. Although it is often
a real pain - but especially for beginners some well commented easy exmaples
and installation notes would be very useful when you release your first version!

Good luck and keep us informed, please !

Why would you want to create a new library when there is already alot outthere?
What would be better is that you create a wrapper library with a unified interface. Don't recreate the wheel.
Something like glhLoadImage("filename") calls DevIL loading routines and glu mipmap builder.

What you have to decide is that what language you want to do this in. C would be compatible with the rest of the OpenGL code, but C++ makes vector- (or math- in general) operations "easy".

If you are going with SDL, then why not have a helper function, that sets up SDL opengl states.