Haha! Indeed it is
Actually we''ll soon have a couple of intro articles up on JGO which detail the details and pros and cons of JOGL and LWJGL and introduce you to using them.

Cas

I would just like to add my 2-cents here.

I have tried out both JOGL and LWJGL. One of JOGL's biggest downfalls is the fact that you can only render opengl from 1 method. So you either have to have all your opengl code in your display() with a bunch of if/else or case/switch or you have to call methods from your display() method in order to render opengl.

This sucks. Opengl is a state machine. You should be able to manipulate that state from anywhere. However, because of AWT/Swing and the way the opengl context is rendered, this can't be done.

LWJGL is different in that is is closer to programming opengl in any other language like C/C++. You can manipulate the opengl state from anywhere you want and update the context. The problem with LWJGL, well the problem for me, was that because it doesn't use AWT or Swing you have no access to any GUI widgets. Now for a lot of people this is not a big deal because you don't need those in games. For me, on the other hand, it sucks because I am making a modeling program to help me learn opengl so I need those widgets. I don't want to create opengl widgets. yuck!

So for my project I have stooped to using JOGL because I can use Swing and I know Swing very well.

Long story short, I didn't mention Java3D because it doesn't even deserve to be discussed. Like what has already been said, JOGL and LWJGL are 2 different animals taking care of 2 different domains. If you want to program a game I would definatly recomend LWJGL. If you are like me and need to learn Opengl, I recommend using JOGL and starting out with something like a modeling application. With a modeling application you are focusing mostly on Opengl and less on Engine design and different considerations that will really take your mind off of Opengl.

Just my opinion though.

Gregg
http://radio.javaranch.com/channel/gthought

[edited by - gthought on April 27, 2004 5:39:17 PM]

I''d also like to add -

- that LWJGL can now actually be used with JOGL (and therefore AWT). Just use JOGL to create the context, but then use LWJGL to call the GL. Handy if you prefer the LWJGL API philisophy.

- that LWJGL can only be called from one thread at a time and is in fact subject to the same restrictions as JOGL. The restriction is actually at the O/S driver context management level, not the API level. However, it just looks a bit fiddlier in JOGL because typically your program is running in a different thread to the AWT whereas in LWJGL you tend to create the context in your main thread.

- that you can use LWJGL and SWT if you need widgets but don''t like AWT.

- that it shouldn''t be rocket science to create a tiny AWT OpenGL context factory that we could include in the LWJGL project, which means that you can use LWJGL from AWT and not need to bother with JOGL. Volunteers?

Cas

quote:Original post by gthought
I have tried out both JOGL and LWJGL. One of JOGL''s biggest downfalls is the fact that you can only render opengl from 1 method.

Rumour has it that they''ve added proper swapBuffers control in the latest build (I''m still using an old one so I havn''t used it myself), which removes a lot of the dependancy on the annoying Animator object and the single .display method.

Of more concern is the fact that Jogl is *terribly* buggy when it comes to creating a display surface. It flat out fail on a number of configurations (not even particularly obscure ones) and some of these issues (despite being well known) havn''t been looked at for months (if at all). Conversly, LWJGL ''just works'' on pretty much every system I''ve tried it on.

Regardless of which API looks better, if I can''t get a drawing surface to do stuff on then the library is pretty much worthless for anything major.

quote:Original post by gthought
I would just like to add my 2-cents here.

I have tried out both JOGL and LWJGL. One of JOGL''s biggest downfalls is the fact that you can only render opengl from 1 method. So you either have to have all your opengl code in your display() with a bunch of if/else or case/switch or you have to call methods from your display() method in order to render opengl.

This sucks. Opengl is a state machine. You should be able to manipulate that state from anywhere. However, because of AWT/Swing and the way the opengl context is rendered, this can''t be done.

I don''t want to speak for Ken here but it seems the decision to not expose context management to the developer is based on his experience with GL4Java. A lot of people didn''t seem to understand how to use OpenGL and Java together so JOGL dumbs it down for everyone. Either that or he would spend all his time answering the same questions over and over again. It takes a little getting used to but it really isn''t that bad.

quote:Original post by OrangyTang
Of more concern is the fact that Jogl is *terribly* buggy when it comes to creating a display surface. It flat out fail on a number of configurations (not even particularly obscure ones) and some of these issues (despite being well known) havn''t been looked at for months (if at all). Conversly, LWJGL ''just works'' on pretty much every system I''ve tried it on.

We are having some teething problems with surface selection. Hopefully we will have a smarter algorithm for picking a surface soon. In the mean time you just have to make sure that your video card supports what ever values you put into GLCapabilites.

"... we should have such an empire for liberty as she has never surveyed since the creation ..."
Thomas Jefferson

quote:Original post by GKW
We are having some teething problems with surface selection. Hopefully we will have a smarter algorithm for picking a surface soon. In the mean time you just have to make sure that your video card supports what ever values you put into GLCapabilites.

Ha, same old same old. >

I raised these issues waaay back in december, and got brushed off with the same response, "it''ll be added ''soon''" I havn''t seen *any* progress on these issues. Even when using valid values in the caps chooser it still fails to create a display surface, most obviously the alpha-bits in linux bug still exists and it''ll fail to do anything on a couple of windows machines I''ve tested on.

As far as I know Ken and I are pretty much the only people making regular contributions and in my case that is a generous description. You are more than welcome to try and find the bug yourself and contribute the fix. I will take a look at the windows surface selection problem after I finish what I am working on now.

"... we should have such an empire for liberty as she has never surveyed since the creation ..."
Thomas Jefferson