To native or not

First time posting - so forgive me if this is a bad question.  :expressionless:

Let me start out with the fact that I am really impressed with the jMonkeyEngine and the physics package attached to it.  The code is beyond top notch.  The question relates to the physics implementation however.

I see that ODE is the preferred physics implementation.  There have been a lot of discussions over whether or not PhysX should be used (looks like there was an implementation but not the 'preferred' way).  Also, I now see that there is interest in the JBullet implementation because it offers a lot of the benefits of the Bullet physics libraries but in a pure java, open-source implementation.  That sounds like 'goodness', but I disagree (with extreme caution).

Lets assume that Java makes its way onto the consoles (this really isn't that far off if you think about it.  The PS3 has Java built in for the blue-ray player…whether or not it can be used by games is another question).  Also, there is the iPhone to think about.  Lets also look at the fact that NVIDIA and AMD have both said they are putting physics into their cards.  The definition of how they do this is of course blurry, but lets just assume they 'do'.

My newbie thought would be that they would probably expose this through something like the Bullet library.  The reason I say this is because Sony has already released an implementation of the Bullet libraries that utilizes the SPE's.  NVIDIA has already done work with the Bullet libraries (not endorsed but recommend).  I think that's some pretty good industry support for an open source project.  (Of course the website just went down so I can't site references - )

That said, why would you want to use a purely Java implementation like JBullet (besides for debugging purposes) when you can get all the benefits of the specialized hardware for a given platform when you use the native code?  Yes, you would have to make native library calls…but remember, LWJGL uses native calls so that it can utilize your graphics card.  If we didn't do this, the graphics would be incredibly slow simply because your generic CPU just isn't made to do graphics.  You can work to minimize the native library calls.  Wouldn't you want that same benefit for physics?

I think that we're over-simplifying our physics implementations simply to support the fact that they have to run on 'mediocre' (for the task) hardware.

Now, I have no idea what the implications would be to implement this because I haven't looked at the actual physics code other than the examples.  I just know that if I could pump all of this information into my graphics card, it would save my CPU a lot of hassle and free it to think about the high-level logic that I would prefer it to be working on.  I also know that if I want to ever port my program to something like the PS3 (assuming that this over comes all the other roadblocks), it would be nice to use the actual specialized hardware instead of bogging down the generic CPU down with tasks that could be passed off to the SPE's.

So that said, why ODE or JBullet over native calls to Bullet (which would run on the best hardware it can within a given system)?

Sorry for the long post.  Remember, I'm new to this  XD

Well, the great thing about jME-Physics is, because it abstract away from the implementation (ODE, JOODE, PhysX, JBullet, Bullet, etc.) if that becomes something that is more prominent then the developer need only swap out implementations for the preferred route.  This is one of the primary reasons there is jME-Physics around these other implementations to handle these scenarios. For now though, PhysX is the only hardware physics system available and being used on many systems…that could change very quickly though as you suggested.

Well, the reason I liked the Bullet implementation is because it can make use of the 'best hardware' available for the task.  There is an implementation of Bullet that runs on the SPE's, one for Cell Blades, and "others".  It has optimizations to run on the XBox, Wii, etc…  While the implementations themselves are different (to make use of the hardware), the API to the user is 'essentially' the same (as I understand it).  The current users have to compile their program with a given implementation I think…

That's why I see it as a nice fit for jmePhysics.  I would think JME could figure out what platform it was running on and then determine which implementation of physics to use.  Rather than enable it to use different physics engines (which usually forces you to lowest common denominator of function unless you only have one implementation…), you would use your abstraction layer to interact with several specific implementations of a single physics library.

Couple of references:

So I guess the only thoughts I really have are:

  • Can the abstraction layer be used in another way?  (ie. different implementations of the same library for given set of hardware?)
  • What are the best physics libraries available today?

    I personally would like to make a much greater use of physics than what current hardware would limit me to today.

Are you saying you're interested in writing the implementation wrapper for it? :slight_smile:

XD  I knew that was coming.  Sadly, I don't know enough yet to do so.  Maybe once I spend more time with this system  :stuck_out_tongue:

Falken224 is working on the JBullet jmePhysics implementation right now: