Learn what 3D object really is, and how to make it if you want.
Learn OpenGL basics, about two or three seconds again ra4king will come to give you the links.
Learn what lib you want to use, currently big four are LWJGL, LibGdx, jME, and JOGL.
Those 4 libs are at different levels and cannot be compared.
If you don’t care about how 3D works underneath and just want to use a high level 3D library, you’ve got Java Monkey Engine, Ardor3D, jPCT, and Xith3D.
For 2D, you’ve got libGDX and Java Rabbit Engine.
If you want to learn raw OpenGL, you’ve got LWJGL and JOGL, both of which provide direct bindings to OpenGL.
Look at this if you want to use JogAmp (JOGL, JOAL, JOCL, Java binding for OpenMAX).
ra4king is right, we should always make a distinction between APIs used at different “levels”.
JMonkeyEngine has a huge community and a lot of features, especially in its third version but it is unfortunately still quite buggy, several major users reported that they had to rewrite most of the shaders because they were not working.
If you choose LWJGL in applets, don’t forget to tell your end users to install the proprietary version of Java (whereas OpenJDK and Icedtea are installed by default) because of this bug. I still reproduce it when trying to run Minecraft demo. It will be fixed only in Icedtea-web 2.0 but it is unclear whether this bug comes from Icedtea-web or LWJGL as one of JogAmp contributors succeeds in running LWJGL applets without any trouble.
I really advise you to look at Paul Lamb Sound Library for the sound support, it’s very easy to use and extensible. You can use it with OpenAL or JavaSound.
LibGdx is fine and even supports iOS.
I advise you to use JOGL because it contains a complete and homogeneous Java binding for the OpenGL & OpenGL-ES APIs with build-in video support, several optional helpers (you can deploy only what you want as it is a modular library), Android support, embedded Linux support, backward and forward compatible contexts, a large choice of canvas (AWT GLCanvas, SWT GLCanvas, GLWindow, NewtCanvasAWT, NewtCanvasSWT, …), more and more active contributors especially since Oracle gave it up ;D, … We are more active on our official forum than here.
I used JMonkeyEngine for a long time but I prefer Ardor3D. It has less features (no octrees, no integrated GDE) but it is less buggy. There is a real lack of tutorials but there are tons of examples on its repository.
Xith3D is still maintained but it’s almost no more evolving. Java 3D has been recently revived but I wouldn’t use it for large projects.
[quote=“ra4king,post:6,topic:39439”]
And Slick… Albeit outdated and a bit rough around the edges, its community and wiki still makes for a good starting point.
While we’re on the topic of JOGL advocacy, are there any recent performance comparisons of JOGL vs LWJGL? The comparisons I’ve seen are pretty old, and since then both libraries have evolved somewhat; the JVM itself certainly has.
I couldn’t see any real reason for any performance differences to be beyond noise for any real-world scene - any real-world scene should either be limited by fill rate, bus rate, or run at 60fps, thus rendering it kinda moot.
Not quite true, in ‘real’ AAA level engines, the OpenGL handles (textures, shaders, VBOs) that the driver generates for us, are the bottleneck, as they mean a cache-miss in pretty much every OpenGL method that accepts them as a parameter. It’s the sole reason there are now extensions that provide/accept direct pointers in vRAM, which in some very specific cases increased framerate by more than factor two.
We, as Java programmers, typically don’t interact with OpenGL to that extend, as the JNI overhead and likely multiple abstraction layers, in our own code or the engine, make it so ‘slow’ that we can’t even be bothered by a cache-miss.
The latest and greatest engines that fire thousands of OpenGL calls per frame through the drivers, simply couldn’t exist in Java. Hence, we’re stuck with the idea that OpenGL calls must be minimized to the extend that there are barely any communication between the CPU and GPU - and then, only then, your game is either fillrate limited, bus rate limited or capped by v-sync.
LWJGL was faster than JOGL 1 on some machines, slower on others (the difference was not very big). Now, JOGL 2.0 takes much time to start than JOGL 1 and LWJGL but it is as fast as LWJGL when using NEWT, its native windowing toolkit. I have never tested LWJGL under Android so I can’t compare it with JOGL 2.0 in that case.