Jbullet-jme direction JME2 / JM3

Development
1

Hello!



I now been using the jbullet-jme project for a while, completed a few PoC for my own project, while also developing the rendering of the physics bounds for jbullet-jme in JME2.

Resulting I've spend many more hours then I'd care to count trawling through the jbullet source code, and even some bullet code.



The author of the jbullet port clearly has put substantial effort in porting bullet into Java, however the jbullet site states  'features most of Bullet 2.70-beta1', while the bullet physics is currently at 2.76 putting the jbullet version of bullet source at early July 2008 * (assuming the jbullet homepage is correct), meaning that the porting is just under two years old.



Personally I've come across problems with quick moving objects incorrectly colliding, having looked through the source I'm reasonably sure it's because the code in jbullet simply isn't there.

It's easy to see that there exists the risk for any porting that without constant updating, it'll fall behind, both in terms of features and perhaps more importantly performance improvements.



Given that jbullet is a port, and one that keep very closely to the original bullet (at least in class names, can't say for sure about the code) there would be the option to switch jbullet with a JNI binding to bullet instead.



So, any thoughts on whether bullet JNI will be used instead of the port jbullet at some point  the future?



I suspect this is a question more directed at normen, but would be interesting in general view / opinions



Cheers

Chris




2

Native bullet is definitely the future of jme bullet physics, especially now that OpenCL use in the native bullet is coming.



In the jbullet-jme googlecode repository you can already see the beginnings of a native jme-bullet wrapper. jbullet-jme was designed in a way that it is possible to move the whole thing to native without changing much for the user.



I want to avoid writing/using a generalized JNI wrapper of bullet as this would mean another instance that needs to be maintained and as we saw with ODEJava and now with jBullet that is not something one should depend on. So the JNI wrapping will pretty directly happen in the current PhysicsNode etc… objects, tailored to jme.



There, now its out. Please refrain from asking when it will be done but be happy to know that your current code won’t be broken when its coming :wink:



Cheers,

Normen

3

Bravo …a blisteringly quick reply normen!

normen wrote:
OpenCL use in the native bullet is coming.
I'd actually not heard of OpenCL before, just googled it - sounds like a very good idea.
normen wrote:
bullet-jme was designed in a way that it is possible to move the whole thing to native without changing much for the user.
It almost sounds like you've created a layer of abstraction from the physics implementation - good stuff!
normen wrote:
So the wrapping will pretty directly happen in the current PhysicsNode etc.. objects.
Huh, makes sense I suppose
4

hi,



just a short question:

I've recently looked into DMM a bit as it is said(waiting for confirmation) that a Version is going to be freely aviable.

DMM is based on bullet.

Thereby the need would arise to wire this by JNI too.



Will it be possible in the way which is set to be gone?

Would this mean to implement a fully blow physic binding?



Thanks for listening

Nebelritter

5
nebelritter said:

just a short question:
I've recently looked into DMM a bit as it is said(waiting for confirmation) that a Version is going to be freely aviable.
DMM is based on bullet.
Thereby the need would arise to wire this by JNI too.

Will it be possible in the way which is set to be gone?
Would this mean to implement a fully blow physic binding?

As said I do not want to create a generalized bullet JNI binding but one specialized for jme.
6
normen wrote:
specialized for jme
+1

Thinking about it now, a specialized / cut down version to access only the methods that are used by JME for physics is the most efficient solution.

Otherwise are so many classes in bullet you'd have to bind for a general binding (ones that you wouldn't need), and as there should be no need for direct access to it either, because it'll be abstracted for developers using JME  :D

Where would the value in creating a generalized physics binding for JME usage be?
Especially as the usage in JME would be specialized.
nebelritter wrote:
DMM is based on bullet.
Not entirely sure about that, it reads more like DMM uses the rigid body physics components from bullet.
DMM does look interesting though, as the pixelux homepage describes it 'deformations and fractures' - some pretty cool stuff  :-o

http://www.amd.com/us/press-releases/Pages/amd-ecosystem-2010mar8.aspx
http://www.techpowerup.com/117030/AMD_Open_Physics_Initiative_Expands_Ecosystem_with_Free_DMM_for_Game_Production.html
http://www.pixelux.com/dmmEngine.html

I'd assume that if parts of DMM were to be included / used in the JME physics (at some point in the future) only the precise methods / classes needed from DMM would be used