http://groups.google.com/groups?hl=en&lr=&ie=UTF8&threadm=20010105012025.13480.00001291%40ngcn1.aol.com&rnum=1&prev=/groups%3Fq%3Dinertia%2Btensor%2Bgroup:rec.autos.simulators%26hl%3Den%26lr%3D%26ie%3DUTF8%26selm%3D20010105012025.13480.00001291%2540ngcn1.aol.com%26rnum%3D1
Message 1 in thread
From: J. Todd Wasson (jtw62074@aol.com)
Subject: Car physics  Inertia tensors
Newsgroups: rec.autos.simulators
Date: 20010104 22:21:51 PST
Ok, can anybody help me out on this one? My project is not using inertia
tensors because I don't understand how to use them. Right now, I have three
different polar moment of inertia values that are local to the car (yaw, pitch,
and roll axes). These alter rotational velocity and acceleration directly
around the three world axes. This seems to work well enough as long as the car
isn't flipping through the air or driving on a 80 degree embankment/hill. When
it does fly into the air, it doesn't flip correctly of course. Their isn't any
gyroscopic precession to the tumble. This must be effecting the rest of the
model at high bank angles too.
I downloaded and printed out a ton of information on rigid body dynamics and
inertia tensors for angular momentum calculations, and understand some of the
concepts. For instance, angular velocity is usually not manipulated directly
or used at all in rigid body dynamic simulation, as by applying forces to the
body through the inertia tensor, angular momentum gets changed directly and
appropriately instead, something that is supposedly very difficult and
expensive to do correctly to angular velocities.
So, suppose I express my initial inertia tensor using the three seperate
polar moments of inertia of the sprung weight of the car (assuming it's the
same as a 3D box) in matrix form like this:
Inertia1 0 0
0 Inertia2 0
0 0 Inertia3
I downloaded a paper written by David Baraff, from the Robotics Institute
at
Carnegie Mellon University, available at Chris Hecker's web page:
http://www.d6.com/users/checker/dynamics.htm
This explained to me everything I currently know on this subject up until
now
(which isn't much, obviously!). In it, he shows how a force vector and a
position vector for the location of the force on the body can be used to find
the total torque vector on the body (for 3 dimensions). However, I'm confused
as to what to do with this torque and the inertia tensor. I'm using a 3x3
matrix to define the rotational orientation of the sprung mass of the car.
What do I do with the torque vector? It says that the inertia tensor itself
changes with orientation. Should I be multiplying my orientation matrix by the
inertia tensor, then multiplying the result by the angular momentum matrix and
the time step in order to change the orientation matrix again? Any ideas?? I
know GPL must do this for the body, as well as all four wheels independently,
because there's gyroscopic precession in the wheels, and this is the only way
I
can imagine it might be done.
Help!!
Thanks,
Todd Wasson
Hello,
First of all, for those not interested, I appologize for the longish
post.
You are just one small step away from doing it correctly.
There is much talk of the 6DOF models. These 6 degrees of freedom are
the position of the center of gravity (3 components) and then three
variables that describe the rotational orientation of the object
relative to its c.o.g. . As you say, and it's the easiest way to do it,
instead of using, say, three angles (say, pitch, yaw, roll) to describe
orientation, you are using a 3x3 matrix that is very well known to
anyone ever doing 3D graphics, however, usually in 3D graphics the
position vector is also included in the last row (or column) to form a
larger 4x4 matrix.
The 3x3 orientation matrix, let's name it O, is an orthogonal matrix,
meaning that if you exchange rows and columns and multiply it by the
original matrix )transpose it, O^T ), you should get the identity
matrix.
Now, the inertia tensor (let's name it J0 in the local coordinates of
the body) can also be represented as a 3x3 matrix. However, this tensor
is a constant only in the system that rotates with the vehicle. The
tensor that you created with components in pitch, yaw, and roll axes is
an example of such a tensor, although generally you would also get
components away from the diagonal.
If you've done 3D graphics, you know that the position of an arbitrary
vector v0 that is given in the local coordinates of the body needs to be
multiplied by the orientation matrix O, v = O v0 , to get the vector v
as the vector v0 oriented in the world coordinates. The tensor J0 in
world coordinates, J, however transforms a bit differently (as a
matrix). Without going into too much detail, to obtain the world
representation of the tensor J, you need to perform the following
operation:
J = O J0 O^T, (1)
where O^T is the transposed of O as given before.
I guess you are familiar with the concept of rotational momentum, gamma,
which is a vector. The relation
d(gamma)/dt = torque, (2)
is true, where torque is the torque vector. Now, gamma is given as
gamma = J omega, (3)
where omega is the rotational velocity vector, which points along the
axis of the rotation and whose magnitue gives the speed of rotation.
Actually,
(d O)/dt y0 = omega (x) (O y0) (4)
holds true, where (d O)/dt is the time derivative of the orientation
matrix, (x) denotes the vectorial product, and v is an arbitrary vector.
Similarly,
(d O^T)/dt y =  O^T (omega (x) y) . (5)
Now one needs to take into account that both the tensor of inertia in
the world (but not local) coordinates and omega change with time.
Inserting (3) into (2), and taking into account both (4), (5) and (1),
one gets
omega (x) O J0 O^T omega  O J0 O^T (omega (x) omega)
+ O J0 O^T (d omega)/dt = torque (6)
where the second term clearly vanishes, and from this one obtains
(d omega)/dt = J^(1) (torque  omega (x) (J omega) ). (7)
While the derivation was done in an inertial frame of reference (world
coordinates for example), the equation (7) can be rewriten in any frame
of reference, as long as all the quantities are transformed correctly.
In the local coordinate system of the body, the J is just J0 (and J^(1)
is the inverse of the J0 (J0^(1)), while in the world system
J=O J0 O^T, J^(1)= O (J0^(1)) O^T.
If you need help on how to update the matrix O from a given vector
omega, let me know, but basically you need to construct a matrix that
creates a small rotation around the vector omega and multiply the matrix
O by it from the left.
Gregor
P.S. There might be some small errors above as I've last visited this
derivation a while ago. The result (7) that you need, however, is surely
correct.
Message 3 in thread
From: Petri Blomqvist (pmb@iobox.com)
Subject: Re: Car physics  Inertia tensors
View this article only
Newsgroups: rec.autos.simulators
Date: 20010105 03:03:32 PST
 Original Message 
From: "J. Todd Wasson" <jtw62074@aol.com>
Newsgroups: rec.autos.simulators
Sent: Friday, January 05, 2001 8:20 AM
Subject: Car physics  Inertia tensors
Hi Todd,
I've been working on a little driving simulation of my own since last July,
and have managed to build fully working rigid body dynamics for it, so I
might be able to help.
> This explained to me everything I currently know on this subject up
until
now
> (which isn't much, obviously!). In it, he shows how a force vector and
a
> position vector for the location of the force on the body can be used to
find
> the total torque vector on the body (for 3 dimensions). However, I'm confused
> as to what to do with this torque and the inertia tensor. I'm using a 3x3
> matrix to define the rotational orientation of the sprung mass of the car.
> What do I do with the torque vector? It says that the inertia tensor itself
> changes with orientation. Should I be multiplying my orientation matrix
by
the
> inertia tensor, then multiplying the result by the angular momentum matrix
and
> the time step in order to change the orientation matrix again? Any
ideas??
First of all, you need to work with the _inverse_ of the inertia tensor.
It's no big deal, simply calculate the inverse once in the beginning and
store it. If you're just using the elements on the diagonal (ie. you assume
no asymmetry in the mass distribution) the inverse of the matrix can be
calculated by just inverting the elements.
Assuming you calculate the torque vector and angular velocity and momentum
vectors in world coordinates, as I have done, what you do is you take the
torque vector (tau) and multiply by the time step (dt), then add this to the
angular momentum vector (L) of the object:
L = L + tau * dt
To calculate the angular velocity vector, you first multiply the current
rotation matrix (R) by the inverse of the inertia tensor (Ibodyinv, which
you calculate and store once in the beginning of the program), then multiply
the result of that by the transpose of the current rotation matrix (this
operation transforms the inverse of the inertia tensor from body coordinates
to world coordinates):
Iinv = R * Ibodyinv * transpose(R)
Then, to get the new angular velocity vector (omega), you multiply the
angular momentum vector by Iinv. Et voila, there you have it:
omega = L * Iinv
Then you just integrate, calculate the new rotation matrix, and you'll have
your cars rotating realistically, with precession and all that.
I'm using quaternions for rotation which makes things slightly different,
but the basic principle is the same. For numerical integration, I suggest
using a fourthorder RungeKutta method for accuracy.
I hope this helps (and that I didn't make any mistakes... I'm sure someone
will step in and correct me if I did. :)
Petri Blomqvist
Message 4 in thread
From: Gregor Veble (gregor.veble@unimb.si)
Subject: Re: Car physics  Inertia tensors
View this article only
Newsgroups: rec.autos.simulators
Date: 20010105 03:35:28 PST
Petri Blomqvist wrote:
<snip>
>
> I'm using quaternions for rotation which makes things slightly different,
> but the basic principle is the same. For numerical integration, I suggest
> using a fourthorder RungeKutta method for accuracy.
>
> I hope this helps (and that I didn't make any mistakes... I'm sure someone
> will step in and correct me if I did. :)
>
> Petri Blomqvist
I must say I would heartily recommend this approach over what I
suggested. Working with both the angular momentum and angular velocity
is easier to implement than just the angular velocity approach (which is
what my derivation focused on). Blame it on my narrowminded education
:).
Gregor
>I must say I would heartily recommend this approach over what I
>suggested. Working with both the angular momentum and angular velocity
>is easier to implement than just the angular velocity approach (which is
>what my derivation focused on). Blame it on my narrowminded education
>:).
>
>Gregor
Geeze, Gregor! The paper I looked at just skipped through that derivation
because it was so complicated! You know your stuff!
Thanks a ton for your help, I'll probably be needing more to get this working
right. :)
Todd Wasson

Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
>First of all, you need to work with the _inverse_ of the inertia tensor.
>It's no big deal, simply calculate the inverse once in the beginning and
>store it. If you're just using the elements on the diagonal (ie. you assume
>no asymmetry in the mass distribution) the inverse of the matrix can be
>calculated by just inverting the elements.
>
>Assuming you calculate the torque vector and angular velocity and momentum
>vectors in world coordinates, as I have done, what you do is you take the
>torque vector (tau) and multiply by the time step (dt), then add this to
the
>angular momentum vector (L) of the object:
>
> L = L + tau * dt
>
>To calculate the angular velocity vector, you first multiply the current
>rotation matrix (R) by the inverse of the inertia tensor (Ibodyinv, which
>you calculate and store once in the beginning of the program), then multiply
>the result of that by the transpose of the current rotation matrix (this
>operation transforms the inverse of the inertia tensor from body coordinates
>to world coordinates):
>
> Iinv = R * Ibodyinv * transpose(R)
>
>Then, to get the new angular velocity vector (omega), you multiply the
>angular momentum vector by Iinv. Et voila, there you have it:
>
> omega = L * Iinv
>
>Then you just integrate, calculate the new rotation matrix, and you'll have
>your cars rotating realistically, with precession and all that.
Ok, let me see if I follow you here. I was going to have a symmetrical
inertia tensor:
inertia1 0 0
0 inertia2 0
0 0 inertia3
But what I really want is the inverse of this. Is this it? Silly question,
I know.
Ibodyinv:
inertia3 0 0
0 inertia2 0
0 0 inertia1
I'm a real amateur with matrices and vectors at this point, as I've just
started using these one or two months ago. My 3D graphics are a wireframe
Win32Api thing that hardly uses vectors or matrices at all, so I'm still
learning this stuff.
Read the rest of this message... (35 more lines)
Message 7 in thread
From: Petri Blomqvist (pmb@iobox.com)
Subject: Re: Car physics  Inertia tensors
View this article only
Newsgroups: rec.autos.simulators
Date: 20010106 09:44:00 PST
"J. Todd Wasson" <jtw62074@aol.com> wrote in message
news:20010105182710.11387.00000042@ngfw1.aol.com...
> Ok, let me see if I follow you here. I was going to have a symmetrical
> inertia tensor:
>
> inertia1 0 0
> 0 inertia2 0
> 0 0 inertia3
>
> But what I really want is the inverse of this. Is this it? Silly question,
> I know.
>
> Ibodyinv:
> inertia3 0 0
> 0 inertia2 0
> 0 0 inertia1
Not quite. :) This is what I meant:
1/inertia1 0 0
0 1/inertia2 0
0 0 1/inertia3
In general, inverting a matrix is more complex, but if every element off the
diagonal is zero you can take this handy shortcut.
> I'm a real amateur with matrices and vectors at this point, as I've just
> started using these one or two months ago. My 3D graphics are a wireframe
> Win32Api thing that hardly uses vectors or matrices at all, so I'm still
> learning this stuff.
I'm using OpenGL for my own simulation. I must say, if I had to pick one
thing about OpenGL that I like the most, it's the ease with which it can be
learnt and used. I've gone in a couple of months from spinning, unlit
singlecolored cubes to multitextured, lit, environmentmapped 3d models. I
don't think I could've done that with D3D. Other people's mileage may vary,
of course. :)
> The angular momentum vector is a 3x3 matrix, correct? Or is it a three
> dimensional vector?
It's a 3d vector.
> The angular velocity vector is also a 3x3 matrix, correct?
Read the rest of this message... (74 more lines)
Message 8 in thread
From: J. Todd Wasson (jtw62074@aol.com)
Subject: Re: Car physics  Inertia tensors
View this article only
Newsgroups: rec.autos.simulators
Date: 20010106 15:06:40 PST
Great, thanks again Petri. I'll see what I can do now. Yes, basic
aerodynamics will be pretty simple to add in when things are done this way.
Also, I imagine adding impulses from collisions would be simplified quite a
bit. (I haven't gone there yet anyway.)
>By the way, you mentioned something about precession of the wheels in GPL?
I
>haven't seen that game (shame on me :), I assume you mean the wheels precess
>if they go flying through the air after a crash? Sounds cool.
>
Yes, basically. If you get some air off a steep hill, you're supposedly able
to rotate the car by steering the front wheels once airborne. GPL seems to be
the most complete model out there, but I haven't tried N4, Nascar Heat, or
Viper Racing, so maybe it's just the hype. I don't imagine many folks would
go
through the trouble of modelling each wheel with an inertia tensor, but GPL
seems to have done this. I know I don't, it's complicated enough as it is
right now! Might as well do the flywheel and engine this way too. That way,
high engine rpm's would cause the chassis to have a little more resistance to
turning. Probably not enough to notice, of course. Don't count on me doing
this! lol Real frame rate killer for an unnoticable effect.
Thanks for the help again, Petri. I'll see what I can do with this and come
back later if I get stuck.
Todd Wasson

Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
It works! Thanks for everybody's help here. It seems to work properly.
Download a little demo here at
http://performancesimulations.com/files/vector3b.exe
Input an initial torque in world space about the x,y, and z axes. This
torque only lasts for one frame, then the object spins on it's own after that.
It looks like it is working correctly to me. What do you guys/gals think? It
may not work on either Windows 2000 or ME, I forget which one, but it's fine
on
Win95/98. Thanks for any input, and thanks again for the help.
Todd Wasson

Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
On 08 Jan 2001 07:33:03 GMT, jtw62074@aol.com (J. Todd Wasson) wrote:
>
> It works! Thanks for everybody's help here. It seems to work properly.
>Download a little demo here at
>http://performancesimulations.com/files/vector3b.exe
Damn, indeed, it doesn't run in my Win2K. Just gives 6 little dots
after inputting XYZ. I'll try it under Win95 later.
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Car simulation: http://www.marketgraph.nl/gallery/racer/
Messages 1120 from thread
Prev 10 Next 10
Jump to [ Start of thread  End of thread ]
Message 11 in thread
From: J. Todd Wasson (jtw62074@aol.com)
Subject: Re: Car physics  Inertia tensors
View this article only
Newsgroups: rec.autos.simulators
Date: 20010108 16:00:19 PST
>Damn, indeed, it doesn't run in my Win2K. Just gives 6 little dots
>after inputting XYZ. I'll try it under Win95 later.
Sorry, it's because I don't handle drawing properly (through WM_Paint
messages), rather, it uses WM_Timer. That doesn't seem to work in Win2K. I
think it does in Win ME, though. Anyway, let me know if it looks right. Do
objects really do wierd things like that when they're spinning in 0g? Bizarre!
Not sure if it's right.
Todd Wasson

Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
On 08 Jan 2001 23:54:09 GMT, jtw62074@aol.com (J. Todd Wasson) wrote:
>>Damn, indeed, it doesn't run in my Win2K. Just gives 6 little dots
>>after inputting XYZ. I'll try it under Win95 later.
>
> Sorry, it's because I don't handle drawing properly (through WM_Paint
>messages), rather, it uses WM_Timer. That doesn't seem to work in Win2K.
Weird, WM_TIMER works in Win2K though. Perhaps you're not handling
BeginPaint()/EndPaint() things right. Well, I don't know much Windows
programming actually, so I can't really tell.
Perhaps you should call Invalidate() on the window instead of painting
from within WM_TIMER. (and process the WM_PAINT message, this is not
really a message at all I believe, more a state which is sent when no
messages are available (idle processing)).
Anyway, this is not the place for these discussions. :)
I still have to check in Win95, unfortunately, upto Sunday I seem to
be stuck with work (outside the office).
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Car simulation: http://www.marketgraph.nl/gallery/racer/
In article <3a5e0ff2.141172435@news.xs4all.nl>, ruud@marketgraph.nl
says...
> On 08 Jan 2001 23:54:09 GMT, jtw62074@aol.com (J. Todd Wasson) wrote:
>
> >>Damn, indeed, it doesn't run in my Win2K. Just gives 6 little dots
> >>after inputting XYZ. I'll try it under Win95 later.
> >
> > Sorry, it's because I don't handle drawing properly (through WM_Paint
> >messages), rather, it uses WM_Timer. That doesn't seem to work in Win2K.
>
> Weird, WM_TIMER works in Win2K though. Perhaps you're not handling
> BeginPaint()/EndPaint() things right. Well, I don't know much Windows
> programming actually, so I can't really tell.
> Perhaps you should call Invalidate() on the window instead of painting
> from within WM_TIMER. (and process the WM_PAINT message, this is not
> really a message at all I believe, more a state which is sent when no
> messages are available (idle processing)).
>
> Anyway, this is not the place for these discussions. :)
>
> I still have to check in Win95, unfortunately, upto Sunday I seem to
> be stuck with work (outside the office).
The WM_TIMER message is the lowest priority message. It gets process
after EVERYTHING else. If you want something to work on a timer, you
should set up a timer thread. I have a threaded timer class if you need
it.

=========================================================
Redneck TechnoBiker (Zerex12)
http://www.paddedwall.org/john
Barbarian Diecast Collector (420+ cars and counting)
http://www.paddedwall.org/diecast
DeMONS Scheduler for N3 and NL
http://www.paddedwall.org/demons
IGPS/3 Home Page
http://www.paddedwall.org/igps3
If you want to send me email, go to the first URL shown
above & click "Send Me Mail" in the contents frame.
=========================================================
Message 14 in thread
From: J. Todd Wasson (jtw62074@aol.com)
Subject: Re: Car physics  Inertia tensors
View this article only
Newsgroups: rec.autos.simulators
Date: 20010110 14:28:06 PST
>The WM_TIMER message is the lowest priority message. It gets process
>after EVERYTHING else. If you want something to work on a timer, you
>should set up a timer thread. I have a threaded timer class if you need
>it.
>
Thanks for the offer, that's kind of you. Unfortunately, I'm not using an
OOP language, so a class won't do me much good. I just need to set things up
through WM_PAINT, like it's supposed to be done :)
Todd Wasson

Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
>Weird, WM_TIMER works in Win2K though. Perhaps you're not handling
>BeginPaint()/EndPaint() things right. Well, I don't know much Windows
>programming actually, so I can't really tell.
>Perhaps you should call Invalidate() on the window instead of painting
>from within WM_TIMER. (and process the WM_PAINT message, this is not
>really a message at all I believe, more a state which is sent when no
>messages are available (idle processing)).
>
Right, I'm not even using WM_PAINT, beginpaint, or endpaint :) It just goes
into a sub right after the WM_TIMER message and draws on the bitmap, then
bitblts it. I'm pretty sure this is what causes the Win2K problem.
InvalidateRect would fire a WM_PAINT message, then I should really call the
graphics section from there. Oh well, it works on my system anyway ;)
Todd Wasson

Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
On 10 Jan 2001 22:20:47 GMT, jtw62074@aol.com (J. Todd Wasson) wrote:
> Right, I'm not even using WM_PAINT, beginpaint, or endpaint :) It just
goes
>into a sub right after the WM_TIMER message and draws on the bitmap, then
>bitblts it. I'm pretty sure this is what causes the Win2K problem.
>InvalidateRect would fire a WM_PAINT message, then I should really call
the
>graphics section from there. Oh well, it works on my system anyway ;)
That's the main thing. Windows has a lot of ways to get messages
across (the internals are complex but sensible).
You wouldn't be using WM_PAINT anyway if you were to make an actual
sim for people out there (although I'm still using normal key events
in Racer, but at 150fps for nonvsync'ed track parts I'm not
complaining, lol).
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Car simulation: http://www.marketgraph.nl/gallery/racer/
The best is to use winmm.lib and the multimedia timers :
timeBeginPeriod
timeSetEvent
timeKillEvent
timeEndPeriod
Use MSDN help for more info.
i'm calling dynmamic under time interruption to guarantee a real time
processing ... even if display is slow.
Be aware of reentrence calling !
Seb
Game Developer
GPLRank 36.24
http://magicfr.multimania.com
"J. Todd Wasson" <jtw62074@aol.com> wrote in message
news:20010108185409.08171.00000485@ngft1.aol.com...
> Do objects really do wierd things like that when they're spinning in 0g?
> Bizarre!
> Not sure if it's right.
You still seem to have some work ahead of you. That rotation looks a lot
like what I got from my first attempts. In fact, I only got mine working
when I switched to using quaternions to describe the orientations of my
objects... but I digress. :)
I would suggest that you use a top (large moment of inertia on one axis,
a much smaller one on the other two) to test the rotation. If you can
make the top spin and precess stably by giving it a large initial angular
momentum on the axis with the large moment of inertia, and small
momentums on the other two, your code is probably working.
Petri Blomqvist
>You still seem to have some work ahead of you. That rotation looks a lot
>like what I got from my first attempts. In fact, I only got mine working
>when I switched to using quaternions to describe the orientations of my
>objects... but I digress. :)
>
>I would suggest that you use a top (large moment of inertia on one axis,
>a much smaller one on the other two) to test the rotation. If you can
>make the top spin and precess stably by giving it a large initial angular
>momentum on the axis with the large moment of inertia, and small
>momentums on the other two, your code is probably working.
>
Shucks, thought I had it until I let it run for awhile. Sometimes, it almost
stops, then suddenly whips around 180 degrees or so. I'll try the spinning top
idea and see what it does. Thanks a lot for your help Petri!
Todd Wasson

Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
Hi Todd
Quick and dirty inverter of a 3x3 matric for you, plenty of room for
improvement, but as you only need to call once (or whenever you mass
distribution changes) then it will do :O)
Chris
BOOL InverseMassMatrix(MATRIX3X3 *source, MATRIX3X3 *dest)
{
long col,row;
float fDet;
float fInvdet;
dest>matrix[0][0] = source>matrix[1][1] * source>matrix[2][2]

source>matrix[1][2] * source>matrix[2][1];
dest>matrix[0][1] = source>matrix[0][2] * source>matrix[2][1] 
source>matrix[0][1] * source>matrix[2][2];
dest>matrix[0][2] = source>matrix[0][1] * source>matrix[1][2] 
source>matrix[0][2] * source>matrix[1][1];
dest>matrix[1][0] = source>matrix[1][2] * source>matrix[2][0] 
source>matrix[1][0] * source>matrix[2][2];
dest>matrix[1][1] = source>matrix[0][0] * source>matrix[2][2] 
source>matrix[0][2] * source>matrix[2][0];
dest>matrix[1][2] = source>matrix[0][2] * source>matrix[1][0] 
source>matrix[0][0] * source>matrix[1][2];
dest>matrix[2][0] = source>matrix[1][0] * source>matrix[2][1] 
source>matrix[1][1] * source>matrix[2][0];
dest>matrix[2][1] = source>matrix[0][1] * source>matrix[2][0] 
source>matrix[0][0] * source>matrix[2][1];
dest>matrix[2][2] = source>matrix[0][0] * source>matrix[1][1] 
source>matrix[0][1] * source>matrix[1][0];
fDet = source>matrix[0][0] * dest>matrix[0][0] + source>matrix[0][1]
* dest>matrix[1][0] + source>matrix[0][2] * dest>matrix[2][0];
if ( fabs(fDet) <= 1e06 )
return FALSE;
fInvdet = 1.0f / fDet;
for ( row = 0; row < 3; row++)
{
for ( col = 0; col < 3; col++)
dest>matrix[row][col] *= fInvdet;
}
return TRUE;
}
J. Todd Wasson wrote in message
<20010105182710.11387.00000042@ngfw1.aol.com>...
>>First of all, you need to work with the _inverse_ of the inertia tensor.
>>It's no big deal, simply calculate the inverse once in the beginning
and
>>store it. If you're just using the elements on the diagonal (ie. you
assume
>>no asymmetry in the mass distribution) the inverse of the matrix can
be
>>calculated by just inverting the elements.
>>
>>Assuming you calculate the torque vector and angular velocity and momentum
>>vectors in world coordinates, as I have done, what you do is you take
the
>>torque vector (tau) and multiply by the time step (dt), then add this
to the
>>angular momentum vector (L) of the object:
>>
>> L = L + tau * dt
>>
>>To calculate the angular velocity vector, you first multiply the current
>>rotation matrix (R) by the inverse of the inertia tensor (Ibodyinv,
which
>>you calculate and store once in the beginning of the program), then
multiply
>>the result of that by the transpose of the current rotation matrix (this
>>operation transforms the inverse of the inertia tensor from body coordinates
>>to world coordinates):
>>
>> Iinv = R * Ibodyinv * transpose(R)
>>
>>Then, to get the new angular velocity vector (omega), you multiply the
>>angular momentum vector by Iinv. Et voila, there you have it:
>>
>> omega = L * Iinv
>>
>>Then you just integrate, calculate the new rotation matrix, and you'll
have
>>your cars rotating realistically, with precession and all that.
>
> Ok, let me see if I follow you here. I was going to have a symmetrical
>inertia tensor:
>
>inertia1 0 0
> 0 inertia2 0
> 0 0 inertia3
>
> But what I really want is the inverse of this. Is this it? Silly question,
>I know.
>
>Ibodyinv:
>inertia3 0 0
> 0 inertia2 0
> 0 0 inertia1
>
> I'm a real amateur with matrices and vectors at this point, as I've just
>started using these one or two months ago. My 3D graphics are a wireframe
>Win32Api thing that hardly uses vectors or matrices at all, so I'm still
>learning this stuff.
>
> The angular momentum vector is a 3x3 matrix, correct? Or is it a three
>dimensional vector?
>
> The angular velocity vector is also a 3x3 matrix, correct?
>
> Ok, to calculate the angular velocity vector, I multiply the current rotation
>matrix by the inverse of the inertia tensor, which is calculated one time
at
>the beginning of the simulation. The, I multiply the result of that by the
>transpose of the current rotation matrix. What is the transpose of the
>rotation matrix?
>Rotation matrix is:
>xx yx zx
>xy yy zy
>xz yz zz
>
> Ok, after the result of this is found, I get the new angular velocity vector
>by multiplying the angular momentum vector by Ibodyinv (the inverse of the
>inertia tensor).
>
> Now, the angular velocity vector is essentially added to the old rotation
>matrix to get the new rotation matrix?
>
> Geeze, I guess I have a lot of homework to do here! I'll go through this
>paper again with your post as a guide. Hopefully I'll get this working.
>Studying vectors and matrices more ought to help.
>
> Thank you very much for your help Petri.
>
>Todd Wasson
>
>Performance Simulations
>Drag Racing and Top Speed Prediction
>Software
>http://PerformanceSimulations.Com
From: neil canning (deathboy@ctaz.com)
Subject: Re: Car physics  Inertia tensors
View: Complete Thread (33 articles)
Original Format
Newsgroups: rec.autos.simulators
Date: 20010106 18:50:03 PST
Geeze Chris......what a showoff<G>
whens that demo ever gonna be released.......sorry just had to ask
neil canning
"Chris West" <chris.west1@ntlworld.com> wrote in message
news:7pQ56.46023$Yy.1092282@news2win.server.ntlworld.com...
> Hi Todd
>
> Quick and dirty inverter of a 3x3 matric for you, plenty of room for
> improvement, but as you only need to call once (or whenever you mass
> distribution changes) then it will do :O)
>
> Chris
>
> BOOL InverseMassMatrix(MATRIX3X3 *source, MATRIX3X3 *dest)
> {
> long col,row;
> float fDet;
> float fInvdet;
>
> dest>matrix[0][0] = source>matrix[1][1] * source>matrix[2][2]

> source>matrix[1][2] * source>matrix[2][1];
> dest>matrix[0][1] = source>matrix[0][2] * source>matrix[2][1]

> source>matrix[0][1] * source>matrix[2][2];
> dest>matrix[0][2] = source>matrix[0][1] * source>matrix[1][2]

> source>matrix[0][2] * source>matrix[1][1];
> dest>matrix[1][0] = source>matrix[1][2] * source>matrix[2][0]

> source>matrix[1][0] * source>matrix[2][2];
> dest>matrix[1][1] = source>matrix[0][0] * source>matrix[2][2]

> source>matrix[0][2] * source>matrix[2][0];
> dest>matrix[1][2] = source>matrix[0][2] * source>matrix[1][0]

> source>matrix[0][0] * source>matrix[1][2];
> dest>matrix[2][0] = source>matrix[1][0] * source>matrix[2][1]

> source>matrix[1][1] * source>matrix[2][0];
> dest>matrix[2][1] = source>matrix[0][1] * source>matrix[2][0]

> source>matrix[0][0] * source>matrix[2][1];
> dest>matrix[2][2] = source>matrix[0][0] * source>matrix[1][1]

> source>matrix[0][1] * source>matrix[1][0];
>
> fDet = source>matrix[0][0] * dest>matrix[0][0] + source>matrix[0][1]
> * dest>matrix[1][0] + source>matrix[0][2] * dest>matrix[2][0];
> if ( fabs(fDet) <= 1e06 )
> return FALSE;
>
> fInvdet = 1.0f / fDet;
> for ( row = 0; row < 3; row++)
> {
> for ( col = 0; col < 3; col++)
> dest>matrix[row][col] *= fInvdet;
> }
>
> return TRUE;
> }
>
> J. Todd Wasson wrote in message
> <20010105182710.11387.00000042@ngfw1.aol.com>...
> >>First of all, you need to work with the _inverse_ of the inertia
tensor.
> >>It's no big deal, simply calculate the inverse once in the beginning
and
> >>store it. If you're just using the elements on the diagonal (ie.
you assume
> >>no asymmetry in the mass distribution) the inverse of the matrix
can be
> >>calculated by just inverting the elements.
> >>
> >>Assuming you calculate the torque vector and angular velocity and
momentum
> >>vectors in world coordinates, as I have done, what you do is you
take the
> >>torque vector (tau) and multiply by the time step (dt), then add
this to the
> >>angular momentum vector (L) of the object:
> >>
> >> L = L + tau * dt
> >>
> >>To calculate the angular velocity vector, you first multiply the
current
> >>rotation matrix (R) by the inverse of the inertia tensor (Ibodyinv,
which
> >>you calculate and store once in the beginning of the program),
then multiply
> >>the result of that by the transpose of the current rotation matrix
(this
> >>operation transforms the inverse of the inertia tensor from body
coordinates
> >>to world coordinates):
> >>
> >> Iinv = R * Ibodyinv * transpose(R)
> >>
> >>Then, to get the new angular velocity vector (omega), you multiply
the
> >>angular momentum vector by Iinv. Et voila, there you have it:
> >>
> >> omega = L * Iinv
> >>
> >>Then you just integrate, calculate the new rotation matrix, and
you'll have
> >>your cars rotating realistically, with precession and all that.
> >
> > Ok, let me see if I follow you here. I was going to have a symmetrical
> >inertia tensor:
> >
> >inertia1 0 0
> > 0 inertia2 0
> > 0 0 inertia3
> >
> > But what I really want is the inverse of this. Is this it? Silly question,
> >I know.
> >
> >Ibodyinv:
> >inertia3 0 0
> > 0 inertia2 0
> > 0 0 inertia1
> >
> > I'm a real amateur with matrices and vectors at this point, as I've
just
> >started using these one or two months ago. My 3D graphics are a wireframe
> >Win32Api thing that hardly uses vectors or matrices at all, so I'm
still
> >learning this stuff.
> >
> > The angular momentum vector is a 3x3 matrix, correct? Or is it a three
> >dimensional vector?
> >
> > The angular velocity vector is also a 3x3 matrix, correct?
> >
> > Ok, to calculate the angular velocity vector, I multiply the current
rotation
> >matrix by the inverse of the inertia tensor, which is calculated one
time at
> >the beginning of the simulation. The, I multiply the result of that
by the
> >transpose of the current rotation matrix. What is the transpose of
the
> >rotation matrix?
> >Rotation matrix is:
> >xx yx zx
> >xy yy zy
> >xz yz zz
> >
> > Ok, after the result of this is found, I get the new angular velocity
vector
> >by multiplying the angular momentum vector by Ibodyinv (the inverse
of the
> >inertia tensor).
> >
> > Now, the angular velocity vector is essentially added to the old rotation
> >matrix to get the new rotation matrix?
> >
> > Geeze, I guess I have a lot of homework to do here! I'll go through
this
> >paper again with your post as a guide. Hopefully I'll get this working.
> >Studying vectors and matrices more ought to help.
> >
> > Thank you very much for your help Petri.
> >
> >Todd Wasson
> >
> >Performance Simulations
> >Drag Racing and Top Speed Prediction
> >Software
> >http://PerformanceSimulations.Com
>
>
Message 22 in thread
From: Ruud van Gaal (ruud@marketgraph.nl)
Subject: Re: Car physics  Inertia tensors
View this article only
Newsgroups: rec.autos.simulators
Date: 20010107 10:07:20 PST
On Sun, 7 Jan 2001 02:21:51 0000, "Chris West"
<chris.west1@ntlworld.com> wrote:
>Quick and dirty inverter of a 3x3 matric for you, ...
>BOOL InverseMassMatrix(MATRIX3X3 *source, MATRIX3X3 *dest)
>{
Is that a columnmajor or rowmajor matrix? It will really be
bughunting plaza when you're (Todd) mixing up code for row and
columnmajor code by using snippets. (I use columnmajor btw, only in
OpenGL format, so the C m[3][3] code is a bit tricky as it is
m[column][row] effectively, but very handy because I'm dealing with
OpenGL).
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Car simulation: http://www.marketgraph.nl/gallery/racer/
Thats Row Major :O)
Ruud van Gaal wrote in message <3a5aaf98.937478653@news.xs4all.nl>...
>On Sun, 7 Jan 2001 02:21:51 0000, "Chris West"
><chris.west1@ntlworld.com> wrote:
>
>>Quick and dirty inverter of a 3x3 matric for you, ...
>>BOOL InverseMassMatrix(MATRIX3X3 *source, MATRIX3X3 *dest)
>>{
>
>Is that a columnmajor or rowmajor matrix? It will really be
>bughunting plaza when you're (Todd) mixing up code for row and
>columnmajor code by using snippets. (I use columnmajor btw, only in
>OpenGL format, so the C m[3][3] code is a bit tricky as it is
>m[column][row] effectively, but very handy because I'm dealing with
>OpenGL).
>
>
>Ruud van Gaal, GPL Rank +53.25
>Pencil art : http://www.marketgraph.nl/gallery/
>Car simulation: http://www.marketgraph.nl/gallery/racer/
>Is that a columnmajor or rowmajor matrix? It will really be
>bughunting plaza when you're (Todd) mixing up code for row and
>columnmajor code by using snippets. (I use columnmajor btw, only in
>OpenGL format, so the C m[3][3] code is a bit tricky as it is
>m[column][row] effectively, but very handy because I'm dealing with
>OpenGL).
Thanks Ruud. I've got it working already. My compiler has some built in
Matrix functions, so even though this is all greek to me, I can continue with
my project anyway :)
Todd Wasson

Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
Thanks, Chris :0) Too late though, everything works already. I'll keep the
snippet in case I switch to an OOP language anytime soon. That looks like
greek to me!
Thanks again,
Todd Wasson

Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
On 08 Jan 2001 04:56:07 GMT, jtw62074@aol.com (J. Todd Wasson) wrote:
> Thanks, Chris :0) Too late though, everything works already. I'll keep
the
>snippet in case I switch to an OOP language anytime soon. That looks like
>greek to me!
Do try to get it into OOP when you have some (long, lol) spare
moments. Matrices, vectors etc really do very well in an OOP
environment.
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Car simulation: http://www.marketgraph.nl/gallery/racer/
>Do try to get it into OOP when you have some (long, lol) spare
>moments. Matrices, vectors etc really do very well in an OOP
>environment.
Yeah, I'm sure it'll take at least a week or two lol!!! See you in a couple
years! It took me about 6 months to write the program on my website, and that
was my first Windows program (aside from little monkeying around stuff to see
how things work.) The physics that went into that were ported from an old DOS
QBasic program I wrote, so it took MUCH longer to figure out. OOP? That'll
take a while... :)
Todd Wasson

Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com
Ruud van Gaal wrote:
>
> Do try to get it into OOP when you have some (long, lol) spare
> moments. Matrices, vectors etc really do very well in an OOP
> environment.
>
> Ruud van Gaal, GPL Rank +53.25
> Pencil art : http://www.marketgraph.nl/gallery/
> Car simulation: http://www.marketgraph.nl/gallery/racer/
Well, I'd say that for matrices and vectors the operator overloading
possibility is much more important than objects. However, if you have an
elegant way of treating them as objects, I'd love to hear more about it.
Gregor
On Wed, 10 Jan 2001 13:11:12 +0100, Gregor Veble
<gregor.veble@unimb.si> wrote:
>Ruud van Gaal wrote:
>>
>> Do try to get it into OOP when you have some (long, lol) spare
>> moments. Matrices, vectors etc really do very well in an OOP
>> environment.
>>
>> Ruud van Gaal, GPL Rank +53.25
>> Pencil art : http://www.marketgraph.nl/gallery/
>> Car simulation: http://www.marketgraph.nl/gallery/racer/
>
>Well, I'd say that for matrices and vectors the operator overloading
>possibility is much more important than objects. However, if you have an
>elegant way of treating them as objects, I'd love to hear more about it.
It seems there are a billion ways of implementing vectors. Operator
overloading to get cross and dot products I don't like very much,
because everyone seems to use different operators (and using * for
either cross or dot both seem reason in the end for confusion).
First, the fact that vectors etc contain the members and some
functions to operate upon (like matrix.RotateX(float angle)) already
works good enough for me to recommend it.
Second, the first version I hacked together on vectors used a lot of
friend functions with overloaded operators. But it seems you can bring
these seemingly static (outside) functions inside the class, like
DVector3& operator*=(const dfloat &s);
I'm still finding out nice ways that are fast and don't use stack
copies so much, as this seems a waste of CPU.
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Car simulation: http://www.marketgraph.nl/gallery/racer/
Hi Chris,
Do you work or have you ever worked on a RBS?
Mojo wrote:
>
> Hi Chris,
>
> Do you work or have you ever worked on a RBS?
You really don't know whom you are just talking to, do you :) ?
Gregor
emmanuel.chamayou@lankhor.fr (Mojo) writes:
> Hi Chris,
>
> Do you work or have you ever worked on a RBS?
Nice quoting.
On 05 Jan 2001 06:20:25 GMT, jtw62074@aol.com (J. Todd Wasson) wrote:
> Ok, can anybody help me out on this one? My project is not using inertia
>tensors because I don't understand how to use them.
Very late (still have to run your Win95 vector3b.exe), but I've been
concentrating on other things. Check out:
http://www.chaney.karoo.net/
And download the PDF file which explains in fastest gear how to use
quaternions to get your 3x3 rotation matrix without the normalization
hassle.
Also does precession (and gives formulas for it). I'll have to sweep
my Racer library to get this in sometime.
The demo is also very nice; has a nice feel and looks good.
Ruud van Gaal, GPL Rank +53.25
Pencil art : http://www.marketgraph.nl/gallery/
Car simulation: http://www.marketgraph.nl/gallery/racer/
metadata block 

see also:  
Correspondence about this page  
Book Shop  Further reading. Where I can, I have put links to Amazon for books that are relevant to the subject, click on the appropriate country flag to get more details of the book or to buy it from them. 
Game Physics  This book has some useful stuff, its more of a textbook, not a step by step guide (although it does have a disc with a lot of C++ code). About the first third of the book is a physics textbook with theoretical exercises, the middle bit covers physics engine topics, and the last third of the book covers mathematical topics. I think I would use this book as a reference book to lookup the theory behind something I might be working on rather than a book to work through in order. 
Commercial Software Shop Where I can, I have put links to Amazon for commercial software, not directly related to the software project, but related to the subject being discussed, click on the appropriate country flag to get more details of the software or to buy it from them. 

This site may have errors. Don't use for critical systems.
Copyright (c) 19982020 Martin John Baker  All rights reserved  privacy policy.