Hi Everyone, I’m trying to create something like this: www.managerzone.com. I’m aiming to duplicate their 3d simulator, but I’m not sure what technology to use - JOGL, Xith3D, etc. I’ll need to load models into it.
Any ideas?
Thanks!
Hi Everyone, I’m trying to create something like this: www.managerzone.com. I’m aiming to duplicate their 3d simulator, but I’m not sure what technology to use - JOGL, Xith3D, etc. I’ll need to load models into it.
Any ideas?
Thanks!
go with jMe or Xith3d
Wow, I just had a quick look at that site and they seem to be using Java3D themselves.
I guess you could argue that if it works for them…

Dan
Hi
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.
HTH
Endolf
if you “preview a live game” (an applet) and load the console, you’ll see they’re actually using JOGL:
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.
Kev
This made me wonder…
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?
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 
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.
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.
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:
go with jMe or Xith3d
or Java3D
Thats all that really needed saying anyway 
Kev
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 