So, this is mainly to irrisor, since he seems to be the big guy 'round here with the working knowledge of JMEPhysics.
I've been playing with the physics stuff lately, and having a blast at it. This whole thread I started about deterministic engines got me looking into other engines, and I noticed there's been work begun on PhysX integration. As there are obviously other implementations to be done, and there always room for more manpower, I'm wondering how to become a contributor. I've got a bit of spare time, been doing a bit of fiddling around in the source code on my own box, and would love to help out in any way possible . . . especially since it would expand my understanding of the subject matter dramatically.
Is there a process?
-Falken
Well, I got WAY to busy to work on getting a JBullet implementation for jME; this would be a HUGE benefit to the jME-Physics library. Probably bigger than Physx since most people don't have Physx cards yet.
Do a forum search for JBullet and you will find the conversation that Irrisor and I had.
So, you got a project started & checked in anywhere? I wouldn't mind building off of that. If not, I'll probably start something on my own, but I hate re-inventing the wheel.
I may start in with integrating that in to my local copy of the jmephysics code and once I get something down, go from there. That could be a ton o' fun. I'm probably not going to have much more time than anybody else . . . real world and work tend to get in the way like that. But I keep wanting to move into game development, and this is a place to start. Webapps and database munging just ain't that entertaining after a while. 
Let me know if you have any good thoughts of where to start.
Any contributions in the short-run that are specific to jME / jME-Physics can be posted on the forums via a patch file and a developer can apply it for you. As far as additional implementations you're always welcome to create one on your own and either ask for it to be committed to the repository (which if it doesn't suck is a good way to get yourself a development role in the long-run) or maintain it externally. As far as third-party implementations JBullet, PhysX, etc. they are up to the developers that maintain them obviously.
As far as JBullet vs PhysX I'd personally rather see the PhysX implementation pushed forward since I believe it to be a better engine and still better performance on non-physics card machines than bullet. However, I'm rather biased because I do have a PhysX card on my machine and hope to be able to develop games that take advantage of it in the not-too-distant future. 
I would love to have a jBullet impl for jME Physics because it's pure Java. So if you can do, start right away 
Well, I've been working on it all weekend. The good part is, I've been learning a TON about not just JBullet, but physics engines in general. The bad part is, I'm having a hard time figuring out how to wire up the JBullet lifecycle with JMEPhysics' lifecycle.
I'm not sure if I should post problems here for suggestions, or start another thread for it, but to start with, here's a couple issues I'm running into.
- Overly protected data in JBullet. Thinks like the current force and current torque are private fields that cannot be read . . . only modified, and even then usually only indirectly when calling methods like 'addForce()' or 'addTorque()'. The only way I can figure around this is some evil reflection code (which even then could be prone to overenthusiastic security manager settings) or modifying the JBullet code. For the short term, I've chosen the latter. (I just threw a couple getters in there for the short term) But I don't think that's really a cool solution in the long run.
- Getting dynamics updates back from JBullet is easy enough . . . I just created a 'NodeBoundMotionState' which ties directly to a DynamicPhysicsNode, setting translations and rotations easily enough. The problem I'm having now is how to go the other way. There's a TON of calls in the JME code with something like 'node.getLocalTranslation().set()'. Kinda tough to tie a MotionState to a node when we're not using the node's setters. That one actually took me a while to track down, since I was blindly expecting 'setLocalTranslation()' to get called and wasn't seeing the node's current translation get pushed through to the JBullet MotionState.
This isn't an insurmountable problem, I'm just having a hard time finding a nifty, slick, not COMPLETELY evil way to do it. (For instance, taking all 'get' methods from a node, wrapping the corresponding JBullet vecmath objects with jme.math objects and letting the changes through that way. shudder)
- I've got the whole Joints vs. Constraints thing figured out . . . I just have to figure out how to map things across to each other.
In general, it seems like JBullet is a LOT more complex than JME, until you get right down to looking at the guts of it, where it seems like really hair-splitting details . . . which may after all be required. It's not hard to wire up JME to just use the right subset of JBullet features but it feels like I'm wasting a lot of potential power in this engine. Or maybe they made things over-complicated . . . I don't know. The point is, I've still got more to learn before I get much further, but for now I've got the dynamics mostly down, if not the collisions and constraints yet. I'll get there.
'Til then . . . any guidance people can give would be great.
Hey, it's great that you're advancing with jBullet. I'll try to address you points shortly:
- simply throw an UnsupportedOperationException where you don't have the info and see how far you can get. Usually reading forces should not be very important. We can even think about removing getters from the API in this case.
- jME has no 'dirty' flag for transformations (it might get them for 2.0). So your best bet is to do it each time or detect differences by storing the last synchronized value. The ODE impl does this (DynamicPhysicsNodeImpl, I believe).
- Joints are constraints actually… what's the difference with jBullet?
jME Physics should be less complex than the underlying physics engine. Ideally without loosing power. Of course that's not entirely possible. I have added features as I (or sometimes other peoples) needed them. So even if jME Physics cannot support all features of all engines it could support each single features if someone needed it…
Well, good to know I'm on the right track.
- Ended up doing exactly that for pretty much everything I'm not sure how to implement. And as far as the forces go . . . it seems the only thing that uses them is the physics debugger. There still may be another way around it. Maybe I just say 'if you're debugging we'll do the evil reflection stuff'. We'll see where it goes.
- Yeah, I hate dirty flags and previous value comparisons unless there's really no other option. In any case, I've got most of this one resolved once I realized that most of the lifecycle issues I was running into weren't really issues at all, but more artifacts of the test I was using. The 'TestBasicRepresentation' test actually manually builds the physics geometry. If I understand the API right, most of the time that's not going to be happening. You're going to be calling 'generatePhysicsGeometry()' to do that. If that's how the API is supposed to work, I think I've gotten past most of the wierd stuff. All the translations and rotations are going to take place at the node level, which I've got wired, and if you're changing local translations of geometry attached to the node, you're supposed to regenerate the physics geometry anyway. All it would take is a hook into the 'generatePhysicsGeometry' method to rebuild the actual JBullet Collision geometry and it all should work fairly well. The test, however, never calls the generate method. I've got a couple wierd things to work out with how I'm actually building the JBullet geometry and then I'll probably go through and re-write that test to reflect a more realistic use-case.
- No difference. Just being unfamiliar with physics engines in general, I wasn't aware it was two different words for the same thing. Took digging into the classes to figure that out. rolls eyes But I gotta say, JBullet's got like a dozen different constraints that all seem to do incredibly similar things, or just combine a bunch of constraints into one. It just seems kinda odd. I mean the implementation works and everything . . . it just doesn't seem terribly lean & mean at the moment.
But hey, it works.
I'm expecting to get lifecycle and geometry / bounding issues worked out today or tomorrow. JBullet's actually doing the collisions right . . . I just need to wire into the events it generates and hand that back out . . . then the only big stuff left is joints. Hopefully another couple weeks I'll have a version 1.
And if I have any more problems, I'll prolly post it in a new topic . . . make it easy to find and all.
l8r
-Falken
I don't understand these things well but according to the things I read you seem fast. :). I just wanna thank for your efforts.
Falken224 said:
The 'TestBasicRepresentation' test actually manually builds the physics geometry. If I understand the API right, most of the time that's not going to be happening. You're going to be calling 'generatePhysicsGeometry()' to do that.
That's not right. Using generatePhysicsGeometry is only a convenience method. More advanced applications will use the create* stuff and change local transformations. So for the physics impl you should not care about the visual geometry at all. Only apply the physics collision geometries as geometries in jBullet with their local transformations (translation, rotation and scale).
Other than that you seem very much on the right track. I'm already very curious about the results :D