Well, it's official . . . I'm no longer taking votes.
I spent the weekend getting up to speed on C++ IDEs, getting a dev environment set up and going, and getting past the initial hurdles of coding up a JNI implementation. I've managed to compile the Bullet 2.75 source into a DLL along with my own 'BulletPhysicsSpace' class, and create and instance of the Bullet 'btContinuousDynamicsWorld' class from within Java code, and throw exceptions back if you try to create two of them. 
Long and short, the JME Bullet Physics native integration is officially under way. I'm hoping that with everything I've learned, this will go much more quickly than the first one. Much of what I've figured out with JBullet applies DIRECTLY to the native Bullet Physics library, so I'm hoping I'll be spared a lot of the trial and error I suffered with the JBullet code.
In any case. I'll try to give weekly updates, though I make no guarantees.
-Falken
Wow!
You're very fast! AND the featuers are damn good!
Hope you have fun!
Do you know if Bullet-JNI is available for Solaris?
Thank you very much!
Tim
Falken224 said:
Well, it's official . . . I'm no longer taking votes.
I spent the weekend getting up to speed on C++ IDEs, getting a dev environment set up and going, and getting past the initial hurdles of coding up a JNI implementation. I've managed to compile the Bullet 2.75 source into a DLL along with my own 'BulletPhysicsSpace' class, and create and instance of the Bullet 'btContinuousDynamicsWorld' class from within Java code, and throw exceptions back if you try to create two of them. :)
Long and short, the JME Bullet Physics native integration is officially under way. I'm hoping that with everything I've learned, this will go much more quickly than the first one. Much of what I've figured out with JBullet applies DIRECTLY to the native Bullet Physics library, so I'm hoping I'll be spared a lot of the trial and error I suffered with the JBullet code.
In any case. I'll try to give weekly updates, though I make no guarantees.
-Falken
... I love you? Excellent work. Are you saying that you did the "BulletPhysicsSpace" code in C++?
Parts of it, yes indeed. Parts of BulletPhysicsSpace and other classes will be native, and currently, BulletPhysicsSpace is the first.
I'm working on stubbing out the Java classes at the moment, and I'm hoping to get some sort of 'falling box' proof going before the end of next week. Simple collisions and dynamics I don't anticipate taking very long. It's all pretty straightforward, especially now that I understand the underlying concepts fairly well.
The other stuff . . . event handling, contact callbacks, all that stuff . . . that's gonna get a wee bit evil. :evil:
But hey . . . we're on the way, eh?
-Falken
I thought physics engines are supposed to be easy to use? In that case I think the main challenge with such a project is getting the native <-> java interface to work. Btw, I have wrote quite some JNI interfaces already and if you have trouble with that I might be able to help you.
I do appreciate the offer, Momoko. It looks like I'm doing okay so far, though I may ping you when it comes time for optimization. :)
By the time this is done, you definitely won't even know it's native. Super-easy.
-Falken
Probably at some point, though I need to look at merging the current branch into trunk first. I'll let you know the moment I check something in.
-Falken
Falken224 said:
The other stuff . . . event handling, contact callbacks, all that stuff . . . that's gonna get a wee bit evil. }:-@
Correct me if I'm wrong but from what I understand this comes from how Bullet handles things compared to what the current JMEPhysics does. So wouldn't it be easier/better/faster to just change those methods into something more general both implementations can use? If that's too complex we (you) could also use a basic code both implementations can use and more complex and implementation-specific things in clearly separated packages (like com.jmex.physics.bullet and com.jmex.physics.ode vs. com.jmex.physics.common). The responsibility of proper casting/using proper methods would then go to the final coder.
Just a thought.
Oh and btw, great to see you do this :)
you) could also use a basic code both implementations can use and more complex and implementation-specific things in clearly separated packages (like com.jmex.physics.bullet and com.jmex.physics.ode vs. com.jmex.physics.common). The responsibility of proper casting/using proper methods would then go to the final coder.
And actually, that's excatly how I'm coding it up. The trick comes when there's pieces assumed to be 'generic' functionality that's actually specific to a couple implementations. There's actually MORE of this with the JBullet integration than there is with native Bullet. e.g. joint motors, for which I have no happy fix. At some point I may try to wire that up, but it's gonna be slow, unwieldy, and not ACTUALLY part of JBullet.
No, the evilness I was referring to is the callback mechanisms. I'm trying to write this code to be able to function with a minimum of JNI 'line-crossing' (my term) since every time you have to call from C++ code into Java code or vice versa, you're paying a decently heavy penalty. :| That makes it tricky when EVERY SINGLE CONTACT detected in C++ code can end up firing a callback, which by the very nature of the mechanism demands that it be written in Java. Potentially HUNDREDS of callbacks per step is not something I'm looking forward to optimizing.
But once it's done, you should barely even know which implementation you're using. About the only exception might come when I start wiring up some of the softbody / particle effects. You'll have to go COMPLETELY custom at that point, though in the high-end engines, that functionality is common enough we might put some common classes into JMEPhysics to deal with it. Just . . . not right at the moment. :)
Well, figured I'd drop a quick update re: the Bullet integration.
Proof of concept is working. Got C++ code and Java code talking nicely to each other, and objects moving around and colliding according to how Bullet says . 
Okay . . . well . . . only sorta. 
Nothing's QUITE working right. Gravity seems to work, and SOME object collide with SOME other objects, and they bounce a wee bit. But nothing rolls at the moment. :| However . . . Java<->C++ == happygood!!
Anyway . . . for a proof of concept, I'm happy. And exhausted. C++ is a sh*t-ton of work to get used to when all I've used for the last 8 or 9 years is Java. :? Thank God for Eclipse.
As for the weekend, the real-money work beckons. More next week, tho prolly not much.
-Falken
Awesome news! Keep up the good work!
Falken224 said:
Anyway . . . for a proof of concept, I'm happy. And exhausted. C++ is a sh*t-ton of work to get used to when all I've used for the last 8 or 9 years is Java. :? Thank God for Eclipse.
A pointer of type sh named t-ton? interesting :P
'Nother quick update on the Bullet integration.
-Joints wired up w/ positional limits on everything.
-Motors wired up on Slider and Hinge joints. Unfortunately, 2-axis hinge and 6DOF (3 or more axes) are spring "equilibrium" based implementations out of the box . . . a setup JMEPhysics isn't equipped to deal with. I'm pondering whether to add some pieces to the JMEPhysics core classes to compensate.
-All collisions and shapes working correctly.
-Played with OpenCL classes . . . unfortunately they're not working right in the Bullet OpenCL branch ATM. At least . . . I couldn't get 'em working yet
Left to do:
- materials
- contact callbacks
- physics callbacks.
- PhysicsSpace.collide()
- PhysicsSpace.pick()
At that point, I'll check it in and let ppl play w/ it. Then I might move on to the SoftBody and/or Particle features. We'll see.
Hoping to have a win32 release checked in early next week. After that, I'll start worrying about compiling for all platforms.
-Falken
Falken224 said:
Hoping to have a win32 release checked in early next week. After that, I'll start worrying about compiling for all platforms.
shoot me a PM if you want some help compiling for any others (Win64, OS X, Linux64)
I really look forward for a fast native-bullet integration!
If I could help somehow, let me know please!
I think, I will start with updating the jME-Physics-Wiki…
While searching for Phyiscs Engines…, I found this:
http://www.adrianboeing.com/pal/
How about integrating this to jME-Physiscs?
It already support Bullet, ODE and so on…
tim8dev said:Been there
While searching for Phyiscs Engines.., I found this:
http://www.adrianboeing.com/pal/
How about integrating this to jME-Physiscs?
It already support Bullet, ODE and so on...
http://www.jmonkeyengine.com/forum/index.php?topic=12169.msg90563#msg90563
It's worth being aware of, but probably there would be too much work involved to make it a priority right now.
Oh!
Sorry, for the multiple entry…
But currently I'm playing a bit around with JNA,
and I've already made some JNA-Interfaces to PAL,
so it won't be that much work for me to integrate this to jME-Physics!
A branch for this in jME-Physics googlecode project would be nice, though!
tim8dev said:If you got the time and know-how for it, then definitely! JME-Physics is turning out to be quite an extensive library :)
A branch for this in jME-Physics googlecode project would be nice, though!
I think PAL would be very nice, since you got support for Bullet, ODE, Newton, and even PhysX…
And one just have to maintain one branch of Java Code…
I think I will start a new Thread here in the forum in around one week, when I've made enough progress 