General Question Burn Vector view in an MFD

[jedidia]

BTW: Jedida, you obviously got it now, no need to further explain it

I'm not quite certain about that, since I can't understand half the things you guys are talking about :lol:

Anyways, the alignement seems to work ok now, thanks for the help.

But now there's the other problem, which is getting the vector of the ship aligned with the target vector... I tried to derive an angle around the X axis and one around the Y axis for both the target vector and the pointing vector of the ship, and then substract them to see how far they're off. However, this seems to work *very* lousy, which I think has to do with the fact that one angle depends on the other... or somesuch.

So how would I correctly calculate the angular difference between the two vectors?

 

[Moach]

think of a rotation matrix as a way of representing the "motion" needed to "turn" a vector into "another"

excuse all the ""'s but that's the only way i can put what's going on into english...


for all effects - the application of a matrix is exactly the same as that of a quaternion - it "turns" things (vectors), how it does this, however, is where they differ....

well, but let's forget about quaternions for now, since orbiter uses matrices, we needn't busy ourselves with alternative methods, right?

perhaps the concept of matrices makes more sense for mathmaticians-turned-programmers, than to us programmers-fumbling-with-math....

to me, 2d rotations boils down to a simple formula (well two actually) - those are the ones closest to the bottom-right corner of Face's little graph (which is great BTW - i saved it)

in 3d, you don't have to worry much about the math itself ´cuz that's already programmed - you just need to know what a so-called "rotation matrix" represents and how to use it

in Martin's code, you can see matrices being multiplied together - this "combines" two rotations, resulting in a total amount - think of spinning a little ball, then thinking: ok, now it's spun, so this is "unrotated" now lets turn it some more - you'll end up with a final rotation with is a combination of the two:hmm:


vectors, likewise, can be rotated in the same way... i don't remember their exact names, but there are functions that will take a VECTOR3 value and rotate (multiply) it by the amount represented by the rotation


did this help at all?


**disclaimer: always take math advice from me with a grain of salt - there is a large chance i have no idea what the hell i'm talking about and might be giving you bad ideas... i try to help, anyways -

 

[Face]

But now there's the other problem, which is getting the vector of the ship aligned with the target vector... I tried to derive an angle around the X axis and one around the Y axis for both the target vector and the pointing vector of the ship, and then substract them to see how far they're off. However, this seems to work *very* lousy, which I think has to do with the fact that one angle depends on the other... or somesuch.

So how would I correctly calculate the angular difference between the two vectors?

Forget euler-angles for this job. The angle between two vectors is simply the acos of the dot-product of both normalized vectors. Every operation here is right in the toolset of Orbiter's API (and standard C++ math.h, of course):

VECTOR3 vVessel;
vessel->GlobalRot(_V(0,0,1), vVessel);
normalise(EclipticStarPos);
double angleRadian = acos ( dotp ( vVessel , EclipticStarPos ) );

regards,
Face

 

[jedidia]

erm... shouldn't I have two angles at least? I can't quite picture how to align two vectors with only one angle...

 

[Moach]

that's what the "cross vector" is for - it is the axis which is simulatanesouly perpendicular to both vectors - and best of all - it's one function call away (someone please specify the name)

looking along the cross vector, things suddenly become very 2D... so a single angle is more than enough to align any two vectors:thumbup:

 

[Face]

that's what the "cross vector" is for - it is the axis which is simulatanesouly perpendicular to both vectors - and best of all - it's one function call away (someone please specify the name)

looking along the cross vector, things suddenly become very 2D... so a single angle is more than enough to align any two vectors:thumbup:

VECTOR3 vVesselUp;
vessel->GlobalRot(_V(0,1,0), vVesselUp);
double angleRollRadian = acos ( dotp ( vVesselUp , crossp (vVessel, EclipticStarPos) ) );

If you have the typical burn vector view, this is the angle where your pointer would be around the origin. The previous angle is the distance of your pointer from the origin (you'd have to map it to a distance, of course).

 

[jedidia]

Ok, I think I got that, thanks a lot. Unfortunately I'm leaving for a four days trip in an hour, it might be a while until I can implement it. I'll notify you of the result... which I hope will be a bit more tangible than what I got so far :lol:

 

[jedidia]

ok, back from one trip, already set up for the next, but a few hours to code in between.

The whole thing works better than it did before, but still not very good yet. My vector doesn't point to the targeted star, and the deviation from the targeted star to the vector isn't constant (it is of course for the same star, but I get another deviation when targetting another star). Still, as far as I can tell so far, the deviation is about 1.1 radians, moving between 1.2 and 1 radians depending on the star (Eta Cassiopaiae has 1.1, Polaris 1.065, Arcturus 1.183, to name a few). That's what my angle between the two vectors is when I am visually aligned with the stars. Here's what my code looks like so far:

        vessel->GlobalRot(_V(0,0,1), VesVec);
        vessel->GetGlobalPos(VesPos);
        vessel->GetGlobalOrientation(VesRot);

//defining the angles provided by martin
        double phi = 90.02 / 57.2957;
        double theta = 60.18 / 57.2957;
        double lambda = 173.6 / 57.2957;    

//rotating star from the galactic frame to the ecliptic, as suggested by face
        double sint = sin(theta), cost = cos(theta);
        double sinp = sin(phi), cosp = cos(phi);
        double sinl = sin(lambda), cosl = cos(lambda);
        MATRIX3 ecl2gal =  mul(mul(_M(cosl,0,sinl, 0,1,0, -sinl,0,cosl),
                                   _M(1,0,0, 0,cost,sint, 0,-sint,cost)),
                                   _M(cosp,0,sinp, 0,1,0, -sinp,0,cosp));
        VECTOR3 EclipticStarPos = tmul (ecl2gal, GalacticStarPos);        


//calculating the actual vector from the ships position (received by vessel->getglobalpos) to the targeted star and calculating the angle between the vectors as suggested by Face
        VECTOR3 VesselToTarget = EclipticStarPos - VesPos;
        normalise(VesselToTarget);
        double angleRadian = acos ( dotp ( VesVec , VesselToTarget ) );

        VECTOR3 vVesselUp;
        vessel->GlobalRot(_V(0,1,0), vVesselUp);
        double angleRollRadian = acos ( dotp ( vVesselUp , crossp (VesVec, VesselToTarget) ) );

Maybe I should add a bit of Information about the coordinate system I'm converting from. My coordinate system has the center of the galaxy as 0/0/0, with the sun lying at (about) 0/-7982/20 (units in parsec). The vector from the sun to the targeted star gets calculated by simply substracting their galactic positions and then being converted to meters (since I assume that's what orbiters coordinate system is in, but since we're working purely with angles here it shouldn't matter anyways, or does it?), so a star towards the center and counter-spinwards has x+y+, the direction towards the plane is z- and away from the plane is z+ (towards the galactic north pole).
This vector gets then rotated into the ecliptic frame as shown above. I still have the feeling that the problem lies somewhere in that conversion, since I don't really know which galactic reference Martin chose as a basis for his angles...

 

[jedidia]

Back after a few days without internet connection, looks like noone has a guess of what's going wrong in my code. Pitty. I hope I can figure it out...

 

[Face]

Back after a few days without internet connection, looks like noone has a guess of what's going wrong in my code. Pitty. I hope I can figure it out...

Ups... sorry, I totally forgot to answer here...

Basically, I think you shouldn't convert your galactic units to Orbiter's units, because that would introduce numerical artifacts. As long as you are using eucledian metric, you should be fine with calculating the distance (==direction) vector from star to sol and rotating that vector instead of the actual star position.
This way you can deal with your "galactic accuracy" right down to the direction vector. Forget about the small deviation from different intra-sol positions. Let me take a stab on your code:

//calculating galactic star direction vector - use parsecs here
    VECTOR3 GalacticStarDirection = GalacticTargetStarPosition - GalacticSourceStarPosition;
    normalise(GalacticStarDirection);

//defining the angles provided by martin
        double phi = 90.02 / 57.2957;
        double theta = 60.18 / 57.2957;
        double lambda = 173.6 / 57.2957;    

//rotating star from the galactic frame to the ecliptic
        double sint = sin(theta), cost = cos(theta);
        double sinp = sin(phi), cosp = cos(phi);
        double sinl = sin(lambda), cosl = cos(lambda);
        MATRIX3 ecl2gal =  mul(mul(_M(cosl,0,sinl, 0,1,0, -sinl,0,cosl),
                                   _M(1,0,0, 0,cost,sint, 0,-sint,cost)),
                                   _M(cosp,0,sinp, 0,1,0, -sinp,0,cosp));
        VECTOR3 EclipticStarDirection = tmul (ecl2gal, GalacticStarDirection);        


//calculating the angles between the vectors
        vessel->GlobalRot(_V(0,0,1), VesVec);
        double angleRadian = acos ( dotp ( VesVec , EclipticStarDirection ) );

        VECTOR3 vVesselUp;
        vessel->GlobalRot(_V(0,1,0), vVesselUp);
        double angleRollRadian = acos ( dotp ( vVesselUp , crossp (VesVec, EclipticStarDirection) ) );

regards,
Face

 

[jedidia]

If I see that right, the only changes you made in the code is that you get the vector from star to star directly (instead of ship to star), don't convert it and normalise it before the rotation. I adapted these changes, but get pretty much the same result. However, I'm beginning to doubt the accuracy of my galactic map. After all, there was a Euler transformation involved in creating the galactic positions too. I kind of checked my positions with celestia, but i's still possible that they are aligned correctly to each other, but not to the galactic frame.

For example, when I currently target Arcturus, the coordinates relative to the sun (in the above explained coordinate system) are X-1.04, Y 3.87, Z 10.51, so the star lies almost in the direction of the galactic north pole, while in orbiter the star lies rather close to the ecliptic, which as far as I know isn't almost at a right angle to the galactic plane... possibly my stellar positions are rotated wrongly in my map?

Edit: forgett what I just wrote above, I checked the position of Beta Com in my map, and it's pretty much where it has to be, and is even pretty close to Arcturus, so the positions of the stars in my Map are ok after all ( I really didn't know that the ecliptic is so steeply aligned to the plane). It intensifies my questions to why I'm still about 1.1 radians off in Orbiter. Is it possible that one of our roatations goes the wrong way round?

The name of the matrix, ecl2gal, seems to indicate that this rotation is supposed to be used to rotate from ecliptic frame into galactic, but what I'm trying to do is the other way round... Martin said something about the inverse of the one being the transpose of the other, but I'll be damned if I know what that means...

 

[Face]

If I see that right, the only changes you made in the code is that you get the vector from star to star directly (instead of ship to star), don't convert it and normalise it before the rotation.

Indeed. If you really converted the huge distances to meters, it is possible for numerical accuracy to weaken the results. This is why I proposed this difference calculation in parsec units first. The normalisation is for getting a unit-free direction vector.

It intensifies my questions to why I'm still about 1.1 radians off in Orbiter. Is it possible that one of our roatations goes the wrong way round?

Very possible, I never checked those angles.

The name of the matrix, ecl2gal, seems to indicate that this rotation is supposed to be used to rotate from ecliptic frame into galactic, but what I'm trying to do is the other way round... Martin said something about the inverse of the one being the transpose of the other, but I'll be damned if I know what that means...

Yes, the matrix is for converting ecliptic to galactic coordinates, but the tmul instead of the mul function is using the matrix transposed and therefore inverted, so you should have a galactic to ecliptic convertion.

I am pretty sure that the angles are wrong for your galactic frame...

regards,
Face

 

[jedidia]

---------- Post added 07-31-10 at 11:03 AM ---------- Previous post was 07-30-10 at 07:29 PM ----------

It WOOOOOOOOOORKS!!!!!

:woohoo::woohoo::jiggy::hail:

sorry for the emotional fallout, but after all the trouble with this I am VERY happy to got it to work. Finally!

in short, there were two major problems that messed it up all the time. First was that the axis perpendicular to the ecliptic in Orbiter is the Y-Axis, instead of the expected Z-axis, so I had to switch the Z and Y coordinates of my position vectors. The terrible Irony is that actually in my starmap, for the sake of the 3d engine, these coordinates are ALSO switched, so if I wouldn't have switched them back to proper galactic coordinates before the rotation, I never would have noticed that one.

The second one was that Lambda is 90 degrees off when converting from my galactic frame (i.e. what the ecliptic assumes as the galactic X axis is actually the Y axis in my map). Urgh! Thanks a lot to everyone that tried to help me out of this mess (especially face, once again. You'll get a Planet named after you once I get to implement procedural starports!), it really WAS helping. I finally arrived at the correct solution after reading through this thread about 10 times, everytime understanding a bit more of what's going on!

 

[Face]

It WOOOOOOOOOORKS!!!!!

Hurray!

Thanks a lot to everyone that tried to help me out of this mess (especially face, once again. You'll get a Planet named after you once I get to implement procedural starports!), it really WAS helping.

You're welcome. Would be an honour to have a planet named after me