Celestia Forums

What are the advantages of 'chase' mode? What is this viewing mode suited to better than other modes?

The choice of a coordinate frame when viewing into or travelling through space depends on what I want to keep invariant (sorry for that word, I'm physicist ). In chase mode this is firstly the direction of motion of the observed body. But secondly? (Since I asked that question in this forum, I know what it is now.)

Every frame is basically given by two linearly independent vectors (not necessarily orthogonal). Chase mode takes its vectors from two different phenomena concerning a celestial body: the orbit and its own rotation. One frame vector (orbit velocity) is taken from the body's orbit, the other one is its spin vector. I don't see any advantages of this combination.

A more straightforward (imho) setup of a frame, which uses the orbit velocity as a first frame vector, too, could use the normal vector of the orbit plane (= vector of angular momentum) as a second frame vector. So both frame vectors are derived from the same phenomenon, which gives the frame a more fundamental meaning.

If we would watch the Earth's motion (e.g.) in this frame we'd see the Earth's axis 'precede'. In chase mode we see it oscillate in a plane. The motion of background stars in chase mode may be confusing somehow (watch Uranus in this mode!); if we substitute the second axis by the orbit plane normal vector, this makes the background stars rotate smoothly.

I know, coordinate frames are a top issue among Celestia's insiders and therefore will have been discussed widely, including chase mode. I don't want to criticize anything. I only, as always, would like to understand why things are as they are.

lidocorc

lidocorc wrote:What are the advantages of 'chase' mode? What is this viewing mode suited to better than other modes?

The choice of a coordinate frame when viewing into or travelling through space depends on what I want to keep invariant (sorry for that word, I'm physicist ). In chase mode this is firstly the direction of motion of the observed body. But secondly? (Since I asked that question in this forum, I know what it is now.)

Every frame is basically given by two linearly independent vectors (not necessarily orthogonal). Chase mode takes its vectors from two different phenomena concerning a celestial body: the orbit and its own rotation. One frame vector (orbit velocity) is taken from the body's orbit, the other one is its spin vector. I don't see any advantages of this combination.

A more straightforward (imho) setup of a frame, which uses the orbit velocity as a first frame vector, too, could use the normal vector of the orbit plane (= vector of angular momentum) as a second frame vector. So both frame vectors are derived from the same phenomenon, which gives the frame a more fundamental meaning.

If we would watch the Earth's motion (e.g.) in this frame we'd see the Earth's axis 'precede'. In chase mode we see it oscillate in a plane. The motion of background stars in chase mode may be confusing somehow (watch Uranus in this mode!); if we substitute the second axis by the orbit plane normal vector, this makes the background stars rotate smoothly.

I know, coordinate frames are a top issue among Celestia's insiders and therefore will have been discussed widely, including chase mode. I don't want to criticize anything. I only, as always, would like to understand why things are as they are.

It's interesting that you should mention this. I'm nearly finished with a complete rewrite of the observer frame code and was contemplating making this very change to chase mode, and also redefining phase lock mode to use the velocity vector as as the second frame vector. The reason that these modes are defined the way they are right now is simply because I was rather naive about coordinate frames when I wrote the code five years ago. It's certainly not the most sensible definition.

The potential problem with redefining two of Celestia's frames is that some scripts could break as a result. I call this a 'potential' problem because I'd be a little surprised if anyone has actually written scripts that would be sensitive to the change.

--Chris

Thank you for your reply, Chris.

chris wrote:I'm nearly finished with a complete rewrite of the observer frame code and was contemplating making this very change to chase mode, and also redefining phase lock mode to use the velocity vector as as the second frame vector.

I'm glad that you are going to change these modes in a coming version. I think, observing in these modified modes will give users a better understanding of what they see.

The following two pictures refer to your explanation. They show a central body C and a satellite S with its orbit. The first picture illustrates the new chase mode frame: x = orbit velocity, z = orbit plane normal vector. y completes the frame. In the second picture the new phase lock mode frame is shown. The chosen target object be the graviational centre C (as an example). You describe the frame in a different way, but it means the same: The cross product of velocity and radius vector is vector z. (This is in fact the practical way to determine vector z, since an orbit plane only exists as approximation in the (much simplified) two body theory of an orbit, but not in VSOP87.)

chris wrote:The potential problem with redefining two of Celestia's frames is that some scripts could break as a result.

In special and rare cases this might come true. But there will be workarounds. In my opinion your new frames are a step forward, Celestia will have much benefit from.

lidocorc

chris wrote:The potential problem with redefining two of Celestia's frames is that some scripts could break as a result. I call this a 'potential' problem because I'd be a little surprised if anyone has actually written scripts that would be sensitive to the change.

Does this mean i should not use Chase mode in scripts at all for now?

- rthorvald

chris wrote:It's interesting that you should mention this. I'm nearly finished with a complete rewrite of the observer frame code and was contemplating making this very change to chase mode, and also redefining phase lock mode to use the velocity vector as as the second frame vector.

IIRC, the primary vector in the phase lock frame is the direction of the second object relative to the first object. Perhaps the second frame vector should be the velocity vector of the second object relative to the first object. Is that what you had in mind?

- Hank

lidocorc wrote:...
A more straightforward (imho) setup of a frame, which uses the orbit velocity as a first frame vector, too, could use the normal vector of the orbit plane (= vector of angular momentum) as a second frame vector. So both frame vectors are derived from the same phenomenon, which gives the frame a more fundamental meaning.

...
lidocorc

Being also a (theoretical) physicist, I do agree with the above. One additional aspect as to the choice of the 2nd basis vector is that it might be desirable to select a vector that is (approximately) conserved during the system's movement. From that point of view the angular momentum vector is a good choice.

F.

rthorvald wrote:

chris wrote:The potential problem with redefining two of Celestia's frames is that some scripts could break as a result. I call this a 'potential' problem because I'd be a little surprised if anyone has actually written scripts that would be sensitive to the change.

Does this mean i should not use Chase mode in scripts at all for now?

In most cases, chase mode should continue to work just fine. There will only be problems if you're making calculations with coordinates, and even then, the change may not cause problems. The calculations would have to depend on the current definition of the secondary axis in chase mode--I doubt that there are any such scripts.

--Chris

hank wrote:

chris wrote:It's interesting that you should mention this. I'm nearly finished with a complete rewrite of the observer frame code and was contemplating making this very change to chase mode, and also redefining phase lock mode to use the velocity vector as as the second frame vector.

IIRC, the primary vector in the phase lock frame is the direction of the second object relative to the first object. Perhaps the second frame vector should be the velocity vector of the second object relative to the first object. Is that what you had in mind?

Yes, this is exactly what I had in mind, and it's also the same as what's depicted in lidocorc's second image.

--Chris