Right now I'm working through the models one at a time ... there must have been something wrong with the plist or something because copying over another one removed the error.... note, copying over the contents did not, I had to copy the whole file.
The player anaconda turrets won't shoot at anything, but they do point at opponents - what did I miss? (Not tested )
Eric Walch wrote:Simon B wrote:The rear gun on the anaconda is requires the subent rotated 152deg about (1,0,0). Hence the quarternion is: (0.2419 0.9703 0.0000 0.0000).
However, the port gun requires the subent rotated -90 deg about (1,0,0) and then -30deg = +330deg about (0,0,1)... those rotations are:
Q1 = (1,-1,0,0) since cos(45) = sin(45) = 1/sqrt(2);
Q2 = (1,0,0,t) where t = sin(-15)/cos(-15) = -tan(15) = -0.26795
When you use the console you can use a lot of Oolites internal quaternion calculations.
Anyone used that console under a gnu/linux?
like:
Code: Select all
> new Quaternion([0, 1, 0, 0]).rotate([1,0,0], 152/180*Math.PI)
(-0.970296 + 0.241922i - 0j - 0k)
[/quote]
(0,1,0,0) is a 180deg rotation about x
(1,0,0) is x
152/180*math.PI = 152 degrees converted to radiens.
this next one is more like how I thought the console would work for this calculation.[quote]
new Quaternion([1, 0, 0, 0]).rotate([1,0,0], 152/180*Math.PI)
(0.241922 + 0.970296i - 0j - 0k)
This last is what you calculated.
Starting with (1,0,0,0) or zero degree rotation.
With your other calculation I got different results.
Code: Select all
> new Quaternion([1, 0, 0, 0]).rotate([1,0,0], -90/180*Math.PI).rotate([0,0,1], -30/180*Math.PI)
(0.683013 - 0.683013i - 0.183013j - 0.183013k)
But when I normalise your results I get the same result (only one different sign):
Code: Select all
> new Quaternion([1, -1, -0.26795, 0.26795]).normalize()
(0.683013 - 0.683013i - 0.183013j + 0.183013k)
And your quaternion is only valid for use after normalisation.
Please note that Oolite normalises the quarternons when it loads them. Also, the actual numbers are not what gives the rotation, but the relatioship between them. So (100,-100,0,0) is the same rotation as (1,-1,0,0). Either can be used. The math is simpler with normalised Qs.
That's why I can do:
Q = (cos(A),Rsin(A)) = (1, Rtan(A)) ... where R is the rotation vector and A is the half-angle.
The difference in sign is important, though, unless
all the elements change sign. It changes the direction of the rotation.
No need to use complex spreadsheets. The console is enough.
I'll agree that spreadsheets tend to over-complicate calculations that do not involve manipulating columns of figures (geometry, say) but the console
still needs me to know the rotation angle.
The octave/matlab thing I'm fiddling with finds the angle for you. The idea is to solve the issue Griff lamented - where you spend hours fiddling with the models in wings3D or whatever, to record the rotation-angle sets and
then multiplying quarternions.
If you have a one-step way to work out the angle and rotation axis you are set. It should be easy to convert the m-file script and add this function to the console.
.
Fabulous Fabulous work Simon - I bow down to your skill and dedication to the cause!
