wayne : Thanks for that! Good for playing, and I've found, at least in that example, two iterations is enough.
VIP3R : What exactly do the numIterations() do then? I can see that that wasn't iterating the collision tests which is where the fault lied. If I drop the numIterations down to 3 the simulation works well, with less variation than using 200 iterations. ODE defaults to 20 but if 3 is enough, isn't 20 wasteful? How much processing overhead does adding iterations have and have does it affect results?
Edit : Actually I can see instability in the seesaw at lower iterations, so I guess it's accuracy of the resolving that numIterations pertains to. I've also lost my reliable results for no reason! In theory I'd have thought with the same setup, the outcome of the physics solution should be the same for all run-throughs. I've heard one explanation of why this isn't the case that's DirectX changing rounding methods on the fly, but it is odd.
VIP3R : What exactly do the numIterations() do then? I can see that that wasn't iterating the collision tests which is where the fault lied. If I drop the numIterations down to 3 the simulation works well, with less variation than using 200 iterations. ODE defaults to 20 but if 3 is enough, isn't 20 wasteful? How much processing overhead does adding iterations have and have does it affect results?
Edit : Actually I can see instability in the seesaw at lower iterations, so I guess it's accuracy of the resolving that numIterations pertains to. I've also lost my reliable results for no reason! In theory I'd have thought with the same setup, the outcome of the physics solution should be the same for all run-throughs. I've heard one explanation of why this isn't the case that's DirectX changing rounding methods on the fly, but it is odd.