[ODE] Back in ODE

skjold@cistron.nl skjold at cistron.nl
Wed Feb 12 02:09:01 2003


Hi,


> I've got so many ideas in my head and not enough time to work on 
> it with the real work.....

That sounds so very familiar :)


> Specifically, what 
> part will ODE play in a program like this, is it stable enough to handle the 
> stresses of a genetic algorithm, and is there another physics library out 
> there that has the same functionality as ODE but is more accurate (and will 
> fit in a college student's budget... i.e. free)?

ODE appears to be among the few good options one has when on a limited budget. I've also seen a bit of DynaMechs (there's a link to it on the ODE links page), which is quite good, but that one lacks collision detection (although there are free options to fill that gap too). All in all, I think ODE is a good choice. I'm sticking with it for my own little GA/NN experiments. It's probably stable enough to handle it, if you impose reasonable limits on what your genotypes can possibly represent (for example, if the available power and speed a creature can have in its joints is unreasonable, or it can attain unrealistically massive weight, you'll tear ODE apart).


> 
> Finally, a quick technical question.  Will I complete a given simulation of 
> say 100 - 100 body/joint creatures faster by running them all in the same 
> world (offset by enough that there is no chance of collision), or in 100 
> separate simulations.  If in the same world is faster, would creating a 
> separate collision space for each creature (and the objects in their section 
> of the world) be faster, or is there another way to lower than nasty O(m2^3) 
> term?

Normally I'd think separate simulations are be faster, but like you already suggest there are tricks you could pull to confine each creature strictly to their own collision space. In that case you could even have them evaluated smack next to eachother if they don't affect eachother at all (you could even create multiple simulation worlds and just overlay the screen output in some nifty way). In this case, I don't suspect it would matter much whether to evaluate simultaneously or sequentially. But I do think that 100 rigid bodies for a single creature is a lot. Your computer will be busy enough simulating one such creature in real-time.

Given all those idea's you have, I'd like to advise that you keep those ideas in sight but start out smaller at first. I've often found it disappointing at times when I tried too much at once and failed because of it. It's more satisfying to see something simple work soon and then go from there, than to never see something complex get finished, or even to see it failing for unsound fundaments. I only started experimenting with ODE last week, and yesterday I got my first ODE-world full of little hopping automatons (no brains in there yet, just simple bodies with automated joints). No matter how trivial it seems when it's done, I did get to learn a great deal about ODE, ran into some obstacles and overcame or worked around most of them, etc. Most importantly, I gained more insight into how I would want to setup a good design onto which I can build my evolving creatures. I'm confident that will help me a great deal when things get more complicated.

In short: You can't do a marathon in a single leap, but if you take one step at a time you'll get there automatically.

Hope that helped. Happy programming! :D