applyOffsetForce for aim?

[Magos Mechanicus]

I don't see what offsetting the torque more would help matters, though?
Anyway, what I meant was:

ToAim = Barrel:toLocal(owner():aimPos()):normalized() #The direction from the barrel to the aim position, normalized and in the barrel's local coordinate system.
Error = vec(0,0,1):cross(ToAim) #Cross it with the up vector, which is [0,0,1] by definition of the local coordinate system. This is our error term - it's a vector normal to both the up and ToAim vectors and with a magnitude that approaches 0 as the two become approach parallell configuration, our goal. 
Torque = Pgain * Error + Dgain * $Error
Barrel:applyTorque(Torque*Barrel:inertia())

In practice I guess it will perform much like Divran's quaternion code, but notably it will allow the barrel to spin freely about its up vector and uses a more reliable method for selecting which face of the barrel aims in the given direction. Adding 90 Pitch isn't always accurate.

[Syranide]

I don't see what offsetting the torque more would help matters, though?
Anyway, what I meant was:

ToAim = Barrel:toLocal(owner():aimPos()):normalized() #The direction from the barrel to the aim position, normalized and in the barrel's local coordinate system.
Error = vec(0,0,1):cross(ToAim) #Cross it with the up vector, which is [0,0,1] by definition of the local coordinate system. This is our error term - it's a vector normal to both the up and ToAim vectors and with a magnitude that approaches 0 as the two become approach parallell configuration, our goal. 
Torque = Pgain * Error + Dgain * $Error
Barrel:applyTorque(Torque*Barrel:inertia())

In practice I guess it will perform much like Divran's quaternion code, but notably it will allow the barrel to spin freely about its up vector and uses a more reliable method for selecting which face of the barrel aims in the given direction. Adding 90 Pitch isn't always accurate.

Offset would allow it to rotate around where it is axised, instead of around the middle of the prop.

[Tolyzor]

Surely the props inertia would prevent it from acting like how you want it to act though? An offset torque would cause a reaction force to act on the axis you are torque-ing around due to the props inertia, meaning the axis point would move.

I think the best solution to vexx's problem would be to simply applyTorque the prop to the correct angle, and at the same time applyForce the prop so that the local prop axis which you wish to rotate around is always at the location you wish.

[Syranide]

Surely the props inertia would prevent it from acting like how you want it to act though? An offset torque would cause a reaction force to act on the axis you are torque-ing around due to the props inertia, meaning the axis point would move.

I think the best solution to vexx's problem would be to simply applyTorque the prop to the correct angle, and at the same time applyForce the prop so that the local prop axis which you wish to rotate around is always at the location you wish.

I'm not quite sure if I follow or if I'm missing something.

But consider two fixed wheels connected via two beams, as one prop. Now, if you apply torque to that, the prop will (hopefully) rotate around the center of the prop, meaning the two wheels will circle around the center. Now, instead imagine that you apply the torque around the axis on either wheel, one wheel would now circle the other... of course due to weight and reaction forces it might not stay fixed in air, but it should still rotate like that.

Torque is implement as two opposite forces acting on each side of the center of the prop, which translates to rotation. Now just moving those two opposite forces to an "arbitrary" position sounds to me like it would then introduce rotation around that position instead... ?

[Tolyzor]

Torque is implement as two opposite forces acting on each side of the center of the prop, which translates to rotation. Now just moving those two opposite forces to an "arbitrary" position sounds to me like it would then introduce rotation around that position instead... ?

In short, no, not quite.

I was pointing out that it wouldn't stay fixed in the air yeah, it would always move around due to the reaction forces*. This means as a function, applyOffsetTorque doesn't make sense, as it would still need to be complimented by applyForce to keep the axis you are applyOffsetTorque-ing around stationary every time its used, just like applyTorque currently needs(to complete the the task you want).

Axis tool your described system to the world and then applyTorque the system; the axis tool is doing the same job my described applyForce would.

Ah, and if you still don't believe me, understand that the "torque" we are talking about is actually a torque in the engineering sense rather than the physics sense - a couple (a pair of moments with no resultant force).

http://en.wikipedia.org/wiki/Couple_%28mechanics%29

Torque has special properties that moment does not have, in particular the property of being independent of reference point, as described below.

It is therefore impossible to have a couple which is offset.

*Reaction forces at the offset axis consist of the following, I think;

Centrifugal force; F = m * omega^2 * r (acting towards the centre of mass)
Inertia and rotational acceleration induced reaction force**; F = (I + m * r^2) * alpha / r (acting opposite to the tangential velocity of the centre of mass) - seeing as this reaction force doesn't act through the centre of mass, you'd actually have to use applyOffsetForce to negate it...

where,
I = moment of inertia about centre of mass
r = length from centre of mass to your axis
m = prop mass
omega = rotational velocity
alpha = rotational acceleration

**Disclaimer: derived in my head, could be errors

[vexx21322]

Thanks Divran, is there any way I can slow the movement? As in, if I set a certain variable it will move to my aim at a slower rate?

[Divran]

Thanks Divran, is there any way I can slow the movement? As in, if I set a certain variable it will move to my aim at a slower rate?

You can try changing the multipliers until it's slower, or you can use slerp.

@persist TargetQuat:quaternion Mul1 Mul2
if (first()) {
    TargetQuat = quat(E)
    Mul1 = 1000
    Mul2 = 20
}
TargetAngle = (owner():aimPos() - E:pos()):toAngle() + ang(90,0,0))
slerp(TargetQuat,quat(TargetAngle),0.03)
Torque = E:toLocal(rotationVector(TargetQuat/ quat(E))+E:pos())
E:applyTorque((Torque*Mul1-E:angVelVector()*Mul2)*E:inertia())

Untested!

Edit: Slerp is a way of smoothing a quat.

Edit2: It might have been TargetQuat = slerp(...) instead of only slerp(...). Don't remember.

[vexx21322]

Okay, that's like calculus and I'm only in trigonometry right now . Is there any way to apply something like that for holograms?.


and also. Say I wanted to make a prop fly with applyForce and aim with my aim(but not at what I aim at). Could I just use the Aim of a advance pod with above code?