Celestia Forums

Is this a bug?
Greetings,

Am new to the forums but not to Celestia. FANTASTIC PROGRAM! I run version 1.4.1 on XP and Snow Leopard desktops, and 1.6.0 on a Vista laptop.

One of my main interests is dynamics, and I am wondering if the following behavior is a bug or the intended result of the frame definitions that changed in 1.6.0.

In 1.4.1, when you were "following" Earth and then "locked another planet to it, Celestia's display maintained Earth's orientation until you changed it. Here's a 1.4.1 link to demonstrate:

cel://PhaseLock/Sol:Earth/Sol:Jupiter/2 ... -107493374

But in 1.6.0, when you "follow" Earth and then "lock" another planet to it, the orientation "flips" at different times of year, turning everything upside down for awhile. The times and speed of the "flips" seem to happen at different times and at different rates for each planet locked to Earth. For example, Jupiter "flips" in 2010 July (as it moves through 0? geocentric declination) and Nov (when it's nowhere near 0?); 2011 Aug and Dec, 2012 Oct, 2013 January etc. Saturn does so in 2010 Jan and May, 2011 Jan and June etc. And Mercury is "all over the place." Is this related to their synodic periods? Using Jupiter, here's a 1.6.0 link to demonstrate:

cel://PhaseLock/Sol:Earth/Sol:Jupiter/2 ... rc=0&ver=3

If this is the intended behavior in 1.6.0, is there any way to add the old behavior in a future version of Celestia? It was quite useful to display retrograde planet motions and if you want to compare planet rotations side-by-side (using narrow FOV's).

Many thanks,
VikingTechJPL

VikingTechJPL wrote:Is this a bug?
Greetings,

.
.

But in 1.6.0, when you "follow" Earth and then "lock" another planet to it, the orientation "flips" at different times of year, turning everything upside down for awhile. The times and speed of the "flips" seem to happen at different times and at different rates for each planet locked to Earth. For example, Jupiter "flips" in 2010 July (as it moves through 0? geocentric declination) and Nov (when it's nowhere near 0?); 2011 Aug and Dec, 2012 Oct, 2013 January etc. Saturn does so in 2010 Jan and May, 2011 Jan and June etc. And Mercury is "all over the place." Is this related to their synodic periods? Using Jupiter, here's a 1.6.0 link to demonstrate:

.
.

Many thanks,
VikingTechJPL

I do not know if that is a bug, but I found it indirectly during the developing of a LUA plug-in for the Moon's bright limb (Sun position). The Sun's position compass "jump" its rotation through the Moon's equatorial plane approximatively in July and in November.

The definition of the phase lock coordinate system changed in 1.6.0. In both cases, the coordinate system is calculated from two direction vectors, the primary and the secondary. The x-axis is set equal to the primary direction, the z-axis is perpendicular to both the primary and secondary, and y-axis is perpendicular to both the x- and z-axes. The primary vector didn't change: in all Celestia versions, it's the direction from the followed object to the target object. The secondary vector did change: in 1.6.0, it's the relative velocity of the followed and target objects, and pre-1.6.0 it's the rotation axis of the followed object.

There are advantages and disadvantages to both choices. The velocity vector works well when the followed object is orbiting the target--stable orbits are nearly planar, and thus the 'up' direction perpendicular to velocity and the position vector is nearly constant. In other situations, the 'up' direction can flip as the followed object overtakes the target.

Using the rotation axis for the secondary vector worked reasonably well provided that the rotation was uniform. When it wasn't--such as for a tumbling asteroid or spacecraft aiming at different targets--then the old phase lock coordinate system would flip and spin in all sorts of undesirable ways. It was particularly bad for spacecraft, where the rotation axis could change instantaneously when pointing.

We probably need to rethink the definition of the phase lock coordinate system. It should be stable, with no extra twists and flips. One easy choice is to use a constant vector as the secondary. This works fine as long as it's not identical to the primary vector, though that's a problem with any choice of secondary vector. We'd need some fallback when the vectors are exactly aligned, and switching to the fallback would make the view twist instantaneously. However, in day-to-day usage without specially constructed test cases, the fallback would never be used, as the chance of two double precision vectors being almost identically is tiny.

--Chris

I have encountered this issue when making movies of spacecraft fly bys. In my movie of Jupiter Europa Orbiter flybys of Io:

http://www.youtube.com/watch?v=FRpSgmgfCes

You can see little stutter rotations of Io, which is me trying counter act the flips.

Chris,

I see what you mean about the problem of using the "rotation axis" with non-uniform rotations. It must cause a lot of "dancing around" in some cases. YEOWW!

For planets, I definitely favor using the "followed" object's "rotation-axis" as the secondary vector, because it allows the display of some of the more fundamental planetary dynamics—especially when comparing one planet to another. In some ways, it might be desirable to be able to explicitly choose Celestial North, Ecliptic North, Galactic North etc. as secondary (or even any fixed direction for that matter), as this would help give users an immediate "sense of direction". (Could users be allowed to simply choose a geocentric RA and Declination? Perhaps that's getting too complicated.) But secondaries relative to non-uniform moving-object-frames reveal a lot too, so I wouldn't want to lose that capability.

In scripts, it is a lot less problemmatical, of course, because the "lookat()" function is available. And I've used that when migrating some scripts from 1.4.1 to 1.6.0. But, when you use an increasing number of multiple views, "lookat()" definitely starts slowing things down. Moreover, it would be useful to be able to somehow "wrap" a user-chosen "up vector" or a non-uniform secondary into a cel//url somehow.

Anyway, thanks for the insight.

--Gary

Chris,

Just a thought. When you use the velocity vector as your secondary, isn't the change of velocity (going through minima and maxima) the problem? If so, could you normalize the velocity vector before applying it as the secondary? If it's magnitude is always equal to 1, would this eliminate the flipping?

--Gary

VikingTechJPL wrote:Chris,

Just a thought. When you use the velocity vector as your secondary, isn't the change of velocity (going through minima and maxima) the problem? If so, could you normalize the velocity vector before applying it as the secondary? If it's magnitude is always equal to 1, would this eliminate the flipping?

All of the vectors get normalized in the construction of the coordinate system. Otherwise, we'd have much worse problems than flipping and twisting of the camera. I think using a constant vector as the secondary is the right approach. It's an easy thing to code and test, so I'll try it out as soon as I have a spare hour.

--Chris

chris wrote:

VikingTechJPL wrote:Chris,

Just a thought. When you use the velocity vector as your secondary, isn't the change of velocity (going through minima and maxima) the problem? If so, could you normalize the velocity vector before applying it as the secondary? If it's magnitude is always equal to 1, would this eliminate the flipping?

All of the vectors get normalized in the construction of the coordinate system. Otherwise, we'd have much worse problems than flipping and twisting of the camera. I think using a constant vector as the secondary is the right approach. It's an easy thing to code and test, so I'll try it out as soon as I have a spare hour.

--Chris

From a theoretical physicist perspective, the frame definition should involve a vector that is known to be approximately conserved in time, like e.g. the angular momentum vector in case of a circular motion (<-> rotation axis).

See e.g my Wiki-friend:
http://en.wikipedia.org/wiki/Constant_of_motion

In simple cases, this matches a constant vector approach, of course, but such so-called "angle-action" variables furnish a more sensible physics-based criterion than the mere requirement of constancy. Even for relatively complex motion, the angular momentum vector can be approximately computed without much effort.

My "friend" Wiki has a page on Angle-Action coordinates, for example.
http://en.wikipedia.org/wiki/Action-angle_coordinates

Fridger

Chris wrote:
All of the vectors get normalized in the construction of the coordinate system. Otherwise, we'd have much worse problems than flipping and twisting of the camera.

Chris,

Please forgive the cobwebs of Math-and-Physics-class-memories that have not been accessed in over three decades. Is it the magnitude of the velocity vector that's causing the "flip" or is it the direction, or both? I'm trying to visualize.

Fridger wrote:
From a theoretical physicist perspective, the frame definition should involve a vector that is known to be approximately conserved in time, like e.g. the angular momentum vector in case of a circular motion (<-> rotation axis).

Fridger,

Is angular momentum conserved in the non-uniform rotation that Chris was concerned about?

Sign me,
Cobweb Impaired

VikingTechJPL wrote:

Fridger wrote:
From a theoretical physicist perspective, the frame definition should involve a vector that is known to be approximately conserved in time, like e.g. the angular momentum vector in case of a circular motion (<-> rotation axis).

Fridger,

Is angular momentum conserved in the non-uniform rotation that Chris was concerned about?

Sign me,
Cobweb Impaired

Gary,

let me refer you to a nice and compact answer about angular-momentum (AM) conservation once more in Wiki:

http://en.wikipedia.org/wiki/Angular_momentum

Notably, see the section about AM conservation further down. If you have some remaining questions, I'd be happy to reply. Total AM is conserved like total energy is, provided that the system under consideration is a closed one. The property of closure can usually be achieved by sufficiently "enlarging" the system under consideration. Yet, in the context of this thread, an approximately conserved AM vector is presumably sufficient.

Suppose you have not one, but two or several (celestial) bodies that interact somehow. Then using only the angular momentum [tex]\vec{p}\times \vec{x}[/tex] of one of the bodies for the frame definition may be inappropriate, since only the total angular momentum is (approximately) conserved.


Fridger

Fridger,

Thanks for the quick reply. Though I'm still dusting off the grey matter and wading through the cobwebs, perhaps I should have elaborated a bit more in my question.

As Chris wrote,

Using the rotation axis for the secondary vector worked reasonably well provided that the rotation was uniform. When it wasn't--such as for a tumbling asteroid or spacecraft aiming at different targets--then the old phase lock coordinate system would flip and spin in all sorts of undesirable ways. It was particularly bad for spacecraft, where the rotation axis could change instantaneously when pointing.

If there is non-uniform rotation or a sudden change of rotation axis, then rotational invariance is violated. Moment of inertia AND linear momentum might both change; at least one would have to (or "AngularMomentum = MomentOfInertia x AngularVelocity" would be violated). For a planet and a spacecraft, the total change in momentum would be minimal, but when "phase-locking" two spacecraft (especially if of similar masses), it might not be. This would seem to imply that using the angular momentum vector would not be a completely suitable choice.

Chris wrote in his last post:

I think using a constant vector as the secondary is the right approach.

And it would be quite useful to be able to choose from a number of constant vectors, or define one ourselves.

Thanks for your insights,

Sign Me,
Still Wading Through the Cobwebs

Gary,

usually both rotational invariance and energy conservation are not really violated, if considered "at large" (closed system), and the possibilities of a transfer of mechanical energy/torque into other forms (heat etc..) are taken into account, along with the familiar "actio = reactio" principle.

An example would be, if a spacecraft suddenly starts its engines for a while, thereby bringing it into a tumbling state by adding EXTERNAL torque into the system via termodynamical effects (engine firing)...

But you certainly also know about those amazing sudden changes of rotational speed that people can effect just BECAUSE angular momentum is conserved. E.g. when skydiving out of a plane or from a high springboard over a pool! The trick is to change from a crouching to an extended body position or vice versa during the jump,...In such a "closed environment" the suddenly changing body extensions MUST be compensated by an instantaneous change in rotational speed to warrant angular momentum conservation. For such (closed) non-uniform rotations, the angular momentum vector is certainly a suitable "body frame vector".

Unfortunately, if all complex cases (firing spacecraft engines etc) are to be accounted for, a simple and entirely satisfactory (astro-)mechanical frame prescription seems quite hard to me. Certainly, it might be worth trying a constant reference vector, but from a physics point of view such a choice seems rather arbitrary/unmotivated to me.

Fridger