Having spent about 4 years playing with various java 3d engines I'd have to say that the most important thing is to try and seperate your rendering layer from your game logic/object layer. Even now I can't decided which tech to use, they all seem to have advantages and disadvantages.

Here is my own views of some of the engines, these may be out of date with current developments or just plain wrong

Java3D - Scene graph, which is good, no mac support after 1.3.1, anything you do using new rendering techniques will probably be done using Java3D 1.4 or later, so no mac support. Also doing 2D overlays are a real pain.

Xith3D - Scene graph, Mostly compatable with Java3D, I've not had any luck porting my 2D overlays from Java3D to it, there was always something that broke. Xith has it's own overlay system, but it is a real frame rate killer. The main 3D components seem to work well though. Java Cool Dude did some really nice looking demos using xith.

jME - Scene graph. It seems that there is a memory issue when your scene contains a large amount of vertecies, however, it is more game oriented that either of the two above. Again, there are some nice looking demos of this. I've managed to implement the starts of a HUD system in jME and it looks like it would be far far easier than with Java3D or Xith

OGL bindings

JOGL - Plain GL wrapper, nothing fancy. You can do anything you can do in OpenGL in this, the sky (or vacume of space) is your limit. The down side is that you have to do it all yourself. Scene graphs make work easy, but limit what you can do, gl bindings give no limit to what you can do, but make you do it all yourself

LWJGL - See JOGL, but has some extras like input handing and OpenAL. LWJGL seems to be well supported and a busy community. LJWGL seems to like the idea of dumping AWT/Swing so that in future it may be used on lower spec devices using OpenGL ES. It's not a consern for most of us though. Again, graphics wise it's a GL binding, so you have to do everything yourself.

If your scene is relativly simple, but you want 3D and 2D mixed, and maybe some of the newer OpenGL features, then it might be worth looking at LWJGL/Jogl, if you have a very complicated scene, then your GUI will be a pain, but go for a scene graph.

If your scene is relativly simple, but you want 3D and 2D mixed, and maybe some of the newer OpenGL features, then it might be worth looking at LWJGL/Jogl, if you have a very complicated scene, then your GUI will be a pain, but go for a scene graph.

I think this is the wrong way round. If you got a really complicated scene then you're more likely to need to optimise your rendering method to get any sort of performance - generic techniques uses in scenegraphs probably just won't cut it. If you want to do something pretty simple pretty quickly generic scenegraphs are great. Then I suppose thats really down to how you define a complex scene.

I also think while the HUD/2D issue with scenegraphcs is fairly irritating its likely to be resolved pretty quickly, especially if people start asking for it.

I don't have too much hands on expirience with 3d engines, but is it possible to write a generic 3d wrapper that wraps your 3d operations to a certain 3d engine? So the game/render logic won't change, you just "plugin" another engine like lwjgl or xith3d. Fx your 3d wrapper maps your 3d operation object.rotate(x,y,z) to the lwjgl equivalant.

I made such a wrapper for my 2d library and it works great, but then again 3d engines might have too much specific operations?

I think this is the wrong way round. If you got a really complicated scene then you're more likely to need to optimise your rendering method to get any sort of performance

These days, theres not much to do in OGL that will give you an extra boost in performance that a scenegraph doesn't already do. display lists, vertex arrays, vertex buffer objects...etc are all used by the scenegraph. Also, complete scenegraphs are designed to handle large scenes, thats why algorithms such as Octrees, Quadtrees, Binary Space Partitioning, Portals and a whole lot of others were created, to handle large scenes efficiently. But ofcourse, having a single scenegraph implement every scenario for any particular game type is definelty asking alot, thats why you see as a scenegraph matures, it tends to veer off in a direction and become specialised in that particular field (either an first person shooter, out door renderer...etc) and it takes a big effort from alot of people to keep it neutral (one of those is Ogre).

Whether a scenegraph is successful or not depends on a mix of algorithms and implementations, and its not just about creating new ways of doing something.

But all of the above can be taken with a grain of salt because its just my opinion

If your scene is relativly simple, but you want 3D and 2D mixed, and maybe some of the newer OpenGL features, then it might be worth looking at LWJGL/Jogl, if you have a very complicated scene, then your GUI will be a pain, but go for a scene graph.

I think this is the wrong way round. If you got a really complicated scene then you're more likely to need to optimise your rendering method to get any sort of performance - generic techniques uses in scenegraphs probably just won't cut it

I dunno, I keep coming abck to the fact that I get a steady 250fps on my laptop with real game data (NWN data) in JNWN out of Java3D.

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

These days, theres not much to do in OGL that will give you an extra boost in performance that a scenegraph doesn't already do. display lists, vertex arrays, vertex buffer objects...etc are all used by the scenegraph. Also, complete scenegraphs are designed to handle large scenes, thats why algorithms such as Octrees, Quadtrees, Binary Space Partitioning, Portals and a whole lot of others were created, to handle large scenes efficiently. But ofcourse, having a single scenegraph implement every scenario for any particular game type is definelty asking alot, thats why you see as a scenegraph matures, it tends to veer off in a direction and become specialised in that particular field (either an first person shooter, out door renderer...etc) and it takes a big effort from alot of people to keep it neutral (one of those is Ogre).

Current state of my mind:

Its not to do with what you can and can't do in OpenGL, thats such a small part of the picture - take culling - a scenegraph must attempt to cull based on only the data structures it knows about, i.e. its a generic scenegraph. If I render without a scenegraph I can make domain specific choices - tile based maps with a fixed view are a good example. I can determine exactly what can and can't be seen instantly, I don't need to be generating bounding volumes as things change, I don't need to be applying quad/oct tree searches to ween out what I can and can't see, I can simply decide. Thats not to say that a scenegraph might not be perfectly suitable to implement the game and to get the performance you need - its just not as simple as saying "use a scenegraph".

Now you can happily go on to say that I could do that with a scenegraph, I could plug in some culling system or I could just set nodes visible/invisible as required. Thats great but am I really *using* the scenegraph then?

As scenegraphs tend away from being generic and become more specialised for different types of game they IMO tend away from being "generic scenegraphs" and become scenegraph based engines.

Quote

I dunno, I keep coming abck to the fact that I get a steady 250fps on my laptop with real game data (NWN data) in JNWN out of Java3D.

I'd say that means your scene is complimentry to using a scengraph, thats good. However, I don't think thats always the case. I don't know what the NWN map format or data structures so I can't really comment.

Please don't take this as a bland "scenegraphs are rubbish" comment. It isn't, I think they're good for appropriate projects. However, experience using them and OpenGL for a few projects tells me that its not a decision that can be made that lightly.

That said, for the original posters project in question as Mazon already said:

Please don't take this as a bland "scenegraphs are rubbish" comment. It isn't, I think they're good for appropriate projects. However, experience using them and OpenGL for a few projects tells me that its not a decision that can be made that lightly.

Agreed, and there is no question that if you want absolutely the maximum frame-rate then youa re likely to get the best results from an algorithym and data set that are tighyl tuned to each other. Thats a lot of work, though, and I guess what Im saying is so far the SG gives me performance that easily falls into the "good enough" range with a lot less effort

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org