I need some help in deciding which API to use for advanced OpenGL rendering in Java. My choices has boiled down to either JOGL or LWJGL, and the following are important for my choice, in prioritized order: 1. Compatibility. I noticed LWJGL fails to even initialize the display on some systems, how about JOGL. Which one is more stable? 2. Performance. I want the API with the smallest amount of overhead between Java and OpenGL. Any Benchmark tests? 3. Features. My application will support advanced rendering techniques like HDR rendering and Perspective Shadow Mapping. I also need support for shaders through Open Gl Shading Language, or similar. I only need to support the Windows platform. Any advice would be greatly appreciated.... :)

I think this belongs to the java / opengl forum if I am not correct in this assertion you can correct me.

Anyway, If you only need to support windows platform why use Java? C# is similar enough. As far as I thought, the main advatange of Java was cross platform (lol) code. Just think of how horribly Azureus performs of on Windows compared to OSX / Linux.

I'm just saying that there is no point fanboy language over another, but it seems like you are trying to use a hammer to screw in nails.

Quote:Original post by el capitan
I think this belongs to the java / opengl forum if I am not correct in this assertion you can correct me.

Anyway, If you only need to support windows platform why use Java? C# is similar enough. As far as I thought, the main advatange of Java was cross platform (lol) code. Just think of how horribly Azureus performs of on Windows compared to OSX / Linux.

I'm just saying that there is no point fanboy language over another, but it seems like you are trying to use a hammer to screw in nails.

wow, all that text and still not one single grain of information requested in my post... :)

I have good reasons for choosing Java, and as I dont care about cross platform compatibility I will compile it into native code and use assembly language if really needed, this cranks up the performance a lot compared to Java running on a JVM.

This is not my first high end 3D project in Java, and I can promise you noone will be able to tell it is Java and not C when done. Also, you should know that the bottleneck in modern games is on the 3D card, not the CPU.

By the way, C# performs horribly and requires a 30mb .net runtime bundle, so no way.

C? Well, maybe, but I prefer a more modern language, it increases my productivity tenfolds and Java is my personal language preference. And there's virtually no performance penalty when using Java like I described before.

Quote:Original post by BlueTomato
wow, all that text and still not one single grain of information requested in my post... :)

Oh, I see and the post is completely under the topic:

"Graphics Programming and Theory"
"All aspects of non-API specific 2D and 3D graphics programming and theory."

So I have no idea what you are talking about.

Quote:
I have good reasons for choosing Java, and as I dont care about cross platform compatibility I will compile it into native code and use assembly language if really needed, this cranks up the performance a lot compared to Java running on a JVM.

I have no idea how you will compile Java to "assembly language". I have also no idea what you are talking about, but this could be highly due to my ignorance. As far as I know Java is compiled to byte-code, which is then interpreted by the JVM which ever the way it sees the best. So I understand that you indend JNI to interface opengl and then then use a JTI JVM? Anyway that still doesn't turn Java into assembly. It merely interprets it that way so everything is left to the user.

Quote:
This is not my first high end 3D project in Java, and I can promise you noone will be able to tell it is Java and not C when done. Also, you should know that the bottleneck in modern games is on the 3D card, not the CPU.

Wow, you had to mention that you are doing High End 3d and then you had to defend the performance. The fact that you brought it up makes me feel that you have insecurities about the language you chose and that you have to defend it somehow.

Quote:
By the way, C# performs horribly and requires a 30mb .net runtime bundle, so no way.

Can you back that up? I can surely back up the fact that Azureus is a resource hog.

Anyway, your post sounds strange and I'm quite sure its supposed to be in an another forum. I was also asking for you to be open minded about the language. And since this is theoretical forum I brough up the perhaps soon to be design flaws in your project.

Since I'm feeling that you are feeling little insecure with Java, maybe you should try OCaml. It looks like excellent tool for your job and does exactly what you want. That way you'll also recieve nice compact API, too. No need to worry about licences or the bloat of LWJGL / JOGL.

Quote:
Just think of how horribly Azureus performs of on Windows compared to OSX / Linux.

Just try ATI's new and shiny control panel, which is written in C#. The earlier version, in worst cases, took nearly 3-5 mins to event startup! Now they improved it somewhat, but still takes ages to launch (just tried, 1.5 mins). And my friend with a brand new AMD and a fresh ATI card he just bought complained how ugly slow it is. I dunno, maybe ATI just has bad engineeers writing it?

It's funny how people are accepting C# without a second thought for just about anything, but still think that Java is slow and bloated - while in the reality C# still has a long way to reach Java's level of performance and maturity. I guess it's the magical C-letter that's enough for most people.

Quote:
No need to worry about licences or the bloat of LWJGL / JOGL.

What bloat?? License problems?

Quote:Original post by OrangyTang
I used Jogl extensivly for about a year long project (game + editor) and have used LWJGL since it started (and am still using it).

You've basically a couple of distinguishing features:
1. Jogl can be placed inside a Swing/AWT window
2. LWJGL has native fullscreen support

No. 1 was important enough for me to choose Jogl at the time. Since then LWJGL has added a similar feature, so it's less important now. Jogl still doesn't do native fullscreen though, which is a must for games.

LWJGL is still miles ahead in terms of reliability. Jogl apps frequently just don't work (usually with an access violation and no oppertunity to catch such an error in your java code). LWJGL tends to work with a much greater variety of graphics cards and platforms.

API wise, Jogl likes to do lots of event-driven stuff which appears closer to Swing's event handlers etc. and places arbitrary restrictions on when you can and can't access OpenGL calls. LWJGL provides an API closer to what you'd need in a game (ie. straightforwads polling of key state and no imposed rendering callbacks).

For shaders you're unlikely to see much difference. I've used GLSL with LWJGL and it works great. Both include all of the up to date extensions, but they tend to appear quicker in LWJGL.

Summary: if you're doing a game, LWJGL is what you want. If you're doing an app then it depends. I'd still be inclined to use LWJGL though (I have a few level editors and animation tools that use LWJGL's windowed mode).

Thanks, nice to know about your experiences.

I learned JOGL supports software rendering while LWJGL does not, thus is therefore in theory more compatible, but if the target computer cannot do hardware rendering then it is just as well the program does not start at all.

Also, I found LWJGL forces the programmer to do things in a more optimized way when it comes to manipulating buffers. JOGL allows slow arrays, while LWJGL forces the use of directbuffers, which is native arrays compatible with both Java and OpenGL.

I will go for LWJGL now.