Viability of a Celestia like program (jME3) (Moved..)

I am interested in making a Celestia (http://www.shatters.net/celestia/) like program. In addition to the general features found in Celestia, I would also like to add in the ability to simulate collisions between bodies, performing force based mesh deformations on the objects involved. (Asteroid impacts on silicate. Collisions between ultra large bodies and )  



Ideally, I would like to do this in Java using jME3 (This will be a long term hobby project, and I would like to grow is alongside the jME3 source.). However, I am also looking at Ogre3D for this. I have taken a good, long look at various posts from Stackoverflow.com, Wikipedia and other benchmarks relating to Java and C++. In conclusion I am left with the following nagging doubt:



  • Java's speed when performing complex math and working with big numbers seems to be a lot worse than that of C++.  



Given the potentially complex mathematics involved, would I be better of implementing this in Ogre3D?  (I will have to honest and admit that the slew of features offered by Ogre3D is also acting in its favour.. but thats another topic?)

(I would also welcome any views and/or recommendations regarding using jME for this. Also, something I found which I would also like to work into this is http://www.arachnoid.com/ruby/gravity/, basically gravity simulation)


Edit: All things said, I am just being indecisive ><;

Well if I understand correctly the difference in speed is due to Java wanting the same result on any system (OS and hardware independent) so it calculates certain operations with software rather than hardware. Now, again, I'm not sure I got it completely correct but if I did that may actually be an argument in favor of Java (so you don't get planets constantly bumping in to each other on one OS when your solar system is stable on the other one).

Btw, doesn't FastMath resolve said speed issues?

I only took a brief look at fastmath, but at a guess, fastmath (as a game orientated library) most likely sacrifices a lot of accuracy for the sake of speeding up calculations.  For example, PI gets cast as a float versus a double in the standard math API. This might not pose a problem in a normal game environment, but the difference in accuracy becomes a big deal when working with stellar distances. (Celestia for example provides a 128bit number class… I will however restrict my "universe" to something that fits into a double, if possible.)

If you want double precision and such I suggest you take a look at Ardor3d.

You don't need double precision if you're partitioning your universe into sectors (which you should be if making a space game).

I think Java is capable of handling this for the most part, I don't think you'll have many deformations running at the same time like in some physics based AAA games where you have tons of vehicles, players, buildings etc on screen all colliding with each over. Not sure if JBullet or any of the available physics engines can handle deformations though, this goes for Ogre3D as well. I know Bullet Physics has soft bodies but that's not deformable rigid bodies.

@Momoko_Fan:



Would I be able to achieve the same effect as Celestia with partitioning?



I was thinking of using the scene graph in the following manner:



The universe is the root node. The solar system and its associated bodies (planets, rings, moons and asteroids) get added as  child nodes. (The universe has a sun, which is the main node of the solar system, which in turn has planet nodes, each with their own moon nodes. Further child nodes can be  added as needed. Asteroids and other moving nodes are either a part of the solar system, or if more finely grained, planet or moon nodes.) When an event occurs at a certain node, it effects its child nodes, and also possibly its parent nodes and indirectly its siblings based on constraint checking. IE, a bright flash at a planet above a certain intensity will get passed to the parent node, which will then pass the event to it's other child nodes if it is relevant to them?



This all seems horribly inefficient but I don't really have enough experience in the field to come up with more than this ><. (A type of publish/subscribe structure with channels and stuff might maybe be usefull to minimize communication overhead. In this case the parent node will take on the role of a channel manager?)



@SomethingNew: I took a look at Ardor3D, just don't like it very much.




It also just occured to me, since one can make proper use of multiple cores with Java threading, unloading the physics and math onto two or 3 cores, and leaving the opengl and main process on another core, might make up for any other language or engine related perfomance issues?



EDIT: Yes, I know C++ and boost threads has this as well.

I'm in your shoes with the precision issue right now.



It's a tough thing and absolutely requires scene partitioning, as Momoko pointed out.  In my case, we're doing meter-accurate coordinates for places around the earth.  Getting into the millions of meters starts to cause problems.



The first problem we encountered was incorrect shadow rendering.  Simply taking the scene and dividing each location in it by 100 alleviated this problem for the most part.



There were still other problems plaguing the application though, one of them I just figured out in the last two days, which was the accuracy of mouse picking (any picking as a matter of fact).  The action was wildly inaccurate no matter how I coded the picking functionality, so on a whim I slapped the camera and some elements at 0,0,0.  Suddenly things started working correctly.  Java floating point arithmetic simply isn't accurate enough (and in my case, using java.lang.Math as opposed to java.lang.StrictMath didn't help when dealing with PI and trig functions).



I spoke briefly with renanse about this and he noted that using doubles would only cloak the problems rather than fix them completely.  The path of least resistance would be to figure out a convenient way for you to split up the universe into different sectors.  Unfortunately, you don't very concrete numeric science to go on here… I at least had maps  :stuck_out_tongue: