#### Archived

This topic is now archived and is closed to further replies.

# Rigid Body Motion update Problems

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

## Recommended Posts

hi.. 3 days now have passed and i am still unable to fix the problem of the motion of the rigid body i will explain step by step what am having and what i am wondering about... i have a rigid body which is composed of a set of boxes ( actually they are the boudning boxes of the object parts) i assume that each box has a mass equal to its density* its volume and i assume there will be 8 masses , one at each end of its box with a mass = 1/8 of the box mass (i calculate this for each box) having those data in hand..and an orientation matrix for the whole body and a translation vector for it.. i am able to find its center of mass and its inertia tensor matrix ( and also the inverse of it which i will need later ) then....the problem lies in the body update function.. which takes the time delta i make several steps there.. i first compute the CG of the body in the world then compute the inertia tensor.. then update the position like this.. m_Center+=DeltaTime*m_LinearVelocity; then comes the step of updating the orientation of the body i am storing in a matrix which i should update it each frame i read many articles and i found that i can update it using 2 methods a matrix based method and a quaternion based method the matrix based method is unstable the object starts to roate but after a few frames everything goes to infinity and i tried also the quaternion method.. in which i need a quaternion q that i update at each frame and i use it to compute a matrix called Mr which i multiply by the rotation when i create insert my own values into this q..the rotation works fine but when i make the update for it.. the object suddenly goes to infinity (without rotating first like in the matrix) am still unable to find the exact solution in the quaternion update equation m_Quaternion = m_Quaternion + 0.5f*DeltaTime*Wt*m_Quaternion; where Wt is another quaertion which i got from the angular velocity how do i really get that quaterion..is it by just inserting the 3 componets into the quaternion''s x,y,z ?? another question...if am just using matrices..why the motion start fine then starts drifing until it reaches infinity ( i think this is due to numerical errors) Flutey Shady El Mously Egyptian Game Programmer (there is no knowledge that is not power)

##### Share on other sites
You most definitely will NOT be able to get away with using an Euler integrator on this problem. Try at least a Verlet integrator. I would recommend a Runge-Kutta... 4th order is most commonly used because of certain optimalities, however you might be able to get away with a lower order update. You should be able to find plenty of resources with regards to these numerical methods online, otherwise borrow a copy of Numerical Recipes from somewhere (your local library or college library?). The code implemented in NR is not the most efficient, but it works.

Further more, might I make one small suggestion as to your representation. Instead of having the mass of each box set at a single point at one end of the box, why not distribute the mass of each box to the 6 planes that define the box... so one point in the centre of each plane? Where two boxes join on a place, you can sum to two points together. This gives you more points to worry about, but would smooth (and make more accurate) your computation of the centre of mass and the contribution to inertia of different parts of your object.

Just an intuitive thought...

Cheers,

Timkin

##### Share on other sites
the rbd formulas are wrong, you will never get gyroscopic effects using them (either method, adding to the orientation matrix and reorthognalizing or adding to the quat and renormalizing!) !

as to the integrator, how can you use second order methods, if your angular momentum is constant? the derivative is zero!

##### Share on other sites
flutey, the difficulty with debugging rigidbody simulations is the large number of calculations that are involved in calculating these simulations. You *must* think of a way to test *every* calculation. You need to put test values directly through the simulation and watch each stage. Compare the values with those that you expect to see at each stage. Believe me, you will find dozens of mistakes this way. You also need to visually output the outputs of various important calculations *during* a simulation. Coloured line vectors with name tags work particularly well for me.

Another thing to think about. If this is your first attempt at a dynamics simulator (it sounds like it) then you really should think about keeping this as simple as possible. Bouncing balls, then cubes, then cube/sphere hierarchies.

Lastly, matrices are more than adequate for the task at hand. You can use quaternions instead if you want to, its really up to you. Remember, OpenGL, Direct3D, Renderware Graphics (and every other 3D API that I know of) are built upon matrices. They are not bad. They are very very good and you should really know them back-to-front *before* you play about with physical simulators. Don''t be afraid to use matrices. They get quite a bad press from some programmers who neither understand matrices *nor* quaternions [but they''d have you believe otherwise.] Have a look at Diana Gruber''s ''Do We Really Need Quaternions?'' article. It really is a breath of fresh air.

Euler integration is more than adequate too. I find that instabilities only occur if you are running the simulation at 5fps or less.

Hope that this helps flutey. Don''t give up hope. If you put in the effort then things will work out (especially if you adhere to my advice!).

Kind regards,
Kevin
---------------------------------------------------------------
A message to the rabble...
I know that some of you will be itching to start an argument (and now that I''ve mentioned it you''ll be at great pains to appear reasonable). It won''t work. I will not reply to self-smug people who spend far too much time trying to score points than do any actual work that is of any relevance here.

I have a university degree in physics and a postgraduate degree in software engineering. I have been programming physical simulators for the past 2 years (amongst other things). I have complex simulations that run for hours using matrices and euler integration that look just as good as anything you have ever seen and I *never* have instabilities and I *never* need to re-othogonalise *any* matrices (yes, it can be done) *PLUS* I get paid for this sort of thing.

Kind regards,
Kevin

##### Share on other sites
quote:
Original post by Anonymous Poster
Euler integration is more than adequate too. I find that instabilities only occur if you are running the simulation at 5fps or less.

As you point out Kevin, Euler integration IS adequate for small timestep updates of certain rbd systems. However, as a general rule, linear extrapolation of a non-linear system is less accurate and care must be taken with the overall simulation design, hence my suggestion that a beginner try a higher order method. It''ll obviously chew more cycles, but it''s a safer bet that instabilities will have an alternate cause, which can then be debugged more fruitfully.

As to your comments ''to the rabble''... those are unecessary and are only likely to start an argument, rather than stop one. Many members of these forums have undergraduate and postgraduate education, with many years of experience. Don''t be too quick to judge people simply because they offer an opinion that''s different from yours. Certainly, if you have evidence to back up your claims, then by all means do so... but please don''t stifle a discussion just because you think you are right.

Cheers,

Timkin

##### Share on other sites
flutey, I hope that you don''t mind, but I have addressed TimKin first. If you want, you can skip the first paragraphs entirely.

----------------------------------------------------------------
Timkin, I agree with some of the points that you make. If you have been about the scene then you will know how much emotional many people can get regarding the subjects that I touch on in my reply to flutey. It is precisely for this reason that I added the message that I did. You may think it unfair to refer to these people as a rabble. I quite agree. A rabble, in general, is far more reasonable and mannerable! I am appalled at the behaviour of this large minority within our community. I''m a reasonable person. I don''t mind debating the pros and cons of a subject, but I will not be involved in a witch-hunt like that directed at Diana Gruber. It was absolutely shameful.

If you would like to continue this discussion in private, then I think that would be best since it only detracts from the help that can be given to flutey. I will send an empty email message to you so that you can do this.

Kind regards,
Kevin
----------------------------------------------------------------

flutey, I don''t agree that a beginner should use a Runge-Kutta intergrator or similar as a first attempt at getting a simulator off the ground (especially for a novice). You should keep things simple. I find that for simulations that run > 20 fps that a more precise integrator does not produce any discernable benefits [you really have to be running < 10 fps to notice any benefit of a higher order integrator].

flutey you are obviously a beginner. The code that you have written probably has many bugs in it (a blight that we all face)that need to be located. Hence my advice.

1. Keep it simple!!
2. Debug simulation visually by displaying vectors for applied forces/torques etc.
3. Debug simulation with synthetic input checking results at every stage with values that you calculate yourself.

These 3 tips are priceless. If you do all 3 flutey you should be able to get your simulator off the ground.

P.S. If you haven''t already done this, do a search on the net for David Baraff. He is a Prof. of Robotics and has published many user-friendly papers on rgd. His papers will show you step-by-step how to get your simulator off the ground and he will even explain the use of quaternions if you later need help with these.

Kind regards,
Kevin

##### Share on other sites
i have an idea, why don''t you post some code demonstrating gyroscopic effects under zero torque!

anyone?

just so we''re clear, cuz you people have a tendency to nit-pick and blame other shit, i want to see a cube spinning around one of its local axis and tilting (nutating) around a world axis, and it better do this indefinitely, like a full >360 degree nutation.

let''s see the shit..

##### Share on other sites
You''ve got me laughing at least! What the hell has this got to do with the original question anyway? Still laughing :-) flutey''s got some debug/development work ahead of him. He can account for gyroscopic motion a bit later on (if he ever feels the need to simulate a spinning top). That''s certainly not what''s wrong with his code at present...

As to your gyro demo with full precession etc, I don''t have anything (gyroscopically speaking!) handy at the moment and I''m hard at work doing other things. You do realise that gyroscopic forces/torques are hardly ever simulated in games. I suppose that we need more spinny things! I don''t mean to jest because it is a good point (humorously put). When I get some free time I''ll have a bash and send you a copy of the results. Hopefully it''ll be more interesting than humorous!

B.T.W. flutey I hope that you''ve made a start to your debugging! :-)

Regards,
Kevin

##### Share on other sites
quote:
Original post by bpj1138
as to the integrator, how can you use second order methods, if your angular momentum is constant? the derivative is zero!

That would depend on your frame of reference...

Timkin

##### Share on other sites
quote:
Original post by Anonymous Poster
I''m a reasonable person. I don''t mind debating the pros and cons of a subject, but I will not be involved in a witch-hunt like that directed at Diana Gruber.

Point taken. I''ll view your earlier post with this in mind.

quote:
Original post by Anonymous Poster
If you would like to continue this discussion in private, then I think that would be best since it only detracts from the help that can be given to flutey.

Actually, I think an intelligent discussion will ALWAYS benefit those that read it, even if it is slightly off-track. Threads always evolve and grow... and this is a ''good thing'', provided we also remember to answer the original question (which has been done).

quote:
Original post by Anonymous Poster
flutey, I don''t agree that a beginner should use a Runge-Kutta intergrator or similar as a first attempt at getting a simulator off the ground (especially for a novice).

Merely a difference of opinion. I would say that while Runge-Kutta is certainly a more complex algorithm, I don''t believe it is beyond anyone that can understand the physics of rotational dynamics. As to whether it is appropriate to the problem at hand, that is a completely different question.

quote:
Original post by Anonymous Poster
You should keep things simple. I find that for simulations that run > 20 fps that a more precise integrator does not produce any discernable benefits [you really have to be running < 10 fps to notice any benefit of a higher order integrator].

I find it interesting that you use iteration frequency to discuss complexity rather than the non-linearity of the problem. There is certainly a correlation and it''s an interesting way to view the problem.

It really gets down to the integration frequency as compared to the simulation frequency. No matter what equations you are integrating, there is always a sufficiently small timestep over which the integrand can be held constant and the anti-derivative assumed linear. As you point out Kevin, you have found this to be anywhere from 5 frames per second (I''m assuming one frame per iteration) upward for your rbd simulations.

The problem with this (as I see it) is that ANY linearisation of the problem - while possibly stable due to small timestepping, is inherently inaccurate. Obviously the extent of this inaccuracy depends on the difference between the linearised system and the full non-linear system. A higher order method will guarantee a lower error propogated to the next time step... and this was the basis for my suggestion of using Runge-Kutta over Euler Integration. This was also the basis for me saying that you could not get away with using EI... because I don''t believe it is accurate enough on this problem (but then I don''t claim to be an expert on rbd''s).

Ultimately Kevin''s points about debugging are valid no matter what integrator you implement. It may be the best course of action to implement your system with an Euler integrator and perhaps to later implement Runge-Kutta and compare the differences!

Whatever you choose, good luck!

Cheers,

Timkin

##### Share on other sites
Good TimKin! We''ve managed to meet in the middle!

You''re right to mention the inaccuracies inherent in a linear solution to a non-linear problem, but the point is that when you get down to it the question that must be asked is, ''Will the user notice?''

BTW have you found that your simulations benefit from a more precise integration method. For me, modelling spring type behaviour is a good candidate for a better-than-euler integration method - as you would expect - although you can instead think about implicit euler integration as long as you don''t mind the inherent energy loss that occurs (most springs are damped anyway so this is usually not an issue).

As to the decoupling the physical update from the graphical update. Its good to do this, but remember that to achieve a smooth visual update the simulation must be *at least* double buffered (if not triple) i.e. you must have the result of the previous integration, the result of the next integration, and you must interpolate between them to find out where the simulation should be *now*. This method is obviously useful in dealing with a level-of-detail for the game/simulation i.e. less cycles spent on objects that are either far away from the viewer or that do not require too much processing (for whatever reason). But this is probably something that flutey should only think about when he''s got the basics up and running.

I hope that I''ve covered all points. Its been nice speaking to you TimKin.

Regards,
Kevin

##### Share on other sites
gyroscopic motion happens all the time, kevin. think of a log rolling down a hill going over some rocks sticking out, the rocks would give it nutation, if the rock hit the log off-center. if the log dropped off a cliff shortly after hitting a rock, it would nutate indefinitely. same thing with rolling cars..

moreover, rbd and simulation in general isn''t about "modeling" different physical phenomenon. either your simulation is generalized and correct and accounts for nutation or it doesn''t, there is no middle ground there.

lastly, stop blaming flutey for buggy code, you can''t and don''t know that. the more you do it, the more i''m beginning to think you''re trying to hide your ignorance on the subject, and failing to do so.

##### Share on other sites

It is entirely obvious to me that you know nothing about the subject. Are you a college student by any chance? Because if you were working for me you would have just signed your own dismissal. When you do eventually get a job you had better tone down your remarks and not be so outspoken with people that you hardly know or you will quickly find yourself on the slagheap.

I and other people that are in the industry do not have to be here. If impolite people like you wish to have access to us then there is a price to be paid. That means immature, disrespectful young adults like you must be polite. Do you understand? Is that clear enough for you? We are outnumbered at least 10 to 1 by you school and college students. We are trying to do you guys a favour for heaven''s sake. A little respect and politeness is all the thanks that we ask in return!?! Do not speak to any of us (or anyone else for that matter) in this disrespectful way, either on this board or in real life.

As to your points that should have been phrased as polite questions, I''ll get to them now.

''gyroscopic motion happens all the time, kevin. think of a log rolling down a hill going over some rocks sticking out, the rocks would give it nutation, if the rock hit the log off-center. if the log dropped off a cliff shortly after hitting a rock, it would nutate indefinitely. same thing with rolling cars..''

You are confusing gyroscopic effects with rotational effects. You are confusing cause and effect. Of course objects rotate when they are acted upon by forces but they do not rotate *because* of the gyroscopic effect. It has been sufficient (thus far) in most games to have the rotation *without* necessarily taking into account gyroscopics i.e. we apply externally generated forces and torques to objects, but we do not take into account forces and torque that are internally generated (gyroscopic effects). I can’t think of any game, off the top of my head, where I’ve seen nutation and so that means that I’ve never seen a game that applies gyroscopic effects. Can you? If you pay any attention to the game charts then you should know of a certain blockbuster game that has been doing very well on the ps2 for many months now that does not bother with gyroscopics. Yes Shock! Horror! No nutation! Has anyone complained? Not to my knowledge (in fact quite the contrary). Yes, that game! Don''t even be so rude as to ask me how I know this! I hope that I''ve made myself crystal clear here. Have a good think about it if you don''t quite understand. I know that you young people are very idealistic ''if it''s going to be done, it should be done properly...'' Nothing wrong with thinking this way when you''re young and lacking in experience, but eventually when you come to actually have to do that thing (whatever that thing may be) then real-world solutions often are very much different! Yes, we often have to make comprimises! So to paraphrase you, there *is* a middle ground here. Most people call it the real world. Remember planet Earth? Because you had better get your feet back down on it quickly.

As to flutey, he does have buggy code. That''s why it doesn''t work. If it looks like a bug and acts like a bug then it probably is a *whole bunch* of bugs. There’s nothing wrong with having bugs in your code. So don’t take it as a slander! What would be tragic would be to code a complex piece of code without thinking of ways to rigorously test that code. Don''t you know anything? This is his first attempt at this kind of work and I gave him some very good advice and TimKin added additional information that will prove useful to him some months from now as he moves on to more complex stuff. When he follows my advice he will surely find those bugs. When he breaks out into the industry he''ll find that we do this kind of debugging all the time! But at least he is trying to do some rbd. What have you done? Sweet FA? That’s shown by your naïve commentry. If you don''t have something to add that may help flutey then don''t bug *either* of us! If you have a valid question that you can phrase politely then start another thread. If you''re not part of the solution you''re part of the problem.

You are a rude little boy, bpj1138 and you do this board a great disservice. It was a pleasure speaking to Timkin. He was both polite and knowledgeable. You, by contrast, are neither and you suffer for it. Do not speak out of turn to me again!

##### Share on other sites
I had similar problems too. My guess is that ur angular velocity calculation is going out of bounds. This could happen because of incorrect angular velocity dampening or the calculated inverse inertia tensor is wrong (for eg. some of the terms are INF). Either way best bet is to fprintf out all the intermediate results into a file and run the program for a few 100 iterations and analyse the output log file.

As far as Quaternion and Matrices are concerned, use whatever is convenient to you, both works. I use both. I use quaternions for my rigid body simulator, and it works fine.
You can do away with Euler integrator initialy, but do have a 4th order Runge Kutta Integrator also in place. You can use Euler integrator while doing collision detection, and Runge Kutta for Collision Resolution, because a higer order integrator helps in achieving a better collision resolution (in my experience, no flames pls).

And about calculating the delta_quaternion...refer the David Baraff's first paper - An Introduction to Physically Based Modeling:Rigid Body Simulation I—Unconstrained Rigid Body Dynamics. This paper explains rigid body simulation in detail, including the quaternion.

Hope this helps!
Cheers

There is no problem so complicated that it cannot be complicated further.

[edited by - aanand_420 on April 23, 2002 11:52:09 AM]

##### Share on other sites

kevin, your message is so wrong in so many ways, i don''t know where to start.

first, nope, i''m not a college student, far from it.

second, it seems to me you didn''t even know basic qualitative concepts about rbd, you still seem confused about what "gyroscopic effects" are, so how is it that you''re doing "us" (whoever that is) a favor by coming in here and posting your messages?

third, i really don''t care what your "real world" constrains are, they''re not my constraints! to me the real world is reality, not some corporate agenda. what''s more is that you use this concept of "a deadline" to refute other''s posts as if it was a scientific argument! it is not..

lastly, your message is full of acknowledgements that you know all this, yet you still argue otherwise, it''s really bizarre.

and for future reference, what company do you work for? so i can avoid it like the plague.. hehe

--bart

##### Share on other sites
Well..thanks everybody for your help in my first question
it seems that each problem i solve opens the gate for other problems..but am really enjoying what am doing..i learnt lots of stuff last week...

i spent the last week reading Dave baraff and chris hecker tutorials..
and i also read some articles in Game Programming Gems (my favourite book)About quaternions
and i made the rigid body motion update function work correctly..
i also applied the runga kutta..i already took it in college ( am in computer egineering ) from 2 years

i already show all the forces graphically in my debuggin to know if am right or wrong
also, to make sure evrything is fine..i manually apply forces and see their effect on the body

my simulation function now is much clearer

this is a screenshot..am trying to make a simulator for any robot
(my engine is used to construct any robots and save them in file.. this is the 2nd part of my project)

http://www.geocities.com/fluteyeg/robot.jpg

and it is working fine
before i say the new problem..here is my new function
(it is working in a reasonable manner)

// Update(deltaTime)
// this function will update the physical state of the robot
// it will update everything according t the applied forces
void cRigidState::Update(float DeltaTime)
{
// Step 1.
// find the CenterOfMass of the body tensor
// i can skip this step if there is robot is completly rigid
if(m_AllBoxes.size())
{
ComputeCG();
ComputeInverseBodyTensor();
}

// Step 2
// calculate the total force and torque from all the applied forces
ComputeTotalForce();
ComputeTotalTorque();

// Step 3
// integrate the positions (linear and angular )
// updating the translation position using the velocity and the DeltaTime
m_Position=RungeKutta(m_Position,m_LinVelocity,m_NetForce/m_TotalMass,DeltaTime);

// update the orientation using quaternion interpolation
m_Quat=Qlerp(m_Quat,0.5f*m_AngVelocity*m_Quat,DeltaTime);
// normalize the quaternion
m_Quat.Normalize();

// transform it into a matrix
m_Orientation=m_Quat.ToMatrix();

// Step 4.
// integrate the velocities
// Update the Linear Velocity useing the NetForce
// and the total mass at the center
// find the new velocity from the net force applied v1=v0+1/M*Fnet*dt
m_LinVelocity =m_LinVelocity+m_NetForce/m_TotalMass*DeltaTime;

// Integrate the angular momentum ...
m_AngMomentum =m_AngMomentum+m_NetTorque*DeltaTime;

// find the new Linear and angular Momentums
m_LinMomentum = m_TotalMass*m_LinVelocity;

// update the angular velocity
m_AngVelocity = m_WorldTensor*m_AngMomentum;

// step 5
// update the auxiliary quantities
// using the Inertia tensor matrix and its inverse
// and the total torque
m_WorldTensor=m_Orientation*m_InverseBodyTensor*matrix4::inverse(m_Orientation);

// clear the forces again for next step
m_AllForces.clear();
}

now i am trying to solve the ground collision problem
my robot is composed of a set of boxes..which am keeping track of all their boudning vertices

i started to make functions to calculate the impulse force when the any point hits the ground
the computation is correct..i already made a bisection path in time into the exact collision instant

the code for the bisection and impulse work just fine in case the colliding point is EXACTLY below the center of mass of the body

the real problem now is that the robot ( my rigid body is a robot) when it hits the ground, it could hit it in several points..
am trying to know how to aplly the impulseive force.. should i make a biosection search witht he ground with all the body vertices(bounding vertices) ..or what should i do..

i am looking for any similar code that could help me see this in action..thanks

[edited by - flutey on April 28, 2002 1:55:35 AM]

##### Share on other sites
Hello,

I have just noticed the following line in your code :

m_AngVelocity = m_WorldTensor*m_AngMomentum;

I have just checked the paper from David Baraff ( A intro. to physically based modeling : rigid body simulations 1 )

I believe it shall be inverse of the world tensor, like :

m_AngVelocity = m_WorldTensorInverse*m_AngMomentum;

May I be wrong ?

Atreides