RE: [Algorithms] Re: Cumalative rotation

[Tony C. <to...@mi...>]

>> You method is certainly simple, but it only works if the
>> inertia tensor is the identity. Which is true for uniformly
>> dense spheres or cubes, and not generally true otherwise.
>
>inertial tensor in my book (not the accurate book) is a three
>element vector. principle axes only.
>what you are talking about is the accurate and correct method.

The inertia tensor is not a three element vector. It is true that by =
appropriate choice of axes, you can make the inertia tensor into a =
diagonal matrix, but that's not quite the same thing.

>> No, no it can't. Consider a non-symmetrical rotating object,
>> with no torque applied. It's axis of rotation can change (and
>> indeed *will* change, unless it happened to already be
>> rotating about a principal axis). Therefore its angular
>> acceleration can be non-zero. And yet the applied torque is
>> zero. Your reasoning is incorrect.
>
>this I don't understand at all, if there is no force, then the
>torque vector will be zero, and whatever you multiply it by it
>will be zero...

Yes, that's true. The torque will be zero. The change in the angular =
*momentum* will be zero. However, the change in the angular velocity may =
well be non-zero, since the object is rotating.  This can easily be seen =
by considering the equation linking angular momentum with angular =
velocity, for an intertia tensor specified in object space:

AMom =3D WorldMatrix * InertiaTensor * InvWorldMatrix * AVel

Those WorldMatrix terms are there to transform into the appropriate =
space. The angular velocity and momentum are specified in world space. =
The inertia tensor is typically specified in object space. Therefore, =
you need to pre- and post- multiply the tensor by the (inverse) world =
matrix, in order to make sure we're consistent about our spaces. This =
pre- and post- multiply is characteristic of tensors, and is called the =
tensor transform.

Now, since the object is rotating, the world matrix changes. But if the =
angular momentum is constant, in world space, that must mean that the =
angular velocity changes, in world space (except in the case where the =
axis of rotation is one of the eigenvectors of the inertia tensor).

Does this make sense now?


>unless you mean by modifying the inertial tensor, and in my book
>that is a no-no...

Your book clearly never considers rotating objects. The tensor needs to =
be transformed from the frame of reference where it is specified =
(typically object space), into the frame of reference where you are =
doing your calculation. This involves a transformation which changes as =
the object rotates.

>sorry, but I don't use matrix based interial tensors... too
>little benefit for too much data and time... this is
>GAMEdev-algos.

Okay, well if you want to do something that's physically incorrect, then =
go right ahead. Maybe it produces pleasing results for your game. =
However, I know of many games that *do* do this correctly. And there are =
people that would like to know how. If you're going to present a =
non-correct solution, please state that loud and clear up front - your =
original posts implied that your procedure was correct, which is highly =
misleading to someone without expertise in the subject.

>Oh and by the way, the offset from the object origin means
>that the tensor doesn't need to be multiplied by world matrix,
>because the point of force application has already been
>transformed to object space.

Er, no. Computing the torque in object space is not especially useful, =
since angular momentum is not conserved in object space, it's conserved =
in world space (or any other fixed frame).

You clearly don't understand this at all.

>> Your procedure is simple, but it is also wrong. I make no
>> apology for correcting it.
>> - Tony
>
>I would agree with you but, I cannot say my method is wrong, it
>is merely not accurate to real world phsyics.=20

Well, I say that your method is wrong *because* it is not accurate to =
real world physics. What definition of 'wrong' were you using?

>this does not mean
>it is unusable. My method, and I am sure others are using it too,
>is simple, fast, and REASONABLY accurate. As I said earlier, this
>is GAME dev algos, and as such I personally think speed and
>acceptability are more important than complete accuracy.

If you're going to present an approximation, then say so. Don't present =
your method as correct (which is what you were doing), when clearly it =
isn't. And if you're going to present an approximation, please indicate =
how it deviates from the correct solution, and what tradeoffs are =
involved. You didn't do any of that.

As it happens, your approximation is not an especially good one, but for =
certain games where realism is unimportant it *may* produce acceptable =
results. More and more developers these days *are* choosing to do the =
right thing, though.

- Tony