Hey y'all,
Figured I'd give a quick update on where I am with this JBullet thing, as well as posting a few questions and gripes hoping for constructive feedback from people who know more than I do. 
As far as progress goes, I've only got one more PhysicsShape to map to JBullet . . . the dreaded TriangleMesh. It's looking fairly straightforward, but there's a lot of interfaces / classes I need to implement / override, so I've been leaving it 'til last. Other than that, I think the dynamics and collisions are mostly worked out. A few remaining items I'll probably have to have help with at some point:
1) Mapping material info across to JBullet. I see nowhere in JBullet the concept of defining material-pair-specific contact properties. Maybe I'm missing something, but it really looks like each RigidBody's contact properties are for all interactions. That, and the properties available are so different from JME material properties, I'm having a hard time translating the two. Perhaps that'll be for wiser heads than mine. For now I've got the coefficient of friction mapped across, and that's about it.
2) JBullet is SUPER eager about setting objects to rest, and it SEEMS to be a global property rather than an object specific one. It's gonna take a bit of time to come up with a solution for that one, but since it's an optimization thing anyway, (albeit an important one) I'm going to put off that piece of integration 'til time for optimizations.
3) I had to create JMECompatible versions of JBullet's Cylinder and Capsule shapes. They work for the most part, but JBullet's CapsuleShape is behaving VERY oddly and I'm getting lost in the math behind it. I have a solution that MOSTLY works now, but . . . yeah . . . it's still kinda odd. Again, that'll be something that smarter people than me will have to take a look at.
4) In the Tests, I've been using, the way ODE and JBullet each handle center of mass provides DRAMATICALLY different results. Honesly, the JBullet one looks right, and the ODE one looks wrong, but that may be an issue for future investigation.
5) Collision events. I can't for the life of me find where I need to wire in to JBullet to capture collision events to hand back out to JME. For now, the physics works, so I'm leaving it alone, but before I can say collisions are done, I have to get that worked out.
So, now that I look at that list, it looks like there's a TON left, but honestly, I've got a lot of the big problems worked out. I think the only big thing left is Joints, and from what I've seen that doesn't look like it's gonna be too difficult. After that, it's all cleanup. I'm going for pretty, clean code right now, which I'll optimize later.
For example, my VecmathConverter utility wastes a TON of objects the way I'm using it right now, and since I'm doing conversions all over the place, that'll be a GC nightmare if I don't work it out. Also, the way I'm mapping JBullet's MotionState to the JMEPhysics Nodes is pretty slick, IMHO, but leaves me calculating a transformation matrix every single time JBullet asks for the Rigid Body's worldTransformation. Not a HORRIFIC state of affairs, as the overhead isn't too terribly much greater, but it could be optimized a bit.
Which leads me to my little gripes about JBullet. I'm not really sure how mature this engine is. It seems to work okay, with some GLARING oddnesses. For example, I never once managed to make the CapsuleShape work right, and looking the math to calculate the bounding, it couldn't possibly work right, unless I'm misunderstanding it horribly. It kinda makes me wonder if there's other stuff a more experienced eye might spot.
Secondly, the super-inconsistent use of proper encapsulation in this library is nightmarish. It may be necessary, but I don't see how. I'm not used to using public fields, for the express reason that it makes overriding properties in subclasses REALLY difficult to do. Maybe getters & setters cost a few extra microseconds but honestly . . . having to track down what parts of the system are grabbing fields directly, vs. calling getters/setters is really annoying.
That all said, I'm discovering it's a slick library anyway, though it looks unpolished at this point. (I may be wrong about the polish. This may be what a solid physics engine looks like, but it's driving me nuts.) Despite my gripes, for the most part it works, and it actually looks pretty fast, and that's what counts. In any case, it's good to have a variety of choices.
And regardless of how this implementation goes, my hat's off to the JMEPhysics guys. Having never had to dig into the guts of it before, I've never fully appreciated how sweet this library is. This API rocks, and regardless of the headaches of wiring up any particular implementation, the whole thing just works nice, and seems to play nice with everything. I admire everybody who had a hand in building it.
So . . . back to work cranking this thing out so I can start on a PhysX implementation.
-Falken
i can't help with any questions, but i want to thank you for taking your time to work on the jbullet implementation.
nice work
XD
Great news Falken224. really looking forward.
- seems more research is needed here (I couldn't implement a good solutions for PhysX either, but it seems to support contact 'tables')
- no biggie - let jBullet decide it
- no idea where the difference should be or why it is harder than boxes
- research as well…
sorry for the short answers - I'm in a steady hurry these days. And I'm of little help at this point as I don't know Bullet or even jBullet - post over at the bullet forum, those guys should be able to help you.
Yes it is and damn I am impressed.
Where do you host your code?
Well, everybody, it's been a crazy week, so I figured I'd drop a quick progress report again.
I have joints semi-wired. By semi-wired, I mean, they work, but not correctly. :) My rag dolls look really sweet, and they flop around all cool and everything, but none of the other joints tests work right. However, I've made a TON of progress, after spinning my wheels for over a week, and I believe that JBullet's joints will give you a much greater degree of freedom than the ones wired up with ODE. For instance, the default joint type in JBullet is the 6-degrees of freedom joint, i.e. full translation and rotation around all 3 axes at the same time. Currently, I'm seeing some pretty severe limitations coded into the ODE implementation, but those may simply be artificial.
In any case, I have solutions in mind for the final technical hurdles, even if I haven't imlemented them yet. So . . . what's left?
0) Correct joints - As I mentioned before, I don't QUITE have joints wired yet. Rag dolls are nice, but you gotta use joints for other stuff sometimes, too, eh?
- collision detection. I think I've ALMOST got this figured out, but right now it's at the node level rather than the geometry level. That's better than nothing, but not really what I wanted, either.
- collision groups. Same thing. Got the theory figured, but haven't wired it up.
- PhysicsPicker - I haven't even tried to play with this, as there's no 'Ray' collision object in JBullet. I'm going to have to figure out how to use the JBullet kinematic objects flags first, but I don't see this as a completely horrible problem to have to solve.
- PhysicsTriMesh - Can't QUITE get this one working. I JUST found a few of the tests that try to use tri-meshes, and I'm getting ArrayIndexOutOfBoundsExceptions. I'm sure it's a little thing, but it's one that's not immediately obvious.
- Material and Joint property translations - Some of these are proving difficult for me to translate. In the case of joint properties, it may be impossible. For example, in JMEPhysics, you can specify individual properties for each translational axis, independent of the others. JBullet applies the same softness, springiness & damping properties to all 3 axes . . . not individually. (unless the axis is locked, in which case, the properties don't apply.) These are smaller details, but important ones. There are other issues I need to figure out regarding joint axes, but for now, I think things work well.
- Perfomance - This thing runs like a DOG right now, and I'm quite certain it's all the crap code I'm writing. I can refactor a lot of it, possibly even after I release it, but this thing's not gonna impress anybody at all for the moment.
And really, truly, I think that's about it. I went back and re-worked the dynamics stuff I wrote until I found the places where I f***ed a bunch of transform logic, so now I understand it all correctly and should be able to clean this code up really well once time for optimization begins. I figure next weekend I should have the rest of the problems worked out, and might even have had the thing hooked up to a profiler a few times. Once I'm at that point, I'll shoot the code off to irrisor and see what the verdict is.
Hope you guys like it when it's done.
-Falken
Huzzah, I'm really looking forward to it. The more the native the better, unless you take advantage of hardware of course :P.
I am sorry I have not completely followed everything that has been said concerning the jBullet implementation… and I'd like to ask something that has perhaps already been said elsewhere…
Will jBullet follow the same interface as the current physics library or will it be completely different. As I said - I am a noob concerning physics, so forgive me my naiveness 
Anyways to re-phrase my question - will it be possible to code to one physics library and use your code also with another (like we in theory will be able to do with LWJGL and JOGL) or would I have to program to one physics lib and stick to it?
I'm going to go out on a limb and say it will use the same interface. JME is written with the idea using interfaces to bridge various other libraries. Hopefully there should be no change to our personal code, just to our referred library.
So just curious any update on this?
Yeah, I can give one real quick.
Unfortunately, the update is that I haven't made much progress. Evil release schedules at the real job interfere again. (speaking of which, http://www.nikeid.com . . . big makeover after next week. Pardon the shameless plug.) On the bright side, my crazy work schedule is clearing up, I've finally got my laptop back, (Geek Squad sucks) and I'm going to probably have some time over the next week to really crank on it. (vacation starting Thursday, and wife's out of town for a week after that.)
I figured if I'm not happy with where I am by end of July, I'm just gonna turn what I have over for other people to finish off. I may do that anyway, but I just went through and started re-writing a big chunk of the dynamics stuff, so I'd like to have that together before I turn people loose on it.
Really the big hurdle left is the constraints. I've got rotational joints mostly wired up, but the translational ones are just a pain, since there's really no way to do them correctly, and I'm having a super tough time tracking down what the problems are. I think this rewrite will smooth some of the problems out (performance included) but we'll have to see how it goes.
I'll give you all an update at the end of next week. Hopefully it'll be good news.
-Falken
Falken224 said:
I'll give you all an update at the end of next week. Hopefully it'll be good news.
Does the lack of that update mean it would have been bad news? :|
chuckle
Yeah, pretty much.
How common a story is this? Well meaning enthusiastic developer takes on open-source contribution, discovers the task is non-trivial, and runs out of time.
I haven't even THOUGHT about this in well over a month. Between losing clients, bad job mojo and . . . blah blah blah. You get the picture.
You want the code I've got so far? Not sure it's useful. Even with a fair bit of work, it runs like a slug, and I'm not sure how much of the wierdness I'm seeing is JBullet and a wierd port vs. my own ignorance. I'd love feedback, though. Shall I zip up the code and send it to you anyway? Make sure the work I have so far doesn't get lost?
It'll be months before I get anywhere on it again.
Just let me know.
-Falken
FYI,
I shipped the code I have off to irrisor this morning. The dynamics stuff is working decently well, but joints are pretty much out of the question for now.
At this point, I'm available for questions . . . prolly irrisor only at first, but if / when he releases it, I'll try to peek in and help out if when can.
Sorry for the lack of progress, everybody. Got some things changing soon that may free some time up for me in the not too distant future, but for now . . . I hope you guys like what's there so far.
-Falken
Thank you falken for the work and effort you have given so far… I am certain this will provide very useful for the community in the long run even if the implementation is not quite 'there' yet…