Now that nvidia offers official opengl 3.0 support and JOGL offers no opengl 3 support I start to wonder whether JOGL is actually as dead as it currently seems. Is there any hope that after JavaFX has been pushed out we’ll see opengl 3.0 support and new nightly builds?
OpenGL 3.0 is not that interesting anyway, as it doesn’t support geometry shaders and all other promised fancy stuff… yet.
Well it always depends what you want to do but there is already some fancy stuff in it. Async vbo updates, texture arrays and AFAIK all OpenGL3.0 ready cards support geometry shaders via extension (GF8 and later).
But i agree GL 3.1 will look cleaner since it removes the now deprecated features.
Thanks for your answers - at least the community seems to be alive 
Good to see that there is a momentum for JOGL (even if it’s seem to be focused on OpenGL ES), but still a bit disappointing that there seem to be no GL 3 features in the JOGL_2_SANDBOX branch.
I really hoped that the official binding would keep up with current versions. I think I’ll switch to LWJGL, since I want to play with the GL_EXT_direct_state_access extension.
I have seen a few people raving about the “GL_EXT_direct_state_access” extension and I get the impression it will play a large part in the future of OpenGL. But i’m not quite sure what it acctually does…
Does it allow the API to be more object orientated & faster in some way? (I read that it will help to get rid of the “bind” concept, and help to make the API more similar to DirectX)
A “hacked” version of JOGL was posted on these forums with 3.0 support. http://www.java-gaming.org/index.php/topic,19129.msg150960.html#msg150960
EDIT: Ah yes you can load a matrix without setting the matrix mode
glMatrixLoadfEXT(GL_MODELVIEW, matrix);
EDIT2:
(27) What feedback has Id Software given on this extension?
John Carmack: “This should have happened a long time ago.”
EDIT3:
Very interesting post at gamedev.net giving examples of the benefits of DirectStateAccess : http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=243609#Post243609
Maybe it is not a good idea to switch to LWJGL only for this feature.
Yes, absolutely right.
We have to remember that LWJGL is extremely evil and we have to be thankful that JOGL has come to save us.
That is not why I meant, sorry. But I really wonder if it is enough to switch to LWJGL just for a particular feature. Is it really a “must-have” feature?
It depends - from a OpenGL user’s view it isn’t, but from a OpenGL programmer’s view it is.
Anyways JOGL’s promise (at least my view of it) was to be the Sun endorsed OpenGL API. That’s what I’m looking for (I was sick of all the short lived OpenGL extensions C++ wrappers), but if JOGL fails to support OpenGL 3 now (though as we’ve seen it shouldn’t be too difficult - just a bunch of extensions and maybe some initialization stuff) then I lose confidence that JOGL will support the next revisions of OpenGL in time.
As for the short lived comment, LWJGL is older than JOGL.
Lots older.
And better, of course
Cas 
Personally I don’t know why JOGL exists. It tries to have object oriented approach on too low level and imposes arbitrary limits that OpenGL doesn’t have. LWJGL on the other hand gives you exactly the same OpenGL API as is, eg. functions are static methods and can be called at any time as long as you have OpenGL context current on current thread. Exactly as in OpenGL in native code.
This conclusion is derived from my own experience with handling OpenGL. I did several attempts until I finally found the right choice. It began as simple utility classes which worked for awhile, but then things were getting messier and messier. Ok, I did a better object oriented abstraction which exposed all the state etc. it looked cool, so I’ve rewritten all my apps to it (and it wasn’t that straightforward sometimes) and was happy for some time… then I started realizing how messy it is and realized that it’s the very bad way of doing things.
I needed something that is realiable from API view, uses modern rendering approach that is shader-centric (= same as current HW implementations). This means my new library has reversed approach, you set shader and it’s inputs (uniforms, vertex data, etc.) and there is minimal set of states (eg. some fixed functionality is grouped into few classes containg more states, which can be replaced as a group). It requires Shader Model 2.0 or better. After I’ve again rewritten all my apps to it (which was even more painful as it diverged from original OpenGL pretty much, practically I did more a rewrite as I did also other things badly), I’m very very happy now and finally feel confident it’s the right apporach. Nice object oriented, still low-level (nothing engine specific is there, just better exposing of HW) and reliable by design (just few state groups to handle and easy to reset to known default state).
My experience concludes that JOGL has stuck with the first design of mine and thus it’s FAIL. You know when design of something is flawed then it’s needed to move on and use better one. LWJGL does exactly what it has to do on it’s level, eg. exposing just OpenGL as is.
Can you please explain what limits JOGL imposes? I don’t know any GL feature that LWJGL supports and JOGL does not (except GL3 of course). And I’m the greatest fan of DebugGL (and it’s the object oriented approach that makes that decorator easily possible) - if I had had that with C++ it would have saved me much frustration. Is there something like that in LWJGL?
Another question: Do you LWJGL users really know to which GL revision or extension a specific function belongs (I don’t) or do you have static import blocks that you simply copy each time?
You are absolutely right, those are my only two ‘problems’ with LWJGL.
It hate to scatter glGetError all over the place to narrow down the bug.
It feels like System.out.println(“1” -> “2a” -> “2b” -> “3”) scattering…
and I sometimes (have to) use Google to find the class of a certain
GL extensions in LWJGL. Somebody should write a debug-version of
LWJGL that does the checks, maybe bytecode transformation…
Other than that, it rocks…
comment in when compiling to get a debug lwjgl.jar
we dont provide this because … well … we dont
Nice one. I’m going to give it a try later.
It wouldn’t be a bad idea to provide this out of the box though, in a seperate jar…
me is a lazy basterd, like the bunch of us :persecutioncomplex:
Lol I like your objectivity.
It has to be said I am probably one of the least objective people in that particular argument
As for DebugGL… yeuch! Nobody in the industry uses this horror. You either use a native GL interceptor or you just narrow down your problematic bits of code or you use that LWJGL debug flag (and Yes, it would be a great idea to include it with the distribution).
Cas
sigh…I’m lurking here…damn it to heck, why can’t we just get one graphics api and stick with that and make that the best it can be rather than jumping from one to another every other year!!!
I initially started with Java3D but then that pretty much died when Sun stopped releasing updates…yes it lives, but in my opinion it is on its last legs. So I move to JOGL thinking this will be backed by Sun and now it seems to be dying as well!!! Frack me, I don’t want to go learn yet another package and convert my code to it!!! Sorry, but JOGL sounds better than LWJGL so I’m gonna stick with it for a bit and then I’m giving up on graphics programming forever.
edit: Meant to say I moved to JOGL thinking it WOULD be back by Sun (had a “not” in there).