So, I just committed a quick fix to the JBullet integration. It was a small compilation error (oops!) related to the recent 'addForce' fixes I made. It got me looking at the code a bit more closely. For the longest time, I've been wondering about the concept in JBullet of a simulation 'step size'. It was an interesting concept to look at, but it never occurred to me the underlying reason for it . . . determinism.
With Bullet, (and JBullet) if you set your simulation step size to 1/60 of a second, EVERY SINGLE STEP is 1/60 of a second. If your framerate is 1/120th of a second, Bullet will INTERPOLATE the motion of the bodies in your simulation, but WILL NOT actually perform physics calculations until 1/60 of a second has passed. This is the fundamental reason why force application was not working correctly in my integrations. When I called 'addForce()' on a rigid body, my framerates were often running MUCH faster than the step rate of the simulation. Internally to bullet, since this force lasts for LESS than a simulation step, is essentially negligible and is ignored. Only if a force is present during a 'simulation step' is it actually applied.
My interim solution was simply to calculate the appropriate IMPULSE and apply it to the object. (impulse = force * time) This solution DOES WORK, but it breaks one fundamental piece of the bullet library: determinism. Now, with the JMEPhysics Bullet / JBullet integration, your physics sims starting from the same start point with the same settings MAY NOT replay exactly the same way.
So, my question is . . . is this a big deal for people? Do I need to go through and put a 'forceDeterministic' flag on the JBulletPhysicsSpace so that the option is available? Or is it more important to have a more 'realistic' simulation than a deterministic one?
Secondly . . . I'm finding more and more features of JMEPhysics that are just not well suited to other physics integrations. Do we need to start looking at upgrading JMEPhysics to a new version with a more general API? Or should I look at starting from scratch with a whole new one of my own?
I'm quite curious to find out what people think. Any thoughts?
-Falken
Well i wuld sys the whole jme physics api is outdated, i prefer one simple working implementation (with everything working as expected and on placeholder functions)
- 1
if it entails ripping it apart and writing it from scratch to accommodate a more streamlined and functional physics library in jme then i'm all for it…
Before i forget:
A clean API has one big pro:
Add a PhysicCache, where you can store shapes/RigidBodyConstructors, in case you use them several times.
(Aka every bullet uses the same shape, no need to create several ones, just share one)
Great Work!
I would like a clean, general API,
and some "plug-in"-framework, for adding features not covered by the General Implementation.
So you have some Generic-Interface + some "optional" interfaces to support more advanced features.
So a Physics Implementation provides information about whether these optional features are supported.
Maybe it could also made more "concurrent friendly" :mrgreen:
But, I do think you should be able to change your used Physics-Implementation.
It would also be quite nice if it worked with jme3 aswell!
+1 on ripping it apart! Although ODE works I do think it's inferior to Bullet. I hope you don't have to rewrite the whole api, but it would be nice as said before for integration with JME 3 if at all possible.
Games are already somewhat non-deterministic due to variable framerate, if I understand this correctly, so there isn't much consequence for doing it this way. If you need deterministic simulation you could run the application with fixed time-step.
Well that was the point, due to the way JBulletworks, it i deterministic even with varaible frame rate, because it internally use a fixed one and interpolates between
But i guess it only accounts for the physics. If you get an variable framerate going in your other code, ai, whatever, i guess that brakes determinism anyway, because you are presumably interacting with the physics from there…
btw, to me it seems that having a framerate more than 60 fps, would be overkill in terms of the physics accuracy needed for most games… The errors that pile up from other stuff, solvers, damping, blabla, will quickly kill the accuracy gained from having the more fine-grained framerate?
@silcowitz
regarding the JMEPhysics api wackiness . . . constraints are EXACTLY what I was thinking of. That 6-dof joint is a pain in my ass 'cause it really doesn't do all the things that are implied by having 6 axes . . . 3 rotational, 3 translational.
Then you have 2x rotational joints. Well, is that a hinge2 joint, or is that a coneTwist joint? And it's pretty easy to set limits and limit restitution and damping and so forth, but try adding springs to a joint and damping and restitution and friciton and all that jazz that's implied with the JMEPhysics API. Doesn't work with MOST physics engines, but there's no part of the API that'll tell you that other than throwing 'UnsupportedOperationException'.
Here's what I want to see in the API:
- A 'supported features' API. You should be able to query PROGRAMMATICALLY whether a particular joint type, material property or other feature (such as soft-body physics, particles, deterministic behavior, etc.) is supported.
- Tighter integration with JME. You shouldn't have to worry about creating a 'dynamic physics node' or a 'static physics node'. You should just be able to add a node to the physics space, along with a definition of how it should behave. (static vs. dynamic, rigid body, soft body, material properties, particle properties, collision shape, etc.) Let the API worry about how to interact with JME . . . you're going to HAVE to anyway if you ever want to do softbody physics with this, as you'll have to actually be changing the display meshes instead of just rotating and translating them with the node they're on.
- . . . I had something for this number, but I lost it . . . I'm sure I'll come up with something.
In any case, I plan on making it more flexible and extensible when I get around to building it.
sigh . . . anybody up to changing the rotation of the earth to give me 36 hour days? Otherwise, I'm gonna be pretty short on time.
-Falken
… and to the stuff about the physics api. Falken, Can you give some examples on what you mean by
" more and more features of JMEPhysics that are just not well suited to other physics integrations" ?
Cause i think I would agree with you. One example could be the way that joint constraints are handled. It kind of encourages you the create your own customized and general joints. However, doing robust and correct handling of general 6-dof joints is really complicated on the physics side of things. This is mainly due to the need for error correction in every time-step. An indication of this could be
http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=4250
Im not sure how things are with this 6dof joint, if it really works robust or not. Can anybody share their experiences?
However, in games you often have a huge amount of "error" that must be corrected, and its much easier (but still challenging) to make this robust with simple joint types like hingejoint, twistcone, etc. (still including limits, motors and friction of course:). When you create complicated constraints, you always increase the risk of an animation blow-up, which would pretty much kill your game instantly.
My point is then: Go for simple, fast and robust solutions, and dump all the general and complicated stuff that isn't really needed.
silcowitz said:
My point is then: Go for simple, fast and robust solutions, and dump all the general and complicated stuff that isn't really needed.
+1
Anyhow, if I understand correctly the problem develops when a force is applied for less than 1/60-th of a second as bullet will "not have seen" that force change. Now correct me if I'm wrong, but it appears to me such small force changes will hardly ever occur (a constant force is generally applied over time, collisions, while in essence force over contact time transfers are better described in games as impuls) so I'm a bit lost on the practical advantage of any fix for this problem... unless one would want to make a very neurotic AI (since no human has that kind of finger speed) with an overpowered engine... and even if that were the case I'd say it's their problem and they should compute their impuls themselves. But that's just me.
Falken224 said:Try give a clear picture and guidance for how people can get deeply involved and help. The documentation efforts are also starting to gain momentum, so if you stop by the documentation threads maybe someone can hook up with you to take care of most documentation needs. This development would certainly benefit from a couple dedicated pages on the wiki.
*sigh* . . . anybody up to changing the rotation of the earth to give me 36 hour days? Otherwise, I'm gonna be pretty short on time. :(
Having a look at PAL (Physics Abtraction Layer) could help the design of a new clean Physics API:
PAL : Physics Abstraction Layer : Home
I did not use it personally, but I think PAL implements in C++ several features requested on this topic.
lf
I'd say continue integrating jbullet into jmePhysics2 and start marking deprecated methods or throwing exceptions, literally omitting current (ODE-specific) functionality. Maybe then it becomes more obvoius how to go about with jme integration / softbodys etc?
I think this way it might be easier for others to follow what is happening because some might already have an idea about jmePhysics2. I am currently messing about with the jmePhysics-jbullet branch for example and could more easily adapt and give feedback this way, I closely watch the googlecode site.
Of course this would lead to a completely "new" api eventually but you might have more followers during the way?
…Just my two cents, anyway you know best if the current api is structurally adequate to go about like this
Regards,
Normen
Not a horrible approach, but I shy away from it for two reasons:
- Slowly evolving an existing system / API into another is not a trivial process. In fact, it's often less time and effort intensive to simply re-write from scratch using the knowledge and lessons learned from the old one. It's not always the BEST way to go, but . . . usually the end product is FAR more solid.
- Breaking a current API is seriously problematic, especially when you have products already based on it out in the wild. Granted, those products SHOULD be based on a specific version of your API and won't be upgrading the core system regularly, but for the ones still in development, you're going to irritate people if you start changing features left and right.
Besides which, I'd like to make a somewhat radical change to the API. I'm actually going to start a topic in the physics forum to discuss the ideas I've been pondering and get feedback before I start coding. Whatever it is I do, I'll be doing it against JME3. JMEPhysics needs to keep being developed in the short term, but in the long term, I'd like to see a more robust physics API that not only supports multiple physics implementations, but PARTIAL integrations as well. And actually, I'd like to put it all in the 'physics' package of jme3, but I haven't run that by anybody yet, so nothing's official.
Anyway . . . still all talk at this point.
-Falken
Yes, I see where you're going, if it's a real restructuring of the whole API it makes more sense to implement a new one. I thought about the change happening in the jbullet-branch and not affecting jme2-projects too much but anyway…
From what I read it felt like there were just some things in jmePhysics that are quite ODE-Specific. If its a matter of redesigning the whole thing then of course starting from scratch is the better solution. I was just hoping for some accessible development versions to check the whole thing out in a game developers environment and give feedback.
But since the whloe jME3 thing seems to be definitely a thing for the future I suppose there is much feedback to give on the jmePhysics2-jbullet/nativebullet integration for improving an emerging jme3-Physics… 
Anyway thanks for the work so far, great working without the sporadic c-nullpointers (or whatever) of ODEJava…