Physics - sci.physics - How do I write a computer animation of solid body

Message 1 in thread
From: Martin Baker
Subject: How do I write a computer animation of solid body
Newsgroups: sci.physics
Date: 2003-01-12 09:09:05 PST

I am trying to write a program to display the motion of a rotating solid
body. I am trying to use an approximate method, I don't mind a certain
amount of inaccuracy due to the build up of floating point errors, and I am
assuming the angular acceleration is known at each frame, so each frame I do
the following:

1) Multiply the angular acceleration by the time since the last frame.

2) Add above to the last angular velocity to give the new angular
velocity.

3) Add above to the last angular position to give the new angular
position.

Where the angular acceleration, angular velocity and angular position are 3D
vectors giving rotation about x, y and z axis. So this gives a crude double
integration to give the position.

The problem is that I know that Euler angles can't be added like this,
although each individual addition is going to be very small because it does
not move far in each frame, and I know that for very small angles vector
addition is approximately correct. So is it valid to integrate position up
like this or not?

If not, then I guess that I am going to have to convert the angular velocity
to quaternions or matrices before doing the second integration, this is a
problem because these conversions require at least one sine and cosine
calculation, for every frame, for every object. This is a big overhead in
CPU time. Also I'm going to have to replace vector addition with quaternion
multiplication (is there an equivalent of integration that uses
infinitesimally small multiplications instead of additions?)

Rather than do these conversions for every frame is it possible to use
quaternions or matrices for all the physics equations, so instead of having
equations like,

Torque=[I]alpha

Theta = theta0 + w0 t + ½ alpha t^2

Can I use quaternions or matrices to represent Torque, alpha and w in these
equations. If I do so, how does the form of the equations change? Does [I]
change from a 3x3 matrix to a 4x4 or a 9x9 matrix? How do I calculate its
elements?

Is there an equation to represent conservation of angular momentum or
conservation of energy, but using quaternions or matrices instead of 3D
vectors for these quantities?

I am stuck on these questions, so I would appreciate any ideas you can give
me.

If you need more explanation of what I am trying to achieve see my website
at:

https://www.euclideanspace.com/

Martin

---

Message 2 in thread
From: keith stein (ks012a2355@blueyonder.co.uk)
Subject: Re: How do I write a computer animation of solid body
Newsgroups: sci.physics
Date: 2003-01-12 11:57:49 PST

"Martin Baker" <bakerm@btinterner.com> wrote in message
news:avs7d0$o5$1@helle.btinternet.com...
> I am trying to write a program to display the motion of a rotating solid

Excellent Martin ! - personally i think this should be a compulsary
exercise
for ALL PHYSICS STUDENTS.

> body. I am trying to use an approximate method, I don't mind a certain
> amount of inaccuracy due to the build up of floating point errors, and I am
> assuming the angular acceleration is known at each frame, so each frame I do
> the following:
>
> 1) Multiply the angular acceleration by the time since the last frame.

dw/dt * Dt = dw = CHANGE IN ANGULAR VELOCITY

>
> 2) Add above to the last angular velocity to give the new angular
> velocity.

w2 =w1 + dw
Right!

>
> 3) Add above to the last angular position to give the new angular
> position.
WRONG !
After 2) You have found w1 and w2. You first wand w(average)
w(average) = (w1 + w2)/2

Then you find the new angle position from:
ANGLE2 = ANGLE1 + w(average)*Dt
>
> Where the angular acceleration, angular velocity and angular position are 3D
> vectors giving rotation about x, y and z axis. So this gives a crude double
> integration to give the position.

Not quite sure what your saying here, if you have a program which enables
you to draw your 3D object at any angle you should be able to take it from
here Martin.

>
>
>
> The problem is that I know that Euler angles can't be added like this,
> although each individual addition is going to be very small because it does
> not move far in each frame, and I know that for very small angles vector
> addition is approximately correct. So is it valid to integrate position up
> like this or not?

I think if you make the mods i suggested you should find your method
works fine. Try it for a fixed object rotating at a fixed angular velocity,
at first, but when you get the hang of the simple stuff you should be
able to cope with displaying accelerating objects too, if you want.

> If not, then I guess that I am going to have to convert the angular velocity
> to quaternions or matrices before doing the second integration, this is a
> problem because these conversions require at least one sine and cosine
> calculation, for every frame, for every object. This is a big overhead in
> CPU time. Also I'm going to have to replace vector addition with quaternion
> multiplication (is there an equivalent of integration that uses
> infinitesimally small multiplications instead of additions?)

Would bother with any of that crap, if i were you Martin. The simple
finite difference method you are considering will work fine, promise.

keith stein

---

Message 3 in thread
From: Martin Baker
Subject: Re: How do I write a computer animation of solid body
Newsgroups: sci.physics
Date: 2003-01-12 15:06:07 PST

Keith,

Thanks for your prompt reply, could you clarify the following question for
me:

> > 3) Add above to the last angular position to give the new angular
> > position.
> WRONG !
> After 2) You have found w1 and w2. You first wand w(average)
> w(average) = (w1 + w2)/2
>
> Then you find the new angle position from:
> ANGLE2 = ANGLE1 + w(average)*Dt

From what I know about Euler angles, we have to specify what order the
rotations are made in, but nowhere here have we specified an order? So are
these Euler angles?
For example, if we take an example with fixed angular velocity as you
suggest, say:
dt = 0.1
a0 = [0,0,0]
w0 = [0.1, 0.2, 0.3]
angle0 = [0,0,0]

then:
w1 = ([0.1, 0.2, 0.3] + [0.1, 0.2, 0.3])/2 = [0.1, 0.2, 0.3]
angle1 = [0,0,0] + [0.1, 0.2, 0.3]*0.1 = [0.01, 0.02, 0.03]

w2 = ([0.1, 0.2, 0.3] + [0.1, 0.2, 0.3])/2 = [0.1, 0.2, 0.3]
angle2 = [0.01, 0.02, 0.03] + [0.1, 0.2, 0.3]*0.1 = [0.02, 0.04, 0.06]

w3 = ([0.1, 0.2, 0.3] + [0.1, 0.2, 0.3])/2 = [0.1, 0.2, 0.3]
angle3 = [0.02, 0.04, 0.06] + [0.1, 0.2, 0.3]*0.1 = [0.03, 0.06, 0.09]

and so on... but as the angle gets bigger it must get more important what
order the rotations are defined in? for example do we rotate 0.03 about the
x axis, then 0.06 about the y axis, then 0.09 about the z axis? or do we
rotate 0.06 about the y axis and then 0.03 about the x axis, then 0.09 about
the z axis? or some other permutation?

Thanks,

Martin

---

Message 4 in thread
From: J. Todd Wasson (jtw62074@aol.com)
Subject: Re: How do I write a computer animation of solid body
Newsgroups: sci.physics
Date: 2003-01-12 17:29:42 PST

Here's a discussion where some folks explained it to me. They really lay it
out all nicely. I use it now in my simulation stuff, and it works fine.

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=20010105012025.
13480.00001291%40ng-cn1.aol.com&rnum=1&prev=/groups%3Fq%3Dinertia%2Btensor
%2Bgroup:rec.autos.simulators%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3D2001
0105012025.13480.00001291%2540ng-cn1.aol.com%26rnum%3D1

The key here is that you're directly altering the rotation matrix of each body
according to angular momentum, velocity, etc.. After that, depending on your
3D system, you'll need to load this matrix directly and use it for rendering.

Using successive rotations around world coordinate axes will result in gimble
lock, so instead, you can simply load in the orientation matrix that results
from this algorithm and use it directly for animation. For instance, in
OpenGL, instead of using successive glRotate3f calls about each axis (where
order would matter, you're right), you can simply use glLoadMatrix to get the
orientation in one shot.

If you have any questions after this, give me a shout.

Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com

My little car sim screenshots:
http://performancesimulations.com/scnshot4.htm
Post a follow-up to this message

---

Message 5 in thread
From: Martin Baker
Subject: Re: How do I write a computer animation of solid body
Newsgroups: sci.physics
Date: 2003-01-13 00:57:02 PST

Todd,

> The key here is that you're directly altering the rotation matrix of each body
> according to angular momentum, velocity, etc.. After that, depending on your
> 3D system, you'll need to load this matrix directly and use it for
rendering.

So how do I generate the matrix? Do I hold all the rotational quantities in
matrix form (in which case there is the issue of converting the dynamics
equations to matrix form) or do I convert from vectors (in which case there
is an overhead per frame, also this just pushes back the question of which
order to do the rotations to the generation of the matrix).

> Using successive rotations around world coordinate axes will result in gimble
> lock, so instead, you can simply load in the orientation matrix that results
> from this algorithm and use it directly for animation. For instance, in
> OpenGL, instead of using successive glRotate3f calls about each axis (where
> order would matter, you're right), you can simply use glLoadMatrix to get the
> orientation in one shot.

Again, this just seems to push back the problem to the generation of the
matrix?

Thanks,

Martin

---

Message 6 in thread
From: J. Todd Wasson (jtw62074@aol.com)
Subject: Re: How do I write a computer animation of solid body
Newsgroups: sci.physics
Date: 2003-01-13 15:40:01 PST

>> The key here is that you're directly altering the rotation matrix of each body
>> according to angular momentum, velocity, etc.. After that, depending on your
>> 3D system, you'll need to load this matrix directly and use it for
>rendering.
>
>So how do I generate the matrix? Do I hold all the rotational quantities in
>matrix form (in which case there is the issue of converting the dynamics
>equations to matrix form) or do I convert from vectors (in which case there
>is an overhead per frame, also this just pushes back the question of which
>order to do the rotations to the generation of the matrix).
>

You define the orientation matrix at the beginning of the simulation and leave
it alone. This becomes your state variable (or group of them, however you want
to refer to it) that *is* the orientation. There is no longer yaw, pitch, or
roll (Euler angles) in the definition of a body's orientation. With the
approach shown in the other link, you're simply altering the matrix directly
using the inertia tensor and angular momentum/velocity and force vectors, once
the initial matrix is set. It is NOT being done by a series of successive
rotations about the x, y, and z axes in the top reference frame (as far as I
can tell, anyway.)

>> Using successive rotations around world coordinate axes will result in gimble
>> lock, so instead, you can simply load in the orientation matrix that results
>> from this algorithm and use it directly for animation. For instance, in
>> OpenGL, instead of using successive glRotate3f calls about each axis (where
>> order would matter, you're right), you can simply use glLoadMatrix to get the
>> orientation in one shot.
>
>Again, this just seems to push back the problem to the generation of the
>matrix?
>

No, the matrix is manipulated directly. It's generated one time in the
beginning of the simulation to initialize the orientation of a body, but that's
it. Yes, if you wanted to generate the initial matrix from Euler angles, the
order of rotations matters, but this would happen only one time; at the
beginning of the simulation in order to simply get an initial state. You're
more or less free to use your own definitions then for how "yaw, pitch, and
roll" are combined to get an initial rotation matrix; there's not much else you
can do, I think.

After the intial matrix is set, all forces and torques manipulate it directly.
You aren't generating a new matrix each time step, per se. Instead, you're
calculating a new, seperate one using the angular velocity and angular momentum
vectors, and the inertia tensor in the upper most frame of reference. This new
matrix is simply added to the old rotation matrix, then normalized and
reorthogonalized if necessary. Voila, you've got a new orientation matrix for
the body and there are no Euler angles to consider at any point along the way
once the simulation has begun. As such, the order of rotations doesn't matter
in this context because you aren't rotating anything around the uppermost
frame's "world axes" successively one after the other. The rotation matrix is
being rotated around the angular velocity vector.

What I'm getting at is that given the angular momentum vector, angular velocity
vector, and inertia tensor, you can calculate the next time step's rotation
matrix directly (which is "correct" in the instantaneous sense, but loses
precision with increasing integration step sizes just like anything else does.)
This isn't done through a series of successive rotations about the x, y, and z
axes in the "world frame", so it isn't necessary to be concerned with the order
of rotations. There's only one "correct" answer for the next time step's
rotation matrix, and it can be calculated directly. It's not a series of
rotations about the three axes being performed to produce this.

The Chris Hecker paper I referred you to in another thread covers this, as does
Dr. Baraff's paper from the Google thread I just posted. I strongly urge you
to download them and have a read. You seem to have a much better grasp of
mathematics than I do, so I recommend looking at Dr. Baraff's papers first, as
they're much more thorough. He also covers quaternion representation of
rotations, something I'm not going to bother with anytime soon because I don't
really need them, but you may want to look at them as well.

Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com

My little car sim screenshots:
http://performancesimulations.com/scnshot4.htm

---

Message 7 in thread
From: Martin Baker
Subject: Re: How do I write a computer animation of solid body
Newsgroups: sci.physics
Date: 2003-01-14 08:44:05 PST

Todd,

Sorry, I'm still not quite with you.

> After the intial matrix is set, all forces and torques manipulate it directly.
> You aren't generating a new matrix each time step, per se. Instead, you're
> calculating a new, seperate one using the angular velocity and angular momentum
> vectors, and the inertia tensor in the upper most frame of reference. This new
> matrix is simply added to the old rotation matrix, then normalized and

Did you mean to say the new matrix is multiplied as opposed to added to the
old rotation matrix?

In other words could I write it like this:
[On+1] = [dO]*[On]
where:
[On+1] = orientation matrix at frame n+1
[On] = orientation matrix at frame n
[dO] = change in orientation from frame n to frame n+1

But how do I calculate [d0]?
Is it a diagonal matrix with the angular velocity components, i.e.,
wx*dt 0 0
0 wy*dt 0
0 0 wz*dt
where:
wx = angular velocity about x axis
wy = angular velocity about y axis
wz = angular velocity about z axis
dt = time between frames

This is just a guess, I had another quick look through the references you
gave (which I agree are very good) but I could not find out how to calculate
this. I probably missed it, I'll have to spend much more time reading them
properly, but if you could give me a hint it would really help.

The only thing that I could find (from the newsgroup messages between you
and Gregor) is the following:

(d omega)/dt = J^(-1) (torque - omega (x) (J omega) )
where:
J=O J0 O^T
J^(-1)= O (J0^(-1)) O^T
O = orientation matrix
omega = rotational velocity vector

But, correct me if I'm wrong, is this just the torque=[I]*alpha equation but
translated from the local frame-of-reference to the absolute frame-of
reference.
So we still have to integrate twice to get from the angular acceleration to
angular position, I think that is the stage I'm missing.

As I understand it, in these equations and the references, most of the
angular quantities such as w and torque are held as vectors but the
orientation is held as a matrix, which makes sense. So when we are
integrating from w to orientation we also need to convert from vector to
matrix, which is why I guessed it might be a diagonal matrix.

Thanks,

Martin
Post a follow-up to this message

---

Message 8 in thread
From: J. Todd Wasson (jtw62074@aol.com)
Subject: Re: How do I write a computer animation of solid body
Newsgroups: sci.physics
Date: 2003-01-17 16:47:03 PST

Hi, Martin.

Dr. Gregor Veble's explanation was a very thorough method that is overkill for
this type of application. He is showing how to use angular velocity to do the
integrations, when really this is not necessary (he admits this after Petri
Blomquist provided the following, much simpler explanation for me.) The quotes
early on are from me, where I was desperately trying to understand how this all
worked. Obviously, it would be best to ignore my own statements there and
instead pay attention to Petri :-D

I have slightly edited his text for clarity and added notes to parts of the old
post here between lines like this:

--------Martin: NOTE/TIP---
Stuff from me to expand on or clarify things.
------

Petri Blomquist wrote:

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.

--------Martin: NOTE/TIP---
This is a 3x3 matrix that is the inertia tensor. In car simulators, we use a
simplification that is simply the moment of inertia about each axis in the
body's coordinate system, and would look like this:
|xx 0 0|
|0 yy 0|
|0 0 zz|

You can of course use a "full" inertia tensor here and get rid of the 0's, but
I am not certain how that would be inverted properly. I'm sure you do, however
:-)

Part of the calculations that follow would normally include dividing by the
inertia tensor for rotation (i.e., angular_momentum_change =
torque/moment_of_inertia).
However, on today's CPU's it is currently much faster, safer, and usually more
accurate to multiply than divide, so we simply invert all these elements.
I.e., xx is really 1/xx, yy is really 1/yy, etc.. If you do this for all the
elements, you will have the "inverse inertia tensor" of the body in the body's
coordinate system or reference frame.

Important: This is the inverse inertia tensor in the body's coordinate system.
It does NOT change during the simulation unless the body undergoes a change in
mass, mass distribution, or shape, so this matrix can be calculated one time
for each object in the beginning of the simulation and stored. It is
effectively a constant from then on in the rigid body simulation case.

-----Back to Petri's lesson:-------

Assuming you calculate the torque vector and angular velocity and momentum
vectors in world coordinates, as I have done, what you do is 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

--------Martin: NOTE/TIP---
Don't worry.. You have NOT calculated the angular velocity vector yet at this
stage. What he is saying here is that you must now add up all the forces
acting on all the objects in "world coordinates," or in your system, the "top
most" reference frame. You're calculating the final, total torque vector in
"world coordinates" of each object. Remember, there will be only one total,
resultant torque vector acting on each body. This is a cross product operation
using the force vector and force's position vector on the body, a simple
calculation I think you are familiar with already. Simply add all the torque
vectors and you will have the final, resultant torque vector. Again, it's
important to have the final result in world coordinates for this particular
approach to work.

Once you have this torque vector, you can multiply this by your time step and
add it to your angular momentum vector for the body. This is simply
calculating the new angular momentum vector. I.e., if there is no torque, the
angular momentum vector will remain the same as it did in the previous time
step; Conservation of Angular Momentum is observed in this approach.

Next, we will calculate the angular velocity vector. Note that this is
calculated "fresh" each loop. I.e., the angular velocity vector is not a state
variable like angular momentum is. This is a neat little trick that lets you
bypass the more involved approach Dr. Gregor Veble discussed and get the same
result a lot quicker. (He has a Ph.D in chaos theory, so his methods are
usually extremely involved; I can't follow most of them :-P)

--------------------Back to Petri for the next step:----

To calculate the angular velocity vector, you first multiply the current
rotation matrix (R) by the inverse of the inertia tensor (Ibodyinv, which
you calculated and stored once in the beginning of the program), then multiply
the result of that by the transpose of the current rotation matrix of the body
(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.

Petri Blomqvist

--------Martin: NOTE/TIP---
Ok, he skips a couple of things here. Here's what we've done up to this point.

1. Using the torque vector in world coordinates (upper most frame of
reference), we multiply by the time step and add this to the angular momentum
vector (also in world coordinates.) When you do collision response, you should
also add impulses to the body at this stage. Note that it is just as easy to
do this in world coordinates as it is in any other frame. (Chris Hecker's paper
shows the impulse magnitude equation for two bodies colliding taking into
account their inertia tensors, angular and translational velocities, and mass.
The calculation is nearly identical regardless of the frame of reference, hence
my suggestion in another thread that it would be wasteful to try to "simplify"
the calculation by running down to a lower frame of reference. All you do is
let a couple of variables drop out of the impulse maginitude equation. In the
meantime, you're doing a lot more calculations by transforming the vectors down
to the frame of reference you're interested in, and then back up to get all
this stuff in world coordinates so it can be used to rotate the body correctly.
Nevermind that for now, that's just for collision response and doesn't effect
what we're talking about here. Just something to chew on while you continue
your work.)

2. Now we need to calculate the angular velocity vector. This is hairy and I
don't really understand why it works, but it does. Perhaps you can explain it
to me after studying it, because I'd love to know :-D The papers lose me in
this area. As I said, I'm not very good at math.

The section below is basically what my code looks like, except these are all
matrix multiplications. TRN() is a transpose operation. Note that it's quite
possible that with my somewhat sloppy programming style, I may be transposing
unnecessarily to cover up previous "goofs" in the rest of my code. I forget
now. This is poor programming practice, but in my case, if it works I'm happy,
so I go ahead and do it sometimes :-) In essence, try to follow Petri's
explanations and compare it here as necessary. I arrived at this through a bit
of trial and error. Your coordinate system and the way you are defining your
matrices may effect things; this may be buggy in your system and need
modification, but it should at least point you in the right direction for
writing out the equations in full form as you seem to want to do.

I do not want to expand all of this here, however. You will be able to do that
yourself anyway.

Here's how to calculate the angular velocity vector given what we have at this
point:

ResultMatrix() = InverseInertiaTensor() * BodyRotationMatrix()
TransposeRotationMatrix() = TRN(BodyRotationMatrix())
WorldInverseInertiaTensor() = TransposeRotationMatrix() * ResultMatrix()
AngularVelocityVector() = WorldInverseInertiaTensor() * AngularMomentumVector()

Above, the InverseInertiaTensor is the first thing we calculated. This is the
InverseInertiaTensor in the body's reference frame/coordinate system and is
only calculated one time at the beginning of the simulation.

You're multiplying this by the rotation matrix of the body, then multiplying
the result of that by the transpose of the rotation matrix. You now have the
inverse of the inertia tensor in world coordinates (another 3x3 matrix.)

The angular velocity vector is simply the inverse of the inertia tensor in
world coordinates (that we just calculated) multiplied by the angular momentum
vector. You're multiplying a 3x3 matrix by a 3 vector, so the result is a 3
vector: the angular velocity.

Note again that there is no integration of the angular velocity vector here.
Angular velocity is a function of angular momentum, body orientation, and the
inertia tensor ONLY in the above algorithm. Angular velocity is not a state
variable.

Now that you have the angular velocity vector, you construct a new, seperate
matrix from the components. This is covered in Chris Hecker's paper, and he
explains what exactly this does and why it works, but I am not quite smart
enough to understand it yet :-) If you could explain it to me, I'd be
appreciative.

This is a "tilde" operation as he describes it.

|0 -z y|
|z 0 -x|
|-y -x 0|

You are simply constructing a matrix that looks like the above bit out of the
angular velocity vector. I refer to this in my code as the "angular velocity
matrix," which is a silly definition, but it's easy for me to remember what it
is this way.

Now we are getting closer to calculating the new orientation matrix of the body
that will be used for the next integration step.

Next, we multiply the body's rotation matrix by the "angular velocity matrix"
we just constructed with the "tilde" operation.

ResultMatrix() = BodyRotationMatrix() * AngularVelocityMatrix()

This "ResultMatrix" gives how much each component of the body's rotation matrix
will change over the course of the next time step. It is simply added to the
old rotation matrix to get the new one:

BodyRotationMatrix() = BodyRotationMatrix() + ResultMatrix()

Bang... You've got the new rotation matrix complete with nutation and
precession, and it follows Conservation of Angular Momentum.

This rotation matrix should be used directly in your animation. Note that
there is no "order or rotations" here to worry about because you've calculated
the new rotation matrix directly from the other variables. At this stage, if I
want to display the body in OpenGL, I just call glLoadMatrix or glMultMatrix.
DirectX of course has equivelent functions.

Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com

My little car sim screenshots:
http://performancesimulations.com/scnshot4.htm

---

Message 9 in thread
From: Maleki (maleki_m_@hotmail.com)
Subject: Re: How do I write a computer animation of solid body
Newsgroups: sci.physics
Date: 2003-01-15 18:50:34 PST

On Mon, 13 Jan 2003 08:56:30 +0000 (UTC), "Martin
Baker" wrote in
<avtuvu$hen$1@venus.btinternet.com> that:

>Again, this just seems to push back the problem to the generation of the
>matrix?

Doing a computer animation of a solid body requires a
knowledge of math, physics (so one could bet you've
seen the relevant math before), computer programming,
and of course you should be a detail oriented person
and put a few days of careful work into it.

If you meet all this, then reading a couple of pages of
a graphing book should be all you need. Read the
section that discusses the four transformations that
are involved, especially the last one that deals with
projecting the actual image onto the screen of your
monitor, because this one is not covered in your past
physics or math courses.

If you do not have the background I just mentioned, you
might as well forget it. Save yourself an ordeal you're
doomed to fail from beginning.

-------------------------

momken tA vAjeb nashavad hAsel nashavad, va tA
momtane' nashavad lAhAsel nashavad.

"Nasireddin Tusi"

---

Message 10 in thread
From: J. Todd Wasson (jtw62074@aol.com)
Subject: Re: How do I write a computer animation of solid body
Newsgroups: sci.physics
Date: 2003-01-17 15:26:00 PST

>>Again, this just seems to push back the problem to the generation of the
>>matrix?
>
>Doing a computer animation of a solid body requires a
>knowledge of math, physics (so one could bet you've
>seen the relevant math before), computer programming,
>and of course you should be a detail oriented person
>and put a few days of careful work into it.
>

A few days? hehe.. I've spent nearly 3 years on my vehicle model to date.
Doing a thorough "general rigid body dynamics" program could easily take just
as long or longer.

Judging by Marin's website and discussions so far in this forum, I think he is
quite capable enough in all these areas to do it :-)

>If you meet all this, then reading a couple of pages of
>a graphing book should be all you need. Read the
>section that discusses the four transformations that
>are involved, especially the last one that deals with
>projecting the actual image onto the screen of your
>monitor, because this one is not covered in your past
>physics or math courses.

This isn't necessary if you're using OpenGL or DirectX. The 3D graphic
projections are handled on your 3D video card now, or done through DX or
OpenGL's internal mechanisms.

>If you do not have the background I just mentioned, you
>might as well forget it. Save yourself an ordeal you're
>doomed to fail from beginning.
>

I think Martin will do just fine :-D

Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com

My little car sim screenshots:
http://performancesimulations.com/scnshot4.htm
Post a follow-up to this message

---

Message 11 in thread

From: Maleki (maleki_m_@hotmail.com)
Subject: Re: How do I write a computer animation of solid body
Newsgroups: sci.physics
Date: 2003-01-17 15:48:30 PST

On 17 Jan 2003 23:25:32 GMT, jtw62074@aol.com (J. Todd
Wasson) wrote in
<20030117182532.07839.00000075@mb-fk.aol.com> that:

>>>Again, this just seems to push back the problem to the generation of the
>>>matrix?
>>
>>Doing a computer animation of a solid body requires a
>>knowledge of math, physics (so one could bet you've
>>seen the relevant math before), computer programming,
>>and of course you should be a detail oriented person
>>and put a few days of careful work into it.
>>
>
>A few days? hehe.. I've spent nearly 3 years on my vehicle model to date.
>Doing a thorough "general rigid body dynamics" program could easily take just
>as long or longer.
>

With the background I explained, only a few days would
be needed without the physics of motion. Years back it
took me about three days to write a program to move a
cube around on the screen in any way and manner I
wanted. Actually moving the angle of view of a
stationary cube. From scratch of course (using DOS
based Borland Turbo C++). What you are doing involves
physics as well, I'd say add a week or so for the
implementation of the physics of it, another week for
making pictures, colors, etc, sexier. With the proper
background you'd do it thus in less than a month.

>Judging by Marin's website and discussions so far in this forum, I think he is
>quite capable enough in all these areas to do it :-)
>
>
>
>>If you meet all this, then reading a couple of pages of
>>a graphing book should be all you need. Read the
>>section that discusses the four transformations that
>>are involved, especially the last one that deals with
>>projecting the actual image onto the screen of your
>>monitor, because this one is not covered in your past
>>physics or math courses.
>
>This isn't necessary if you're using OpenGL or DirectX. The 3D graphic
>projections are handled on your 3D video card now, or done through DX or
>OpenGL's internal mechanisms.
>

Sure, I bet there are applications now that make
writing such programs even easier.

>>If you do not have the background I just mentioned, you
>>might as well forget it. Save yourself an ordeal you're
>>doomed to fail from beginning.
>>
>
>
>My little car sim screenshots:
>http://performancesimulations.com/scnshot4.htm

Nice work :)

-------------------------

khodAyA:
aghideye marA az daste oghde'am masun bedAr.

"Ali Shari'ati"
Post a follow-up to this message

---

Message 12 in thread
From: J. Todd Wasson (jtw62074@aol.com)
Subject: Re: How do I write a computer animation of solid body


View this article only
Newsgroups: sci.physics
Date: 2003-01-17 17:05:05 PST

>>A few days? hehe.. I've spent nearly 3 years on my vehicle model to date.
>>Doing a thorough "general rigid body dynamics" program could easily take just
>>as long or longer.
>>
>
>With the background I explained, only a few days would
>be needed without the physics of motion. Years back it
>took me about three days to write a program to move a
>cube around on the screen in any way and manner I
>wanted. Actually moving the angle of view of a
>stationary cube. From scratch of course (using DOS
>based Borland Turbo C++). What you are doing involves
>physics as well, I'd say add a week or so for the
>implementation of the physics of it, another week for
>making pictures, colors, etc, sexier. With the proper
>background you'd do it thus in less than a month.
>
>

Ah, ok. Yes, this does not take long, even in DOS (provided you aren't too
worried about hidden surfaces.) I neglected to think that you might have
missed his other thread recently on this subject, where his intentions were
outlined more fully. My impression was that his intent was to write a full
rigid body physics and animation system with contraints including collision
response code. Something that can take quite a bit longer to do of course. My
fault for assuming when I should not have :-D

My hat's off to you for writing even a basic 3D application in DOS. This is
something that most 3D programmers today probably do not know how to do.
Coming from DOS, you're right about checking into projection algorithms. I
sometimes forget that the whole world is not using OpenGL or DirectX, and some
people actually know how to do the calculations manually :-D I spent more
than a year developing the vehicle simulator on a DOS 3D wireframe engine I
wrote, but was stunned when I found out how easy OpenGL is to use, and haven't
looked back since.

>Sure, I bet there are applications now that make
>writing such programs even easier.

OpenGL is very cool :-D You could get a rotating cube, fully texture mapped up
and running in a couple hours knowing less than you needed to know for your DOS
program. It's much easier these days than it used to be :-)

>>My little car sim screenshots:
>>http://performancesimulations.com/scnshot4.htm
>
>Nice work :)
>

Thanks :-D

Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com

My little car sim screenshots:
http://performancesimulations.com/scnshot4.htm

---

Message 13 in thread
From: Maleki (maleki_m_@hotmail.com)
Subject: Re: How do I write a computer animation of solid body


View this article only
Newsgroups: sci.physics
Date: 2003-01-18 14:01:50 PST

On 18 Jan 2003 01:04:19 GMT, jtw62074@aol.com (J. Todd
Wasson) wrote in
<20030117200419.07839.00000077@mb-fk.aol.com> that:

>OpenGL is very cool :-D

Is it free ("open" usually means free I guess)?

-------------------------

khodAvand "marde amal" ast! va dar daftare khod
nAm va shohrat va shekle ashkhAs rA sabt nemikonad
balke a'mAl va AsAre amal rA sabt kardeh tebghe An
bA ehsA'iyyeye daghigh pAdAsh midahad.

"Mehdi Bazargan"

---

Message 14 in thread
From: J. Todd Wasson (jtw62074@aol.com)
Subject: Re: How do I write a computer animation of solid body
Newsgroups: sci.physics
Date: 2003-01-19 22:42:49 PST

>>OpenGL is very cool :-D
>
>Is it free ("open" usually means free I guess)?
>
>-------------------------

Yes, the OpenGL API is free, as is DirectX. OpenGL is quite a bit easier to
use, however.

Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com

My little car sim screenshots:
http://performancesimulations.com/scnshot4.htm

---

Message 15 in thread
From: Maleki (maleki_m_@hotmail.com)
Subject: Re: How do I write a computer animation of solid body


View this article only
Newsgroups: sci.physics
Date: 2003-01-20 00:52:25 PST

On 20 Jan 2003 06:41:49 GMT, jtw62074@aol.com (J. Todd
Wasson) wrote in
<20030120014149.18406.00000137@mb-ma.aol.com> that:

>>>OpenGL is very cool :-D
>>
>>Is it free ("open" usually means free I guess)?
>>
>>-------------------------
>
>Yes, the OpenGL API is free, as is DirectX. OpenGL is quite a bit easier to
>use, however.
>
>

If OpenGL is just a collection of graphics library
subroutines, and one still has to write a C program to
utilize it, then perhaps you overestimated the depth of
what I did to move a cube around the screen. I used C
(provided by Borland) and wrote a program that used
Borland's own graphics library to draw lines, go to
prescribed points on the screen, etc. So I think it
must have been similar to using OpenGL. But if there
are applications that in effect save the users the
trouble of writing C programs to get the jobs done,
then yes what I did was a bit more involved.

-------------------------

khodAyA:
marA az in fAje'eye palide "maslahat parasti," ke
chon hamegir shodeh vaghAhatash az yAd rafteh, va
bimAri'i shodeh ke az fart omumiyyatash har ke az
An sAlem mAndeh bimAr minamAyad, masun bedAr, tA
be ra'Ayate maslahat haghighat rA zebhe shar'i
nakonam.

"Ali Shari'ati"

---

Message 16 in thread

From: J. Todd Wasson (jtw62074@aol.com)
Subject: Re: How do I write a computer animation of solid body
View: Complete Thread (24 articles)
Original Format
Newsgroups: sci.physics
Date: 2003-01-20 02:31:52 PST

>>Yes, the OpenGL API is free, as is DirectX. OpenGL is quite a bit easier to
>>use, however.
>>
>>
>
>If OpenGL is just a collection of graphics library
>subroutines, and one still has to write a C program to
>utilize it, then perhaps you overestimated the depth of
>what I did to move a cube around the screen. I used C
>(provided by Borland) and wrote a program that used
>Borland's own graphics library to draw lines, go to
>prescribed points on the screen, etc. So I think it
>must have been similar to using OpenGL. But if there
>are applications that in effect save the users the
>trouble of writing C programs to get the jobs done,
>then yes what I did was a bit more involved.

OpenGL is a library similar to what you probably used, that is called from your
C (or other language) program in a similar fashion. With it, you're operating
at a higher level than you were with your library however, meaning it insulates
you further from the video hardware than you were with the Borland compiler and
graphics library. I think you'd find that making a system using OpenGL is
substantially easier than how you were doing it.

Drawing a cube in OpenGL does not involve actually calculating the positions of
the vertices or manually drawing the lines connecting them as you needed to do
for your system. Yes, you used a library to draw the lines, but in OpenGL you
don't even need to do that yourself. You also do not need to rasturize or fill
in the surfaces yourself, so you don't need to know the calculations necessary
for projecting the vertices to the screen. It's quite a bit easier than what
did, actually.

The hardest part is probably getting an initial framework up and running, but
that's actually pretty easy because you can just copy an example skeleton from
somewhere and study it. :-) (My car simulator started as a little rotating box
demo I found, then I just started adding stuff to it.) From there, you don't
even need to do your own matrix calculations for rotation. You can call a
function like glRotatef to do a rotation operation on your orientation matrix
about any axis you want, or load in your own matrix with glLoadMatrix. You
don't have to even define the matrices! OpenGL has three internal matrix
stacks than you can pop and push and manipulate very easily.

You can move the viewpoint or objects around with glTranslatef (x,y,z) as well,
which simply changes the "internal" matrix that OpenGL is using.

After that, you simply define the object's points in body coordinates and then
tell OpenGL to draw the scene, then tell it to swap buffers. It does all the
matrix calculations that you wrote yourself internally. You'd basically make a
surface on cube like this:

glLoadIdentity//Sets OpenGL's current matrix to the identity matrix.

//Set view transform:
//Camera location
glRotatef -RollCam,0,0,1
glRotatef -PitchCam,1,0,0
glRotatef YawCam,0,1,0
glTranslatef -XCam,-YCam,ZCam
glMultMatrixf ObjectRotationMatrix(0)//Rotate the object. You could also use
more glRotatef calls instead here.

//Draw the face
glBegin GL_QUADS
glVertex3f 0,0,0
glVertex3f 10,0,0
glVertex3f 10,10,0
glVertex3f 0,10,0
glEnd

//Tell OpenGL you're done drawing and display it on screen
SwapBuffers hDC

Do you want to rotate the box 5 degrees around the y axis on the next frame?
Just put this in the right spot:

glRotatef 5,0,1,0

You don't even need to recalculate the new vertex positions in either 3D or 2D,
because you're just transforming the OpenGL matrix that the system will use to
multiply all the vertices you've defined by.

That's pretty much all there is to it for basic stuff. OpenGL does all the
hidden surface removal (through a Z buffer that you don't have to do anything
with except define in one line of code during initialization), and completely
renders everything just from this little code fragment. If you change the
vertex colors (just call glColor3f before each glVertex3f to assign each vertex
a color), OpenGL will automatically blend the colors across each face,
resulting in some very nice looking stuff without you having to calculate the
rest yourself. It will even use whatever 3D graphics acceleration that's on
the system automatically to do whatever it can handle.

With a few more lines of code, you can texture map the surfaces as well.
Again, you're not doing any of this yourself, except to say "put this texture
on this surface." Easy stuff.

If you're still interested in 3D graphics, I urge you to take a look into
OpenGL and break out your Borland compiler again. Seeing as you've already
worked on a lower level than this, you'd probably be just as shocked as I was
to see how easy it is to use when compared to writing your own system at a
lower level :-) My cheesy little wireframe engine was probably more difficult
to write than the car simulator's graphics engine, even with all the textures
and stuff.

In 3D systems, at the lowest level you'd be writing assembly code to draw each
point yourself, calculate the colors, etc.. What you did (and I in my old
wireframe engine) was a level above that: The graphics library would use the
endpoints to draw a line, and perhaps fill in a polygon with a solid color, but
you still had to do all the 3D calculations (matrix rotations, projections,
etc.) to figure out where the endpoints of each line were on the screen
yourself. You were doing everything you'd have to do in an OpenGL app, plus a
lot.

OpenGL and DirectX go up another level, and take care of all the nasty stuff
for you. It's actually quite necessary now; otherwise you'd need ot write your
own rasturizer for every sort of 3D video card out there. Yikes :-) Anyway,
you're running at a higher level with these systems, so it's generally quite a
bit easier.

Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com

My little car sim screenshots:
http://performancesimulations.com/scnshot4.htm

---

Message 17 in thread
From: Maleki (maleki_m_@hotmail.com)
Subject: Re: How do I write a computer animation of solid body


View this article only
Newsgroups: sci.physics
Date: 2003-01-20 23:57:54 PST

On 20 Jan 2003 10:30:54 GMT, jtw62074@aol.com (J. Todd
Wasson) wrote in
<20030120053054.18514.00000074@mb-ma.aol.com> that:

>
>
>OpenGL is a library similar to what you probably used, that is called from your
>C (or other language) program in a similar fashion. With it, you're operating
>at a higher level than you were with your library however, meaning it insulates
>you further from the video hardware than you were with the Borland compiler and
>graphics library. I think you'd find that making a system using OpenGL is
>substantially easier than how you were doing it.
>
>Drawing a cube in OpenGL does not involve actually calculating the positions of
>the vertices or manually drawing the lines connecting them as you needed to do
>for your system. Yes, you used a library to draw the lines, but in OpenGL you
>don't even need to do that yourself. You also do not need to rasturize or fill
>in the surfaces yourself, so you don't need to know the calculations necessary
>for projecting the vertices to the screen. It's quite a bit easier than what
>did, actually.
>
>The hardest part is probably getting an initial framework up and running, but
>that's actually pretty easy because you can just copy an example skeleton from
>somewhere and study it. :-) (My car simulator started as a little rotating box
>demo I found, then I just started adding stuff to it.) From there, you don't
>even need to do your own matrix calculations for rotation. You can call a
>function like glRotatef to do a rotation operation on your orientation matrix
>about any axis you want, or load in your own matrix with glLoadMatrix. You
>don't have to even define the matrices! OpenGL has three internal matrix
>stacks than you can pop and push and manipulate very easily.
>
>You can move the viewpoint or objects around with glTranslatef (x,y,z) as well,
>which simply changes the "internal" matrix that OpenGL is using.
>
>After that, you simply define the object's points in body coordinates and then
>tell OpenGL to draw the scene, then tell it to swap buffers. It does all the
>matrix calculations that you wrote yourself internally. You'd basically make a
>surface on cube like this:
>
>glLoadIdentity//Sets OpenGL's current matrix to the identity matrix.
>
>//Set view transform:
>//Camera location
> glRotatef -RollCam,0,0,1
> glRotatef -PitchCam,1,0,0
> glRotatef YawCam,0,1,0
>glTranslatef -XCam,-YCam,ZCam
>glMultMatrixf ObjectRotationMatrix(0)//Rotate the object. You could also use
>more glRotatef calls instead here.

Read the rest of this message... (121 more lines)

---

Message 18 in thread

From: J. Todd Wasson (jtw62074@aol.com)
Subject: Re: How do I write a computer animation of solid body
Newsgroups: sci.physics
Date: 2003-01-21 22:58:10 PST

>Very interesting :) Gets most of the hassle of graphics
>programming out of the way, but programming still has
>to be there I suppose, if you want to implement physics
>into your car's motion. Only the visualization part of
>the codes will be greatly simplified by OpenGL. For
>instance if there is rotation and translation, the
>amount of each during certain period needs physics
>calculation and programming. Or heck, perhaps there are
>even software that do a lot of physics calculations for
>you too :) I don't know.
>
>Back in the 80s I did a lot of scientific programming.
>Lots of ready to use subroutines were available (in
>Fortran) that would, to some extent, simplify the job
>of creating a model of some physical process. But the
>extent of them were limited and most of us, including
>me, found it easier to ignore available codes and just
>write everything from scratch, tailor made for our own
>purposes. But after 20 years, and seeing something like
>OpenGL is _freely_ available to public I guess much
>more has become available for scientific computing. Do
>you use physic calculations in your programs? If so,
>are there applications that are similarly helping you
>simplify the process or do you have to do the physics
>part step by step by yourself?
>

Yes, I do a lot of physics calculations in my programs, especially the 3D car
simulator (the physics engine by itself is over 9000 lines long and will grow a
lot more before it's "done.") I don't get help from any libraries though; it's
all done the hard way, although engines like Havoc and MathEngine are available
that can do this type of thing as well. Be prepared to spend 5 or 6 figures
for a license to use it for the development of ONE program, though. An
alternative is DOE, a free system written by an ex MathEngine employee that
looks quite good. Actually, if you weren't going to sell the program, a lot of
these companies that charge big licensing fees will let you use their system
for free. I'm not sure about those two, though.

My system is designed to be exactly just such a library, except it's
specialized to work only with cars, trucks, go-karts, etc.. When it comes to
cars, it'll run circles around MathEngine and Havoc performance-wise, but it
can't do anything BUT cars :-) Right now it's being licensed to a developer
that's using it to help write a racing simulator for another company, and
they'll use it again to create a vehicle engineering package (possibly two or
three) for that company as well when it's finished. This other developer
doesn't know how to simulate a bouncing ball in 2D (literally, he told me
this), but his knowledge is far superior to my own when it comes to 3D graphics
and a page or two (or ten) of other things :-)

I think engineers nowadays interface with Simulink and Matlab to do physics
type stuff in their programs without having to code the equations themselves,
so yes, these sorts of libraries do exist where you can call functions that say
"I want two masses here with a hinge joint there, and then I want to hit it
with a bowling ball, then get the info every 1/30th of a second and animate it
through my own C coded graphics engine and user interface."

These are usually written to be very general systems capable of modelling just
about anything, which can be a good or bad thing depending on what kind of
system you're trying to model. Speed is usually not an issue with these
systems, I think, but accuracy is supposedly very good. (I get the feeling
Martin is trying to create something like this :-)) Generally I think these
are not for real time animations though.

>>If you're still interested in 3D graphics, I urge you to take a look into
>>OpenGL and break out your Borland compiler again.
>
>Hehe :) That Borland Turbo C++ was the first version
>out and if I'm going to spend any time on it I'd rather
>use newer versions to be safe. I don't know to what
>extent the first edition is machine dependent.

Borland was actually giving away free C++ compilers a year ago or so, if I'm
not mistaken. I'm not sure if they still do it. Honestly, I have no idea how
the first edition would work. Are you familiar with Windows programming? .

>Oh I can fully see the convenience of OpenGL,
>especially after your thorough explanation. And I
>remember what I had to go through to do the things that
>you showed are easily done by OpenGL. Of course if I
>had continued similar programs for some time I would
>also create subroutines to make similar simplifications
>that OpenGL provides, but I did that 3D thing just for
>fun and only to see if I could do it. When I realized I
>could do it I didn't continue it :) I've done lots of
>stuff and stopped at that stage (and for that purpose).
>

I can identify with that :-) You shouldn't give up though, right? ;-)

>>OpenGL and DirectX go up another level, and take care of all the nasty stuff
>>for you. It's actually quite necessary now; otherwise you'd need ot write your
>>own rasturizer for every sort of 3D video card out there. Yikes :-) Anyway,
>>you're running at a higher level with these systems, so it's generally quite a
>>bit easier.
>>
>
>Some ten or 15 years back I still would do all this for
>curiosity and fun. Now I have changed. It seems that
>now I have to have a more solid reason to do this
>stuff. If I'm going to do 3D programming, I need to
>know first for what purpose beyond fun and curiosity.
>If I come up with such a purpose OpenGL will become my
>everyday pal :)

Hmmm.... I gotta tell ya.. I started the 3D simulator using an OpenGL
rotating box demo I found, and in 3 days had a little road and cheezy car
running on it powered by my vehicle model DLL. It might be worth wasting a
week of your life just to see if the bug bites you again ;-)

What sorts of scientific programming were you doing?

Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com

My little car sim screenshots:
http://performancesimulations.com/scnshot4.htm
Post a follow-up to this message

---

Message 19 in thread

From: Maleki (maleki_m_@hotmail.com)
Subject: Re: How do I write a computer animation of solid body
View: Complete Thread (24 articles)
Original Format
Newsgroups: sci.physics
Date: 2003-01-22 02:01:03 PST

On 22 Jan 2003 06:57:52 GMT, jtw62074@aol.com (J. Todd
Wasson) wrote in
<20030122015752.11173.00000184@mb-fg.aol.com> that:

>
>
>Yes, I do a lot of physics calculations in my programs, especially the 3D car
>simulator (the physics engine by itself is over 9000 lines long and will grow a
>lot more before it's "done.") I don't get help from any libraries though; it's
>all done the hard way,

In what language, C?

>although engines like Havoc and MathEngine are available
>that can do this type of thing as well. Be prepared to spend 5 or 6 figures
>for a license to use it for the development of ONE program, though.

A state of the art scientific program that involves
various types of tricky and difficult computations will
take about a year to develop, from scratch to finish.
If "Havoc" and "MathEngine" could cut this to, say, 3
months, then I can understand why they charge 5 or 6
figures for using them. It would be about as much one
would have to pay somebody to develop it.

>An
>alternative is DOE, a free system written by an ex MathEngine employee that
>looks quite good. Actually, if you weren't going to sell the program, a lot of
>these companies that charge big licensing fees will let you use their system
>for free. I'm not sure about those two, though.
>

The prospects of selling the program must be there. It
would be extremely unfair, really meaningless, to not
benefit from the results of your work and time.

Also when future selling of the work is intended, then
it might even be advisable not to use such other
software to avoid instances of error and/or
undiscovered incompatibilities.

>My system is designed to be exactly just such a library, except it's
>specialized to work only with cars, trucks, go-karts, etc.. When it comes to
>cars, it'll run circles around MathEngine and Havoc performance-wise, but it
>can't do anything BUT cars :-) Right now it's being licensed to a developer
>that's using it to help write a racing simulator for another company, and
>they'll use it again to create a vehicle engineering package (possibly two or
>three) for that company as well when it's finished. This other developer
>doesn't know how to simulate a bouncing ball in 2D (literally, he told me
>this), but his knowledge is far superior to my own when it comes to 3D graphics
>and a page or two (or ten) of other things :-)
>

Then you're turning it into a career. Money is one of
those reasons "beyond fun and curiosity" :-)) But there
are other reasons beside money as well.

>I think engineers nowadays interface with Simulink and Matlab to do physics
>type stuff in their programs without having to code the equations themselves,
>so yes, these sorts of libraries do exist where you can call functions that say
>"I want two masses here with a hinge joint there, and then I want to hit it
>with a bowling ball, then get the info every 1/30th of a second and animate it
>through my own C coded graphics engine and user interface."
>

Again the reliability of such ready to use codes comes
to my mind. It depends on the sensitivity of the
project. For too sensitive and/or critical works I
believe one should not rely on anything but the most
straightforward and tested and simple ready-to-use
software. Research work is one example. You do not know
apriori what the result is going to look like because
by definition in that line of work you would be doing
something for the first time, trying a new idea and
implementing it into your program to see how the idea
works. If you are not _absolutely_ sure your codes are
doing exactly what they're supposed to do, you will not
be able to interpret the result no matter it matches
any other types of evidences or it doesn't.

>These are usually written to be very general systems capable of modelling just
>about anything, which can be a good or bad thing depending on what kind of
>system you're trying to model. Speed is usually not an issue with these
>systems, I think, but accuracy is supposedly very good. (I get the feeling
>Martin is trying to create something like this :-)) Generally I think these
>are not for real time animations though.
>

If the ultimate use is in a computer game or accuracies
as such, then reliability is not that much of an issue
and anything that can simplify the work would be
wonderful.

>
>Borland was actually giving away free C++ compilers a year ago or so, if I'm
>not mistaken. I'm not sure if they still do it. Honestly, I have no idea how
>the first edition would work. Are you familiar with Windows programming? .
>
>

I heard of that too, but that was the command line
version. It did not have an application coming with it
that would integrate the various features into one
windows application. I think from this point of view
Bloodshed Dev-C++ is superior to it. It is free and
comes with a rather nice application that brings
various features together. But it is almost as old as
the original Borland turbo c++ (Borland's came out I
think in 1989 or 1990 - that's when I bought it anyway
- Bloodshed dev-c++ free version is from early 1990s).

>>Oh I can fully see the convenience of OpenGL,
>>especially after your thorough explanation. And I
>>remember what I had to go through to do the things that
>>you showed are easily done by OpenGL. Of course if I
>>had continued similar programs for some time I would
>>also create subroutines to make similar simplifications
>>that OpenGL provides, but I did that 3D thing just for
>>fun and only to see if I could do it. When I realized I
>>could do it I didn't continue it :) I've done lots of
>>stuff and stopped at that stage (and for that purpose).
>>
>
>
>I can identify with that :-) You shouldn't give up though, right? ;-)
>
>

I have given up a hell of a lot more than that :-))

>>
>>Some ten or 15 years back I still would do all this for
>>curiosity and fun. Now I have changed. It seems that
>>now I have to have a more solid reason to do this
>>stuff. If I'm going to do 3D programming, I need to
>>know first for what purpose beyond fun and curiosity.
>>If I come up with such a purpose OpenGL will become my
>>everyday pal :)
>
>
>
>Hmmm.... I gotta tell ya.. I started the 3D simulator using an OpenGL
>rotating box demo I found, and in 3 days had a little road and cheezy car
>running on it powered by my vehicle model DLL. It might be worth wasting a
>week of your life just to see if the bug bites you again ;-)
>

I might do it, but not before becoming sure I have
everything that I need to have with me. I have various
projects in mind that I could embark on. For instance
I'd like to see if I could develop a fine program for
a, say, "smart eyeglasses" so the pair of glasses could
adjust for daily and hourly variation of eye's behavior
and accuracy. My own eyes changes accuracy and behavior
several times during the course of the same day. Just
putting a fixed set of two lenses in front of them is
stupid. For the Keck observatory (Hawaii) they could
write programs that would make up for all sorts of
variations in the accuracy of what they were observing
through the atmosphere. This is the type of programs I
would like to write for the "smart glasses" so it would
automatically make up for any change that my eyes go
through throughout 24 hours or a week or a year. There
might be a way for this glasses to see the image formed
on my retina and compare it to the object out there and
see if it is focused enough or if it has astigmatism,
and correct for the effects the way those Keck
Observatory codes do it. So as you see it is not a
matter of my decision to sit write the programs at
once, but a few things should first get done and
cleared out so I'd have what I need, and go from there.

>What sorts of scientific programming were you doing?
>

Oh, just various graduate school projects that
themselves were bits and pieces of what research that
particular center was conducting. In other words these
were not "baby problems" but real projects. It boiled
down, one way or another, and after taking care of
everything else, to solving some PDEs.

I didn't continue that one also :-) But I left it after
becoming pretty sure that I could do it. One life is
too short for repeating the same type of thing
endlessly. I am just not made for spending it that way.
But life is also too short for changing its mode and
direction endlessly. You'll end up in sci.physics, and
on the Oldman's list.

---

Message 20 in thread

From: Karl Forsberg (use.replyaddress@domain.invalid)
Subject: Re: How do I write a computer animation of solid body
View: Complete Thread (24 articles)
Original Format
Newsgroups: sci.physics
Date: 2003-01-13 11:30:41 PST

See eg https://www.euclideanspace.com/maths/geometry/rotations/index.htm ,
http://www.geocities.com/matrindade/papers/ijnme01b.pdf and the links
found there. It is usually a good idea to avoid using Euler angles.

---

Message 21 in thread

From: Karl Forsberg (use.replyaddress@domain.invalid)
Subject: Re: How do I write a computer animation of solid body
View: Complete Thread (24 articles)
Original Format
Newsgroups: sci.physics
Date: 2003-01-13 11:37:15 PST

Karl Forsberg wrote:

I just realized that the first is probably a reference to your own web
site - OOPS!

---

Message 22 in thread
From: Karl Forsberg (use.replyaddress@domain.invalid)
Subject: Re: How do I write a computer animation of solid body
Newsgroups: sci.physics
Date: 2003-01-13 11:52:11 PST

For everything but the kitchen sink when it comes to relevant
mathematics (most of it is rather abstract) see the SYNODE project
http://www.math.ntnu.no/num/synode/papers/synode_papers.html

---

Message 23 in thread
From: Martin Baker
Subject: Re: How do I write a computer animation of solid body
Newsgroups: sci.physics
Date: 2003-01-18 09:28:01 PST

Todd and everyone else,

Thank you very much, I am sure you have given me all the pieces of the
jigsaw, I just need to work though your e-mails and references step by step,
so it will take me a while (I just don't feel I understand things until I
work though it myself) More like a couple of weeks than a couple of days but
I will get there in the end!

Just one last question, I am still very uncomfortable with adding rotation
matrices as follows,
BodyRotationMatrix() = BodyRotationMatrix() + ResultMatrix()
Do you know what would be the physical effect of such an operation? or have
you overloaded the '+' operator to do a matrix product?

I have come across the "tilde" operation, If I understand correctly, it is
used to convert a vector cross product into an equivalent matrix transform.
So if v, w and r are all vectors we might have:

v = - (w × r)

We can rewrite this as a matrix transform:

v = -[~w]r

Of course I'll put what I manage to work out on my website,

Martin

---

Message 24 in thread
From: J. Todd Wasson (jtw62074@aol.com)
Subject: Re: How do I write a computer animation of solid body
Newsgroups: sci.physics
Date: 2003-01-19 22:52:50 PST

>Todd and everyone else,
>
>Thank you very much, I am sure you have given me all the pieces of the
>jigsaw, I just need to work though your e-mails and references step by step,
>so it will take me a while (I just don't feel I understand things until I
>work though it myself) More like a couple of weeks than a couple of days but
>I will get there in the end!
>

I have confidence in you, Martin :-) I'm looking forward to seeing what you
come up with!

>Just one last question, I am still very uncomfortable with adding rotation
>matrices as follows,
>BodyRotationMatrix() = BodyRotationMatrix() + ResultMatrix()
>Do you know what would be the physical effect of such an operation? or have
>you overloaded the '+' operator to do a matrix product?

ResultMatrix isn't really a rotation matrix, it's sort of an "added to the
rotation matrix rotation" matrix". (Great explanation, huh?! )

What you'll need to do is occasionally check and manually correct the final
rotation matrix as necessary. The result matrix will tend to cause shearing in
the body rotation matrix over time (this makes for some interesting looking
objects after awhile :-P), so I normalize the BodyRotationMatrix every time
step, and check to see if it's still orthogonal. To reorthogonalize it, after
normalizing I'll take two of the vectors from the rotation matrix, do a cross
product op to get the third "correct" vector, then cross that with one of the
other vectors and then update the BodyRotationMatrix. If you do this every
time step (or every few, depending on your speed/accuracy requirements),
everything stays nice and neat.

It's not perfect, but it's good enough for any use I can think of.

>I have come across the "tilde" operation, If I understand correctly, it is
>used to convert a vector cross product into an equivalent matrix transform.
>So if v, w and r are all vectors we might have:
>
>v = - (w x r)
>
>We can rewrite this as a matrix transform:
>
>v = -[~w]r
>
>Of course I'll put what I manage to work out on my website,
>

Yes, that sounds like Chris Hecker's explanation, but the math behind it is a
little beyond my grasp. I don't quite understand how/why it works yet. I'll
have to check your site occasionally for the explanation later on :-)

Thanks, and good luck!

Todd Wasson
---
Performance Simulations
Drag Racing and Top Speed Prediction
Software
http://PerformanceSimulations.Com

My little car sim screenshots:
http://performancesimulations.com/scnshot4.htm