Page 1 of 1

Solution to incorrect impulses calculations with elasticity

Posted: Sun May 23, 2010 4:50 am
by luca-deltodesco
To slembecke, I tried sending this as a PM but after a couple days, is only in the outbox rather than sent messages, implying to me that you won't have received it at all

http://code.google.com/p/nape/

I've based a good part of my engine on your own, and i've come across what would seem to be a good solution to the problem of incorrect impulses being calculated when elastic iterations are used.

My solution is to store the cached impulse values jnAcc and jtAcc (pjnAcc and pjtAcc in nape) when warm-starting the contacts between elastic and inelastic iterations, and then when evaluating impulses afterwards for whatever reason (sound effects, crushing impulses etc), add the current cached values, with the mid-step cached values to get a total value which as far as I can tell is exactly what it should be, and what would be expected.

Re: Solution to incorrect impulses calculations with elasticity

Posted: Sun May 23, 2010 1:08 pm
by slembcke
Interesting, I'll have to check that out. I figured it would come down to something simple like that, just needing to know when to push the values. I'll have to check that out.

Re: Solution to incorrect impulses calculations with elasticity

Posted: Fri Jun 11, 2010 9:56 am
by ShiftZ
Is that feature(fix) already included?
Just came to need cpArbiterTotalImpulse works correct.

Re: Solution to incorrect impulses calculations with elasticity

Posted: Mon Jun 14, 2010 8:24 pm
by slembcke
I looked at this a bit on my plane flight today. I'm still hoping that there is a way to do it without needing to inflate the size of the cpContact structure any more as it is already very large. I'll look at it some more this week too.

Re: Solution to incorrect impulses calculations with elasticity

Posted: Sat Jul 17, 2010 9:03 am
by slembcke
So. I've had some time to look at this this weekend and I'm really starting to question whether elastic iterations are even needed anymore. Initially they solved the problem of allowing elastic objects to stack stably, but I was always a bit surprised how the implementation actually ended up working. At some point I also added back the ability to handle elastic collisions without enabling any elastic iterations to save on CPU time.

I thought the new elasticIteration-less method was identical to the old way that I handled elasticity, but it turns out that it's not. It reordered and separated a couple of the operations. In fact, I think I'm finding out now that it has completely removed the need for elasticIterations. The stable stacking and jitter issues are completely gone, something I never tested for when I thought it was identical to the old simplistic way of handling elasticity. :oops: All of the old cases where the original way of handling elasticity was failing works just fine with the new way without elastic iterations at all.

So, if you have been using elasticIterations for a long time simply because it used to be the only way to get stable stacking behavior. Try setting it to 0, and see if it works fine without them.