Sign in to follow this  

rigid body simulation

This topic is 4812 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello (1st post), I'm trying to develop a simple rigid body engine (in C#). After a few tries, I based my code on Danny Chapman's code (http://www.rowlhouse.co.uk/jiggle/index.html). I do the same collision response and overall simulation. But I just want boxes in my simulation so I used the separating axis algorithm to obtain collision info (point,normal,depth) instead of Chapman's more general poly/poly algorithm. My test program is just 2 boxes floating in the air. Depending on the orientation, the boxes bounce ok the first time but don't really depart from each other after and start doing weird things after a few correct bounces. Here is my test program with source code http://vlad-game-coding.site.voila.fr/Zip/Physic_Engine_2_Release.zip The user has control over the left box via a force or a torque. Controls : Camera : Mouse, Q,D,Z,X (quake style) Force on left box : F,H,T,B,R,Y Torque on left box : J,L,I,";",U,O Stop velocity,omega of left box : Space Restart simulation : Enter (sorry for non-french keyboard owners:) - Does someone has an idea of the problem ? - Is it the separating axis collision detection that is insufficient ? (returns only 1 point of collision). I doubt since Oliiii used it with success (if I remember right).

Share this post


Link to post
Share on other sites
I tried running it but got "An exception 'System.Reflection.ReflectionTypeLoadException' has occurred in Axiom.exe

I'd unzipped everything and was running from the bin\Debug directory. There's nothing helpful in the log file. This is under M$ Windows XP with all updates etc.

Share this post


Link to post
Share on other sites
Just a hunch...no time to check the code nor the execution.

Are you sure you've departed the boxes from each other at the time of the next separating axis check?

It is quite easy to code a collision system such that impact impulses are correct after the first collision, i.e., the objects are flying in opposite directions but the objects are still interpenetrating when the next check executes and the impact impulses are reversed. In effect the boxes get stuck, shake and after a few rounds (enter floating point arithmetic and cheap integrators) the system blows up.

How does your collision restitution model cancel the interpenetration?

JD

Share this post


Link to post
Share on other sites
Quote:
Original post by MrRowl
I tried running it but got "An exception 'System.Reflection.ReflectionTypeLoadException' has occurred in Axiom.exe

I'd unzipped everything and was running from the bin\Debug directory. There's nothing helpful in the log file. This is under M$ Windows XP with all updates etc.

I'm sorry I don't know what causes this. When I download the zip file, the exe in bin/Debug works for me. I also have XP. I think it's an axiom engine related problem. I updated the zip by modyfing minor config things, hope it works now. I really would like you to see it :)
Can someone launch my test program ?

Quote:
Original post by JesusDesoles
Are you sure you've departed the boxes from each other at the time of the next separating axis check?

I follow MrRowl scheme :
- save bodies velocities and positions
- update bodies velocities and positions
- detect collisions (points,normal,depth)
- restore bodies velocities
- apply impulses to bodies ( I do P+=impulse and L+=(position-x).Cross(impulse) )
- restore bodies positions
- update bodies velocities and positions

(PS: I use state variables x (position), q (orientation), P (velocity*mass), L (Iworld*omega), my mass are always 1 and my inertia matrices are identity (cubes) )

And yes I forgot the next to last step "restore bodies positions" so you were right, I forgot to depart the boxes from each others.
But correcting this did not change the results unfortunately.

The problem is elsewhere. Maybe the impulse is false
I calculate it this way :

-(1+e)vab.n
j = ---------------------------------------------------
( 1/Ma + Iainv*(pos-xa)^n^(pos-xa) + same for b ).n

where
n : normal of contact normalized
pos : position of contact point
xa : position of center of mass of body A
vab : va+omegaA^(pos-xa) - (vb+omegaB^(pos-xb)
* : matrix vector multiplication
^ : vector cross product
. : vector dot product

What is the unit of an impulse ? num = m.s-1 denom = kg-1.m2 so j = kg.m-1.s-1 ? weird
j should be kg.m.s-1 because I do P = P + j (with P=mv)

The problem seems to be that when I do :
P+=j
L+=(pos-x).Cross(j)
j is too small (around 1)
how can such a small change in velocity be enough ? The translational impulse response seems too weak.
as for L, (pos-x).Cross(j) is far bigger since my boxes are of 100 unit length, so the rotational impulse response seems correct.
Is this a problem to have such big boxes ?

Share this post


Link to post
Share on other sites
Quote:
Original post by _Vlad
I'm sorry I don't know what causes this. When I download the zip file, the exe in bin/Debug works for me. I also have XP. I think it's an axiom engine related problem. I updated the zip by modyfing minor config things, hope it works now.


Sorry - still get what's probably the same error. This time running at home (XP home) - when I click on OK to make the error dialog box there's a console window that fills up with some trace output... but it immediately closes! So I con't tell you what it says.

Again, the log file is pretty much empty... sorry!

Share this post


Link to post
Share on other sites
It's not easy to release a program properly with visual studio.
I asked some help on the axiom forum. I'm waiting for their reply.
Does my program work for other people ?

Share this post


Link to post
Share on other sites
Quote:
Original post by _Vlad
Quote:
Original post by MrRowl
I tried running it but got "An exception 'System.Reflection.ReflectionTypeLoadException' has occurred in Axiom.exe

I'd unzipped everything and was running from the bin\Debug directory. There's nothing helpful in the log file. This is under M$ Windows XP with all updates etc.

I'm sorry I don't know what causes this. When I download the zip file, the exe in bin/Debug works for me. I also have XP. I think it's an axiom engine related problem. I updated the zip by modyfing minor config things, hope it works now. I really would like you to see it :)
Can someone launch my test program ?


I'm almost certain that this is the error you will get when you either don't have the managed extensions for DirectX installed, or you have a different version of the extensions installed from what the program was compiled with.
I believe that the version of Axiom that _vlad has compiled is referencing the DirectX 9.0b (summer 2003 update) libraries, so you will need to have those managed extensions installed. If this is the case, then you will need to get the DirectX redistributable package and run the installation with the /InstallManagedDX command line argument. If that does not work (and in some cases it doesn't work), then you can extract the contents of the ManagedDX.cab file, in there there will be a file named mdxredist.msi, which you can use to force the managed extensions to install.

Even though _vlad did not include the DirectX renderer plugin, the Windows platform manager references Direct Input unless _vlad has made some changes to strip it out.

J.W.

Share this post


Link to post
Share on other sites
Quote:
Original post by MrRowl
errr wouldn't it just be easier to write generic c++ with some standard, cross platform libraries?!?


Questions like that usually just lead to religious holy wars over which language is better. I say that it all depends on your personal preference, and in this case, _vlad has chosen to use C# and Axiom. Which once the SDL platform manager is complete should be fully cross platform (without requiring comipilation for a specific platform).

J.W.

Share this post


Link to post
Share on other sites
Thanks for the advice jwace81,

Wow, directX sucks[flaming]
In fact I had to remove the directX project from the axiom solution because of compile problems (things like Light.Commit() not existing) and me not being able to install correctly the managed extensions (/InstallManagedDX very hard to do)
I had some more problems with the reference to directInput which I couldn't remove.

I also installed several directX versions with more or less managed extensions from different versions and seasons so I don't know what I'm using exactly.
Dxdiag gives me DirectX 9.0c (4.09.0000.0904)

And installing several directX sdk with a 16Ko/s connection is a pain so I'll maybe try again but not right now.

Quote:
Original post by MrRowl
errr wouldn't it just be easier to write generic c++ with some standard, cross platform libraries?!?

I have coded also a lot with c++ but
- I now prefer to develop in C#, it's really more productive and elegant I think.
- The axiom engine is awesome I think and it's in C#.
- even in c++, people were missing some msvcrt??.dlls

So if you feel like updating your directx with the information given by jwace81 it would be nice. Elseif I'll do it in a near future (motivation+16Ko/s).

Share this post


Link to post
Share on other sites
OK I found the error,
I was right, the boxes were too big.
Reducing the box size from 100 to 1 corrected the problem.
Don't you think it's weird ?

I updated the test program
http://vlad-game-coding.site.voila.fr/Zip/Physic_Engine_2_Release.zip

Share this post


Link to post
Share on other sites
OK I even know why it depends on the box size :
The inertia matrix of my box was an identity matrix instead of the real box inertia matrix.
Thus I forgot to multiply by a factor of the size of the box.

Share this post


Link to post
Share on other sites
Quote:
Original post by jwace81
Quote:
Original post by MrRowl
errr wouldn't it just be easier to write generic c++ with some standard, cross platform libraries?!?


Questions like that usually just lead to religious holy wars...


Yep - sorry - didn't mean to sound like a troll! Guess it was a long day, or something like that :)

Share this post


Link to post
Share on other sites
Check to see if you are using the same handedness and method of vector and matrix multiplication as the paper from which you got the formulas. For example most people define vector cross products like this:

A cross B = (AyBz - AzBy, AzBx - AxBz, AxBy - AyBx)

where as it can also be defined like this:

A cross B = (AzBy - AyBz, AxBz - AzBx, AyBx - AxBy)

The only thing that changes is the sign of the outcome. What can make the situation even more confusing if you're using the wrong one is that do one cross product and the answer comes out flipped, but do two in the same place and the answer comes out correct :/. Similarly matrix multiplication can also be defined differently in the same manner as above and the answers come out even more confusing. This is a problem I have when implementing some things from papers. The best thing to do is to play around with some signs to see which method they're using. Also try flipping the z components for different handedness.

Share this post


Link to post
Share on other sites
Thanks but I've solved my problem.
I have at least a rigid body simulator with correct box/box collision and even ballsocket joints and hinge joints (using 2 ballsocket joints).
I'm happy now, thanks to MrRowl for his Jiggle source code.

Although it seems quite stable for my 1st simulator, I tried to build a pyramid of boxes (5 levels) and the boxes drift to the side of the pyramid until it falls.

PS: I did not reproduce the body freezing system

Share this post


Link to post
Share on other sites
The drifting is probably because the order in which you traverse the collisions is the same each step - you could try changing the order by randomising it in some way - maybe choosing a seed based on the physical properties of one of the bodies in order to maintain reproducability of the simulation?
Maybe also try the thing of gradually increasing the coefficient of restitution from -1 to 0 as described in the paper?

Share this post


Link to post
Share on other sites
Quote:
Original post MrRowl
The drifting is probably because the order in which you traverse the collisions is the same each step.

I already change the traversal direction each time (as you do) but it's maybe not sufficient. Randomizing is maybe better.
I'll look into the restitution coefficient trick also.

And do you think that upgrading the Euler integrator to something better would increase the stability and/or resolve the stacking problem ?

Share this post


Link to post
Share on other sites
I think the sliding is because of "microbounces" that slowly will move the boxes.
Euler also has a tendency to cause oscillations when objects reach nearzero velocities.
You could try damping all of your motionvalues if they are under a certain threshold.That should make it a little bit more stable.
Switching to RK4 would reduce this behaviour as well.

Share this post


Link to post
Share on other sites
As for the error stuff, you might want to create an installer with the wizard provided by VS.NET, they look great and include or refer to all dependencies of your project.

Share this post


Link to post
Share on other sites

This topic is 4812 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this