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
rigid body simulation
Author
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.
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.
Quote:Original post by jwace81Quote: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 :)
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.
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.
Author
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
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
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?
Maybe also try the thing of gradually increasing the coefficient of restitution from -1 to 0 as described in the paper?
Author
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 ?
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.
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.
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.
I think that using only one collision point per box-box collision is probably causing some problems.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
