API Question LocalRot??

[jedidia]

There's a very handy function to get the global orientation from a rotational vector relative to a vessel.

However, there doesn't seem to be an inverse of that.

Looking at the old IMS, it just used Local2Global and then Global2Local on the other vessel, which seems to work. But reading the docummentation for GlobalRot, it explicitly states that Local2Global shouldn't be used to transform rotational vectors, only positions. I assume that this is also true for the inverse operation, Global2Local.

So now I'm wondering if there's some inverse of GlobalRot, or if the transformation of rotational vectors with Local2Global doesn't pose a problem if the vector is transformed back with Global2Local and not actually used in the global context, or if there's another method I should use?

 

[ADSWNJ]

tmul() the GetRotationMatrix()?

 

[jedidia]

Thanks. I don't understand 3-dimensional trigonometry, so it is difficult for me to arrive at such conclusions myself...

 

[Hielor]

I do something similar at http://www.orbiter-forum.com/showthread.php?t=5072 , although there's a lot of math there. This other post is more directly relevant:

This code is excerpted from http://www.orbiter-forum.com/showthread.php?t=5072:

planet = ves->GetSurfaceRef();
ves->GetGlobalPos(glob_vpos);
ves->GetRelativeVel(planet, glob_rvel);
ves->Global2Local((glob_rvel + glob_vpos), loc_rvel);

You'd probably then want to normalize(loc_rvel) for passing to an autopilot.

The addition of the global position glob_vpos to the velocity vector is necessary because Global2Local converts positions, not velocities, so you need to translate the velocity vector by the vessel's position so it'll be relative to the ship's velocity.

Make sense?

The above was done for a velocity vector, but the same concept holds true for any non-positional vector. So, a generic LocalRot function could be:

// Rotates a non-position (velocity, rotational, etc) vector from the global
// to the local frame.  For position vectors (IE, actual position 
// coordinates) use Global2Local directly.
VECTOR3 LocalRot(VESSEL *ves, VECTOR3 glob_vec)
{
  VECTOR3 loc_vec, glob_vpos;
  
  ves->GetGlobalPos(glob_vpos);
  ves->Global2Local((glob_vec + glob_vpos), loc_vec);
 
  return loc_vec;
}

Disclaimer: I haven't actually tested this particular variation, so you may need to modify it slightly. The algorithm should be correct, though.

 

[ADSWNJ]

I've had a real crash course in understanding vectors, translating coordinate systems, applying directions, etc, in my long quest to deliver my Rendezvous Orientation MFD+HUD. For example, to orient relative to the target port, I get the target port offset (from the target vessel origin), then apply the direction vector (normal out from the port), and rotation vector (somewhere on the port's plane defining local "up"). From this, I can convert the port, direction and rotation into global coords, then back to local coords in MY ship, then apply MY port offset, then apply MY port's rotation matrix to define those three remote points into my port's coordinate system. From that, I can determine the relative vectors for translation and orientation to align to the port. And that's 1% of the work .

So ... you have vectors in VECTOR3, and 3x3 matrices in MATRIX3. When building your own rotation matrix, you think about applying a pitch, yaw and roll matrix one by one. So V' = M1 * M2 * M3 * V. You can multiply matrices together to make this into V' = M * V. In Orbiter terms, this is VECTOR3 V-prime = mul(M,V). The inverse is V = tmul(M,V-prime). (Tmul being a transpose-multiplication).

It takes a while to debug-step through the code to get your head around what actually is going on, and a ton of simple use-cases to lock in the right transformations, but the result is satisfying. Watch out for RV Orientation release inside a couple of weeks now, time-willing.

 

[Hielor]

Alternately, you could just ignore matrices completely and do it the way I did it

 

[Artlav]

I don't understand 3-dimensional trigonometry, so it is difficult for me to arrive at such conclusions myself...

Your best bet is to just grind through, and understand the math. Vectors are not hard, and a human brain is equipped with the right hardware to understand them intuitively.

If you don't bother to understand, then each time you'd need to do one transformation or the other it would be like trying to program a calculator by making lookup tables for every number and operation.

If bland symbols don't compute for you, then look for visual demonstrations.
There are many applets on the web, that would allow you to play with things like cross product, or matrix vector rotation. (i.e. http://mathlets.org/daimp/MatrixVector.html , http://mathinsight.org/cross_product , in general: http://www.falstad.com/mathphysics.html , http://mathlets.org/mathlets/ , http://mathinsight.org/thread/vector_algebra#vectors )
Or, you can just make such programs on your own - visualize the result of each and every basic operation, and try it out.

Simulate, just like Orbiter gives you a feel for orbital mechanics.

 

[jedidia]

Your best bet is to just grind through, and understand the math.

Tried that once, somehow it seems I don't get it without a proper tutor. I will study the links you sent me, though, hope they help a bit.

 

[ADSWNJ]

Alternately, you could just ignore matrices completely and do it the way I did it

Absolutely, when you are doing a standard conversion. But as soon as you want to do your own rotation, you need to understand matrices and mul() and tmul(). I spent quite a while thinking through the three axis rotations, thinking what kind of matrix would convert say {0,-1,0} to {0,0,1}, etc. It's satisfying to sort this out, and it arms you not to worry about it when you don't have a direct function.