Problem with Celestia Rotation model

[Chuft-Captain]

Hi folks,

I wonder if anyone can shed some light on this problem....

I am trying to orientate a CMOD model using the FixedRotation command.
The model is such that when displayed in Celestia using the following code, it is vertical (with Y-axis pointing up relative to a given reference object).

Code: Select all

FixedRotation
   {
      Inclination      0   # rotate about the X-axis
      AscendingNode    0   # rotate about the Y-axis
      MeridianAngle    0   # rotate about the Z-axis
   }


The following seems to correctly rotate it about the X-axis as expected (ie. model flips forward/backward by 45 degrees)

Code: Select all

FixedRotation
   {
      Inclination      45   # rotate about the X-axis
      AscendingNode    0   # rotate about the Y-axis
      MeridianAngle    0   # rotate about the Z-axis
   }


and the following also seems to work as expected (rotating left/right by 45 degrees)

Code: Select all

FixedRotation
   {
      Inclination      0   # rotate about the X-axis
      AscendingNode    0   # rotate about the Y-axis
      MeridianAngle    45   # rotate about the Z-axis
   }


however, I cannot get it to rotate about the Y-axis in the same way as expected. The following code seems to place it into exactly the same orientation as the Z-axis version above.

Code: Select all

FixedRotation
   {
      Inclination      0   # rotate about the X-axis
      AscendingNode    45   # rotate about the Y-axis
      MeridianAngle    0   # rotate about the Z-axis
   }


Is this a bug, or is there an error in my assumptions about how this should work?

Cheers
CC

[selden]

Changing an object's rotational Ascending Node is not the same as rotating the object around an axis.

The Ascending Node is the angle to one of the two points where an object's current Equatorial plane crosses the Equatorial plane that it would have had if its axis weren't inclined -- the point where the object's rotation is moving a point on the object's surface "upward" (ascending). (The other point is the Descending Node.)

If the object's axis isn't inclined, changing the object's Ascending Node has the same effect on its orientation as changing its Meridian Angle.

p.s. another way of looking at it might be to consider a precessing object -- one which has its axis slowly changing directions with time, as the Earth's axis does. The Ascending node effectively specifies where the axis is currently located in that precessional circle. Of course, with a Fixed Rotation, the axis isn't actually moving.

[Chuft-Captain]

Thanks Selden,

I thought it might be something along those lines, given that Celestia's primary purpose is the positioning and orientation of Celestial bodies.
I imagine however, that there should be a way to achieve any orientation you want through a combination of 2 or more of the 3 values, but understanding how the, I guess you'd call it,... "polar" notation relates to the X,Y,Z frame is the hurdle I guess.
(It would be nice if there was a syntax available that obfuscated this.)

Cheers
CC

[t00fri]

Thanks Selden,

I thought it might be something along those lines, given that Celestia's primary purpose is the positioning and orientation of Celestial bodies.
I imagine however, that there should be a way to achieve any orientation you want through a combination of 2 or more of the 3 values, but understanding how the, I guess you'd call it,... "polar" notation relates to the X,Y,Z frame is the hurdle I guess.
(It would be nice if there was a syntax available that obfuscated this.)

Cheers
CC

CC,

as we know since a long time from Leonhard Euler, it takes exactly 3 angles, the famous Euler angles, to effect an arbitrary rotation of a solid body (or its local coordinate frame) relative to a given frame. The geometrical visualization of the 3 Euler angles is very intuitive, indeed, once you have understood their meaning. It can't be done simpler. Here is a nice sequence of respective drawings from Wolfram Math World that should make the issue crystal clear.

http://mathworld.wolfram.com/EulerAngles.html

One starts with a rotation about the z-axis, which rotates the x and y axes to x' and y'. Next you rotate around the x' axis (<-> the former x-axis), which rotates the former z-axis into z'. Finally, you rotate around z'. Done!

Both Astronomers and Celestia use essentially the Euler angles. That's also how I have e.g. spacially oriented my 10000+ NGC/IC galaxies in Celestia... The "axis-angle" representation of Quaternions is a very handy tool in this context.

Fridger

[Fenerit]

This thread is fantastic. Reading it, there is the sensation of a "walkaround" about what each one want to draw up from the Chuft's request respect to what Chuft then want presumably to achieve, in my opinion.

[Chuft-Captain]

Hi guys,

The model (3ds version) looks like this in Anim8tor:

model in Anim8tor.jpg

In Celestia, Abramson is facing directly south as in this picture:

South at top of screen.jpg

All that I'm trying to do is to rotate him 45degrees anti-clockwise when seen from above,
so that he's roughly facing the comet in the South-East ie. with a view of The Scorpion constellation.

[Chuft-Captain]

OK,

I managed to come up with a solution by changing the Primary Axis in the following Bodyframe definition from "-y" to "-z", placing the model initially in a face down position (head towards Soouth at top of screen).

Code: Select all

   BodyFrame
   {
      TwoVector
      {
         Center   "Sol/Earth/Bariloche"
         Primary
         {
            Axis "-y"
            RelativePosition { Target "Sol/Earth" }
         }
         Secondary
         {
            Axis "x"
            RelativeVelocity { Target "Sol/Earth" }
         }
      }
   }
   
   FixedRotation
   {
      Inclination    0   
      AscendingNode    0   
      MeridianAngle    0   
   }
}


It was then possible to place him upright using a 90 rotation about the "x" axis, followed by the desired 45deg rotation about the "Y" axis (which is now vertical) to face him towards the southeast.

Clearly there's much I still don't understand about the two-vector syntax. It seems that you need to pick carefully the axes which you choose for Primary and Secondary with a view to the rotations you may want to do.
Anyway, the final version of the Bodyframe and Rotation code looks like this:

Code: Select all

   BodyFrame
   {
      TwoVector
      {
         Center   "Sol/Earth/Bariloche"
         Primary
         {
            Axis "-z"
            RelativePosition { Target "Sol/Earth" }
         }
         Secondary
         {
            Axis "x"
            RelativeVelocity { Target "Sol/Earth" }
         }
      }
   }
   
   FixedRotation
   {
      Inclination    90      # stand him up (X-axis)   
      AscendingNode    45      # turn 45deg (Y-axis) to face the south-east
      MeridianAngle    0   
   }


... and looks like this:

solved-above+comet.jpg

Thanks for the advice.
CC

PS. Any further explanations are welcome (even though I've muddled out a solution), as the whole point of this is for me to gain a better understanding of how these syntax's interact for future reference.
For example, there may well be a far simpler way to handle this scenario than with a two-vector. (eg. SurfaceObject perhaps??? )

Note that the referenced Parent/Center object is:

Code: Select all

ReferencePoint "Bariloche" "Sol/Earth"
{
    LongLat [ -71 -41 1.000 ]
    Size 20
    Type "TA"
}


[selden]

Knowing what you want to accomplish is indeed necessary in order to use TwoVector appropriately. I often use it when an object is composed of multiple Meshes with complex interactions.

The SurfaceObject prefix can greatly simplify the orientation of objects on the surface of a spherical body. It aligns an object's Z axis with the local vertical, so an SSC can be significantly simplified, if that's one of your goals, by using appropriate orientations in the initial design a 3D object.