I'm doing a little AI experiment using genetic algorithms to drive a little 3d lunar lander. The whole thing's wired up and ready to go, except for one little issue. When I set the controller loose on my lander, I discovered that the physics engine is making my lander take a different course every time, even with the same applied forces. I tried locking in the framerate (meaning I hard-coded a time interval into the update method) thinking maybe it was just rounding errors, but to no avail. The only thing I can figure is that JMEPhysics (or at least the underlying implementation) is not a deterministic engine. Is there any way to set it up to be at the very least a bit more consistent. . . even temporarily? It's just odd watching my little lander guy apply the same forces over and over again, but land in different places and break into different pieces.
The last option I can use is I could record its path from start to end, then just replay it over and over, but it's not my ideal solution.
Any suggestions?
-Falken
I'm no help and useless sorry but do you have some videos of this ?? Must be awesome.
chuckle
I think the term "lunar lander" might have thrown you off. It's just a 3D version of that classic lunar lander game where you can roll the thing back and forth and use the space bar to apply thrust, all the while trying desperately not to crash the thing into the ground. It's just boxes . . . one for the body, four for the legs, all tied together with nifty joints that will do a wee bit of shock absorbing. After you set it up, you just give JMEPhysics the breaking forces and it does all the hard work after that.
Really, it's pretty ghetto . . . not textured, flat lighting, no camera control, no terrain. Just a flat plane 40 units x 40 units x 1 unit and an oddly glowing green box falling from out of nowhere under 1/4 gravity. (I know . . . not exactly moon-gravity accurate, but it ended up looking cool.)
It is kinda fun watching the computer try to land the thing, though.
And watching the legs go splat everywhere when it hits especially hard is cool, too. 
What'll really be impressive is when I get the whole thing wired up and you can watch the entire population of landers all trying to land at once.
In all seriousness, though . . . it's all kinda moot if I can't rely on a consistent physics model, since the fitness calculations are all based on amount of time in the air, intactness of the craft, and not crashing . . . all of which can be VERY close calls, but still okay depending on how the physics works out. With just a slight difference, suddenly a "genome" that's really promising crashes every time you do the run, its fitness score plummets and it doesn't get passed on to the next generation of little baby landers.
Thus my interest in a physics model that will play out the same given a set starting point. Even if I have to lock the framerate it would be helpful to know if it's possible.
-Falken
I have built a GA package along with a NN package. So I know how challenging this is. What kind of tests have you done to ensure that your lunar lander module has been implemented correctly in JMEPhysics? When using a GA, your lander may act different every time. 
Well, I haven't wired up the whole breeding thing yet . . . I'm just resetting the same controller for now, so I'm pretty sure it's set up right. Plus, I had the whole thing wired up to keyboard controls first. I've already got a lot of the genetic code written. I did a 'Traveling Salesman' problem earlier in 3D space, so I have a bunch of pluggable mutation and breeding algorithms already built. After this one, I start in on the Neural Network stuff. It's gonna take a bit of work to get it all nice and refined, but it's a ton of fun. And in the end, I've got a sweet little AI playground.
In any case, I'm kinda working through a couple other ideas dealing with the physics oddness. What I'll probably end up doing is I'll average out a bunch of runs and use that for an overall fitness score. Probably end up with better results that way anyway . . . filter out the marginal successes in favor of more solid performers and all that stuff. It'd still be good to figure out if there's a way to make this physics stuff a bit more consistent, but it's probably not going to be a big deal in the long run.
If anybody has any more ideas, I'd love to hear 'em.
Wha! I always thought ODE would be deterministic, but after looking at the code: it really uses random numbers for quite some things :-o
You can do it like the guy on blogspot and set the randomizer seed to a fixed value (odejava offers this function)…