#### Archived

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

# Rigid Body Motion update Problems

This topic is 5315 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

1. 1
Rutin
61
2. 2
3. 3
4. 4
5. 5

• 12
• 10
• 28
• 20
• 9
• ### Forum Statistics

• Total Topics
633412
• Total Posts
3011751
• ### Who's Online (See full list)

There are no registered users currently online

×