Displaying orbits

[chris]

There have been quite a few complaints about gaps and jumps in Celestia's depiction of orbit paths. These gaps exist because the orbit of a body is generally not a perfect ellipse due to gravitational perturbations from other bodies. In the current SVN code, Celestia draws planet orbits over a duration of one mean orbital period, starting at the current time minus one half the orbital period. Thus the gap appears approximately 180 degrees away from the body, though this will vary for significantly eccentric orbits like Pluto's. While this placement of the gap is an improvement over previous versions, it's still visual jarring. The screen shots below hide the gap via a fade effect. The effect is configurable: the linear fade can occur anywhere in the orbit, or it can be disabled completely. These screen shots show a linear fade over half of the orbit.

solarsys-orbits.jpg

saturn-orbits.jpg

--Chris

[Chuft-Captain]

Sorry, I can't say that I like this effect Chris. I take it that there's no easy/efficient way to close the gap.
I know that accuracy is your priority, just not sure if I like the solution.

JM2CW.

[chris]

Sorry, I can't say that I like this effect Chris. I take it that there's no easy/efficient way to close the gap.
I know that accuracy is your priority, just not sure if I like the solution.

It's not a matter of ease or efficiency: the gap is real. The only way to eliminate it is to draw the osculating orbit instead of the actual path of the object through space.

--Chris

[chris]

The patch against SVN revision 4945 may be downloaded from here:

http://www.celestiaproject.net/~claurel/celest ... fade.patch

The fade effect is actually a small part of the patch. The bulk of the changes address problems with elliptical orbits, and general shortcomings of the old orbit sampling scheme.

--Chris

[Cham]

Just to say that I **love** the second picture !

Graphically, we easily feel the motion, with this fade effect. And we can easily guess in which sense the body is actually moving, without having to accelerate time.

To me, this is a HUGE improvement !

[Guckytos]

I don't like it either.

If it is in the code now, okay, but please make it switched off per default.

And where can I configure it? In celestia.cfg?

Best regards,

Guckytos

[t00fri]

Chris,

why don't you tell (for the experts among us) what exactly you did to eliminate the familiar remaining orbit drawing problems??

I don't like the fading feature either.

While I agree with Martin that the fading informs about the sense of the movement, it INCORRECTLY suggests also an acceleration of the body (starting from rest = maximal fading) until its final speed (no remaining fading). This is physically misleading.

Fridger

[ajtribick]

Like the others I'm not convinced about the fading effect. I would prefer the rendering of the osculating orbit instead, which makes it obvious that the orbit is deviating from the Keplerian scenario (the user can see the orbit shift with time) instead of hiding the orbital evolution.

We already have an add-on that displays (some of) the osculating orbit parameters.

[CAP-Team]

I'd like to mention that even in build 4936 planetary orbits are not drawn at all, if the orbit is a spice orbit.
Orbits of moons with spice orbits are drawn correctly.

[chris]

I don't like it either.

If it is in the code now, okay, but please make it switched off per default.

It's not in the code now, as the patch still needs to be reviewed by the other devs. The optional fading effect would be configured via the GUI, not celestia.cfg--I think it's best to avoid adding more settings that can only be modified by editing the config file.

--Chris

[chris]

Chris,

why don't you tell (for the experts among us) what exactly you did to eliminate the familiar remaining orbit drawing problems??

Recall that for drawing purposes, orbit paths are approximated as piecewise cubic curves.There have been three improvements since the last orbit patch submitted to the dev list:

- Improved the adaptive sampling algorithm so that it can adjust the step size downward from the starting step size. The old algorithm adjusted the step size upward only, so you had to pick the 'right' starting step. Too large, and the tolerance isn't met; too small, and a lot of time is wasted searching.
- When the 'window' needs to be adjusted because the simulation time changes, the new code will use adaptive sampling instead of reverting to fixed time step sampling.
- The adaptive sampling algorithm is applied to all orbit types (SPICE, VSOP87, etc.), not just elliptical.

--Chris

[chris]

Here are a couple examples where fading is used to help illustrate the evolution of an orbit over 10 periods. First, Hyperion:

hyperion-orbit.jpg

Next, the Moon... Here, the fading is less helpful because the orbit evolves less regularly than Hyperion's:

moon-orbit.jpg

--Chris

[Hungry4info]

Personally, I love the fading effect.

[selden]

The patch compiled and ran on my home computer. I don't think it's doing the right thing for spacecraft xyz and xyzv trajectories, though: shouldn't it terminate at the object's current position, not continue on? The screengrab below shows Cassini.

I think the GUI should make it easy to switch between orbit paths which trail the object and the (possibly disjoint) ones which are centered on the object.

[Imy]

Hi,

I like the fading effect which allows to know the sense of the movement but also thanks to that it's easier to locate the object itself!

Is interesting to have orbits which appears slowly with fading when we turn them on or off?

[Guckytos]

If we are already at orbit lines I'd like to have the following possiblities for spacecraft trajectories:

• Define the maximum length (timewise) of the trajectory to be shown.
• In both directions (past and future). Future should then be dotted or lines with spaces.
• Be able to adjust past and future indepently from each one.

They could even have fading effects. And if possible with an easy slider control box.

Background is the rather clogged up Saturn, when all of Cassinis trajectory is seen on screen.

Just my 2 cents.

[chris]

The patch compiled and ran on my home computer. I don't think it's doing the right thing for spacecraft xyz and xyzv trajectories, though: shouldn't it terminate at the object's current position, not continue on? The screengrab below shows Cassini.

Thank you for testing the patch, Selden. The display of spacecraft trajectories is controlled by the 'show partial trajectories' flag. If it's enabled, only the port of the orbit up to the current time is shown. However, this flag is obscure, and has no effect on periodic orbits. As you, Christian, and Andrew have pointed out, Celestia could use some finer controls over the display of orbit paths:

Time range:
- Fixed (e.g. entire trajectory for a spacecraft)
- Fixed start until current simulation time
- A fixed duration interval...
- centered on the current simulation time
- ending at the current simulation time
- For periodic orbits, the time interval could be specified either in terms of revolutions or some fixed time unit.

Render style:
- To fade or not to fade
- Dashed or dotted lines for orbit segments in the future

Osculating ellipses or traces?

An open question is what the scope of orbit style settings should be. Global settings are useful of course, but it would also be useful to have per-object settings. For example, it could be useful to view just one month of Cassini's trajectory while a full revolution is shown for orbits of all Saturn's moons.

The reference frame is another critical consideration in orbit plotting, but one which should be saved for another thread in order to keep the scope of this discussion manageable.

--Chris

[Guckytos]

An open question is what the scope of orbit style settings should be. Global settings are useful of course, but it would also be useful to have per-object settings. For example, it could be useful to view just one month of Cassini's trajectory while a full revolution is shown for orbits of all Saturn's moons.

A general rule would probably be useful, but with the addition of being able to make a per-object override. Perhaps with predefined settings (user changeable?) that can be called with a right click menu?

[ajtribick]

Perhaps would be best to implement both scenarios... concepts such as orbital precession and resonant orbits are perhaps more easily demonstrated with the osculating orbit, but trails could be more useful if you want to demonstrate, e.g. the convex orbit of the moon in the sun-centred reference frame.

[lithium3]

I’m not a developer of Celestia but her I go,

I agree with the right click menu option because there is to much in the render menu,
+ I agree with it giving you a cense of movement and you can find it with out using the labels.

I LOVE IT, and I would lick to see it on 1.6.1 if it happens