37

Looking for an easy to use 3D Java Engine API (i.e. not wrapper) that has a good community and good development. Extra features (i.e. audio, input, etc.) are not necessary but nice.

List of the most popular Java 3D graphics APIs I found:

Wrappers / Low Level

  • JOGL - Strong community / Good support / Active
  • Java3D - Abandoned (or slowly dying), phased out Scene Graph (or re-tooling into JavaFX?)
  • lwjgl - Open GL wrapper, with audio and input handling / Active

Engines

jMonkey Engine - Wikipedia - Active

  • Branching between version 3.0 and 2.0 (may hurt community)

ogre4j - Wikipedia - Active

Bindenlicht - No Wikipedia! - Not active

High Level (Not designed for gaming)

  • Processing - Doesn't seem suited for gaming but for graphics visualizations and demos
  • Jzy3d - An easy to use Java API for 3d charts (surfaces, scatters, bar charts, etc). Built on top of JOGL

Update: Please pick a JAVA engine and explain why its your choice! Thanks!

dbr
  • 153,498
  • 65
  • 266
  • 333
Venus
  • 6,390
  • 12
  • 48
  • 62
  • 1
    Why Java? Better use C++, your options increase tenfold even when restricting yourself to multi-platform solutions. It is easier to learn C++ than getting lacking Java libs to work. Also irrlicht's java binding hasn't been updated for almost two years. Irrlicht itself is C++. – haffax Jul 30 '09 at 22:20
  • 3
    @haffax My program does a lot of work with line input and MIDI files, I don't think I would get that with C++ easily. I know its difficult to do it with C# (there's no official support in the API). I could only imagine how much harder it would be in C++ :) – Venus Jul 30 '09 at 23:57
  • 1
    jogl moved from java.net to jogamp: http://jogamp.org/ you linked the old project home. – mbien Sep 14 '11 at 03:33

2 Answers2

13

I would look at Ardor3D and have another look at JMonkeyEngine.

Ardor3D

UPDATE: Ardor3D's developer ceased the project, but a subset of it continues to exist

Created by the original JMonkeyEngine developer(s) who decided a clean break was required so they could start over and use all the experience gained to create a better API and platform.

The people I know who have used Ardor3D have very positive things to say about its design and API. It is actively maintained and has a good community and good API documentation, although tutorials are a little short in supply and generally you'll have to be familiar with 3D programming concepts to be able to pick it up.

JMonkeyEngine 3

A community-led rewrite of JMonkeyEngine 2, driven by dissatisfaction with JME2 design and related issues caused by said design, it has gone from strength to strength since its release.

There is ample documentation including tutorials and plenty of projects using it. If you had issues with JMonkeyEngine 2 or earlier, it is well worth another look at version 3.

Others

Charles Goodwin
  • 6,019
  • 2
  • 31
  • 61
  • 2
    Ardor3D is dead. http://ardor3d.forumatic.com/viewtopic.php?f=4&t=12755 – Finn Johnsen Mar 21 '14 at 11:20
  • 1
    The "official" Ardor3D is effectively dead but I still maintain a subset of this engine, Charles is right and I thank him for mentioning JogAmp's Ardor3D Continuation which is actively developed and maintained. – gouessej Dec 15 '14 at 12:57
  • Is it time to update and mention JavaFX? – Troyseph Apr 14 '15 at 12:10
9

You are mixing libraries and levels of libraries, Jogl and lwjgl are both pretty thin wrappers around OpenGl (IIRC lwjgl has more wrappers for OpenAL i.e. audio). While you can write a game using pure opengl you will probably spend a lot of time managing geometry, building (or reinventing) a scenegraph and other management functionality.

Processing is mostly 2D oriented.

I don't have any experience with ogre4j, but the last time I looked JMonkey was under current development looking at the 2.0 repository there is a long list of changes that are current.

If you are not too set on using Java consider some of the alternatives Torque (private Scripting Language) Panda3d (python) or the aforementioned OGRE using C++. I don't know what classes and constructs you are talking about in your first paragraph, but having a library or backend that takes care of the scene management, visibility calculations, sound management, game loop, possibly even networking might be a better driver for your decision than a specific language feature.

Harald Scheirich
  • 9,346
  • 25
  • 51