Damping of a spring doesn't match analytical solution

[viblo]

From reading this thread it sounds like you know your way around to update and recompile the chipmunk version included in pymunk. However, you might still be interested to hear that Ive updated pymunk svn to use the latest 6.x svn version (as of yesterday) of chipmunk including the spring fix.

[pwagner]

Wow, thanks. I tried myself but got stuck on the generation of the wrapper caused by gcc-xml. That safes me a lot of trouble so thanks again.

[viblo]

If there are no api changes then you can just update the chipmunk src files (the stuff in chipmunk_src, I just copy the files from svn of chipmunk and paste in there) and recompile using the build_chipmunk command:

Code: Select all

python setup.py build_chipmunk

(you might need to clean out the .o files first)

If there are only some minor api change that you want to test and you dont have the generation stuff setup then its probably easier to just update the bindings file directly with whatever changes you need. The auto generation is more of a convenience thing when there's a lot of things updated, its not that complex to add simple methods or change the signature of a function. The low level binding stuff is in _chipmunk.py and I think you will see the pattern quite easily

[pwagner]

So finally I've tested damped springs against the new version you uploaded and its nearly done. The factor of 1/e is gone but it seems that the factor of 1/2 was correct because the damping factor is defined as:
-beta/(2*m)
and it does not matter if you are using an effective mass or absolute mass. Sorry that you have to change your code again but think of it this way: You will never have to change it again except for another solver! ^^

Best regards

[slembcke]

How do you mean? I was able to critically damp a spring using:
float damping = 2.0f*sqrt(stiffness*ballBody->m);

That is the correct formula no?

[pwagner]

Well I think you are correct so I maybe have missed something in my code.

Now another question: Should I use the GoogleCode issue tracker to report possible bugs or is it the same to tell you and everyone else here in the forum? And should I open a new thread everytime I will find a bug?

The purpose of this questions are that I recognize an other basic irregularity: If I just place a body of arbitrary mass and an arbitrary shape into the space and let gravity do its work. The simulation diverges from the analytical solution in a reproducable way. The default velocity function of the body might be the problem. It is now:

Code: Select all

body->v = cpvclamp(cpvadd(cpvmult(body->v, damping), cpvmult(cpvadd(gravity, cpvmult(body->f, body->m_inv)), dt)), body->v_limit); 

or nearly the same as:

Code: Select all

body_velocity = (body_velocity * damping) + (gravity + force_vector * mass_inverse) * dt

For the experiment as described above I have to correct the simulated values by 1/2 * gravity * dt to get the analytical solution. My function looks like: v = g * t + 1/2 * g * dt


Best regards

[slembcke]

Chipmunk (like pretty much every rigid body physics library) uses simple Euler integration. With constant acceleration or forces the velocity should be correct, but the position will be off slightly. Using a smaller timestep reduces the error. You can also implement a more exact integration scheme by overriding the position function at the expense of making the overlap correction do more work.