Original Post
🔒 Locked
[java] OpenGL (JOGL) or Java3D
Advertisement
Well, give him/her/it the benefit of the doubt:
JOGL is the sucky new OpenGL binding layer for Java that Sun are "sponsoring" with their "goodwill". OpenGL programming is all about how to draw things (draw this triangle here with this blending operation etc) and though it starts out simple it gets hard fast as you try to do more and more nontrivial things such as rendering animated models.
Java3D is the sucky old 3D scenegraph library for Java that Sun abandoned a while ago and then unexpectedly are resurrecting. Java3D programming is all about what you want to draw, not how to draw it. Java3D starts out being amazingly difficult to learn and fraught with pitfalls and unexpected performance problems and bugs, but makes a lot of stuff reasonably easy, such as the aforementioned animated models.
They are about as different a way as you can get from each other to draw 3D stuff.
And now the shameless plug:
There are two great alternatives to both - instead of using turdy JOGL you could try out the LWJGL - which is specifically designed for professional games programmers in Java, and is an OpenGL binding; and if you are interested in scenegraph programming instead, you might consider Xith3D, which looks very like Java3D but is a) not dead b) open sourced c) optimised for games programmers d) not shit
Cas
JOGL is the sucky new OpenGL binding layer for Java that Sun are "sponsoring" with their "goodwill". OpenGL programming is all about how to draw things (draw this triangle here with this blending operation etc) and though it starts out simple it gets hard fast as you try to do more and more nontrivial things such as rendering animated models.
Java3D is the sucky old 3D scenegraph library for Java that Sun abandoned a while ago and then unexpectedly are resurrecting. Java3D programming is all about what you want to draw, not how to draw it. Java3D starts out being amazingly difficult to learn and fraught with pitfalls and unexpected performance problems and bugs, but makes a lot of stuff reasonably easy, such as the aforementioned animated models.
They are about as different a way as you can get from each other to draw 3D stuff.
And now the shameless plug:
There are two great alternatives to both - instead of using turdy JOGL you could try out the LWJGL - which is specifically designed for professional games programmers in Java, and is an OpenGL binding; and if you are interested in scenegraph programming instead, you might consider Xith3D, which looks very like Java3D but is a) not dead b) open sourced c) optimised for games programmers d) not shit
Cas
Agreed. JOGL is designed simply for graphics. LWJGL is a game library. Comparing JOGL and LWJGL is like comparing DirectX and OpenGL -- you can''t, because DirectX is an entire library including things beyond graphics, whereas OpenGL is only graphics. Now comparing the graphics functionality of LWJGL and JOGL as a whole is a different story...
I think that the JOGL/Java 3D/LWJGL question will be making it''s way into the FAQ soon...
http://chaos.webhop.org
I think that the JOGL/Java 3D/LWJGL question will be making it''s way into the FAQ soon...
http://chaos.webhop.org
quote:
Original post by Strife
I think that the JOGL/Java 3D/LWJGL question will be making it''s way into the FAQ soon...
that would be much appreciated. much like the directx/opengl debate its hard to get a straight answer about the benifits of each...anyone interested enough to respond tends to be rather biased...and really its usually just 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 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
- 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
"... we should have such an empire for liberty as she has never surveyed since the creation ..."
Thomas Jefferson
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement