Quite accidentally popped into a little thing called Ogre4j today. As many of you (probably) know, it uses JNI to make all the Ogre3d interfaces available in java. Searching around on our forum here, turns out Ogre4j has been mentioned only 3 times and only in one thread has the discussion really taken off the ground. However all that was a while ago.
Apparently the Ogre4j project has seen a surge of new activity lately. Well not a big surge, but the activity is there - on their website, sourceforge, and also the SF forum. Quite accidentally I also discovered that one jME user is making use of Ogre4j in conjunction with jMe. So… this all intrigues me a lot…
How many of you have taken a longer look into Ogre4j or do you think there could be things worth investigating here? Perhaps SOME functionality or modules we can use? People often seem to frown upon JNI interfaces, but I have no personal experience with them, so please frown freely, if you DO have experience.
As another user mentioned, using OGRE through JNI is a messy business. I started off writing a game using ogre4j, but switched to jMe not so long ago. I got fantastic support from the authors of ogre4j and the OGRE community but jMe won me over easily. Using a wrapper takes away a lot of things that make Java great: the integration with your code (possibility to easily study how it works, extend the classes, garbage collection, the possibility to use your favorite design pattern (like MVC) without worrying about stuff like not getting enough access or weird threading problems, etc).
So, looking at ogre4j I don't think there's much to investigate. It would be interesting though to see a comparison between OGRE and jMe features…
jonkri said:
As another user mentioned, using OGRE through JNI is a messy business. I started off writing a game using ogre4j, but switched to jMe not so long ago. I got fantastic support from the authors of ogre4j and the OGRE community but jMe won me over easily. Using a wrapper takes away a lot of things that make Java great: the integration with your code (possibility to easily study how it works, extend the classes, garbage collection, the possibility to use your favorite design pattern (like MVC) without worrying about stuff like not getting enough access or weird threading problems, etc).
So, looking at ogre4j I don't think there's much to investigate. It would be interesting though to see a comparison between OGRE and jMe features...
One thing I wouldn't mind in jME that Ogre has would be material scripts ;)
One thing I wouldn't mind in jME that Ogre has would be material scripts Wink
You can load mesh and material files in jME using OgreLoader.
I would prefer to use jME over Ogre3D, because Ogre3D is a graphics engine and even though the C++ version has support for physics, sound, gui, etc. it's still better to use an engine that has it all nicely integrated.
Like others mentioned using a JNI wrapper would require you to manually destroy native objects and do other housekeeping stuff.
Momoko_Fan said:
One thing I wouldn't mind in jME that Ogre has would be material scripts Wink
You can load mesh and material files in jME using OgreLoader.
Yeah, I read that about the OgreLoader, but its not exactly the same as not everyone works with the ogre format. Although, there are quite a few modeling tools with exporters for ogre, so it makes sense to use in order not to re-invent the wheel. But I still consider it more of a "hack".
Ogre3D wasn't designed to be JNI wrapped. Generally C++ libraries are hard to wrap (and use) properly trough JNI. Wrapping C++ code goes trough the route C++ -> C -> Java. For example the Horde3D engine was designed so to be easily wrapped, Ogre3D wasn't. Don't know how much stable Ogre4j is, but i presume it will need allot of fixing until it is.
The good side of using Ogre3D is good graphics API support (OGL, DX9, DX10.0 almost done), and that a single JNI call results in more GL commands than using the GL library directly from Java. So the total overhead of going trough JNI is reduced, because you achieve more with less calls. The Ogre3D engine itself is not much advanced than jME. It has solid basics, it has pluggable scenemanagers, the material system is as good as jME 2.1 will (?) have, tho it could be better. The strength of Ogre3D comes from the multitude of plugins it has, the tools and exporters. But you can not use Ogre3D plugins, if those are not themselves wrapped. The LGPL license requires contributing code back to the project, unlike jME's BSD license, which permits dodging this. Ogre3D has probably magnitudes more users that jME. Ogre3D is a beast of code and API, and Ogre4j doesn't make it any more elegant.