There are too many OpenGl extensions? I need you advice...what is the best way to sort the huge extension registry? I'd like to make a list of all extensions useful to my library (since it's a library, I'd like to let the programmer use any relevant OpenGL feature, which is why I don't want to skip any extension), but it's taking too much time. Even after I removed the extensions which have been promoted into the core in OpenGL 2.1 or earlier and started removing other extensions which aren't useful to me, there's still much too much! What should I do? If I pick only extensions I already know (float texture and FBO formats, FBO, half-float, texture array, etc.), I can very easily skip very useful extensions I never heard of (since I'm just a beginner)...

I'm new to extensions and don't know what sort of library you're working on, but... even if something is promoted to the core, don't you still have to go through the extension mechanism to use it? If I'm using Visual Studio for example, they don't provide updated headers, so I think you still have to access everything via extensions.

Quote:Original post by nerdtroneven if something is promoted to the core, don't you still have to go through the extension mechanism to use it?

Sometimes core functionality is extended and some more features added. So it is often better to use core functionality, then ARB, then EXT, and only then vendor specific extension.

Im not quite sure what youre making from your post.

A extension loading library (there are existing ones, in case you didnt know) perhaps use one of those, glew is one I can think of, glee another

http://www.opengl.org/wiki/OpenGL_extensions

personally I only use a single extension in my stuff
FBO though this aint an extension if u use opengl3 and greater (I target opengl2.1)

My view is, ignore extensions and life is great. With OpenGL v3.20 and GLSL v1.50 (which works great by the way), 3D graphics development with OpenGL/GLSL is "much simplified", "highly efficient", and "highly capable and flexible".

I believe OpenGL has nearly reached the point that "extensions are obsolete". This is a natural consequence of providing highly general capability like generalized buffer-objects (that can now essentially hold data of any kind) and generalized programmability through modern shader languages. And if that isn't quite enough, the interoperability between OpenGL/GLSL and OpenCL or CUDA should handle just about everything else).

Having said this, I'm sure some developers still have legitimate reasons to adopt an extension now and then. But my advice is to put yourself into a totally "no extensions" mindset, and only consider them when absolute necessity drags you kicking and screaming.

That's my two cents.

Thanks for your posts!
I have 2 questions:

1. In the current library's plan, (at least the first version of) it will have a #defined constant which will allow the programmer set the GL version he wants their program to use. The options will be 2.1, 3.0, 3.1 and 3.2. But allowing the library support all 4 versions is extra-work I'll need to do (maybe not much for you, but I work very slowly due to very limited time-per-week, to it is at high cost for me) and maybe until the library is complete, 3.2 will be everywhere and nobody will use the library's OpenGL-level-setting. What do you think, should I stick to OpenGL 3.2? A fully usable release of my library will be ready only within a year at least...What do you think? The problem is that my graphics card don't support OpenGL 3.2 and I don't habe money for new equipment...on the other hand, until a whole year passes maybe..who knows? Also, I'll feel somewhat stupid because until now I was working on the OpenGL 2.1 mode of the library...(but that doesn't count as a problem)

2. There are still many vendor-specific extensions that may never become useless. For example, NVIDIA'a multisampling control extensions. Unless all vendors support such control (taps, samples, etc. I don't remember exatly how it works), NVIDIA's extension will always be useful to me. Should I look for such extensions? They let me take advantage of vendor specific features when glGetString(GL_VENDOR) gives the right vendor name...

Quote:Original post by Tom Backton
2. There are still many vendor-specific extensions that may never become useless. For example, NVIDIA'a multisampling control extensions. Unless all vendors support such control (taps, samples, etc. I don't remember exatly how it works), NVIDIA's extension will always be useful to me. Should I look for such extensions? They let me take advantage of vendor specific features when glGetString(GL_VENDOR) gives the right vendor name...

I think its probably best to directly query if the extension itself is supported, say for instance you use an extension that works on Nvidia 8800 and above, and somone comes along with a geforce 3 that might not have it, just because the name is nvidia doesnt mean the extension is necessarily supported, Likewise some NV extensions are supported on ATI cards too. You can directly query all supported extensions of a GPU and then just check what capabilities are availible.

Maybe I'm confused then. I've just started using extensions, but as I understand it NONE of the newer enhancements/features/extensions/etc are available to me if I'm using Visual Studio 2005 "out of the box".

It appears to me that for any new features (beyond the ancient headers that come with VS), you have to use the extension mechanism (i.e. query for the function pointers at runtime and/or use something like glew).

So even if you say you're using a newer version of GL, don't you still have to go through the extension mechanism to get at any of the newer features?

>>So even if you say you're using a newer version of GL, don't you still have to go through the extension mechanism to get at any of the newer features?

on windows you do, since MS refuse to allow opengl32.dll to be updated
its not a major issue, use a extension library and its done for you
better info can be gotten from the faq at www.opengl.org