Faster, smooth high precision orbits

[chris]

Here's an update to the orbit smoothing patch:

http://www.celestiaproject.net/~claurel/celest ... thorbits2/

It corrects the bugs seen with spacecraft trajectories and extremely eccentric comet orbits. Performance has been addressed by breaking orbits up into sections and precomputing bounding volumes for each section. The bounding volumes are used to perform a quick visibility check on each section so that time isn't wasted drawing invisible parts of orbits.

To use it, you need to have the latest version of the source from CVS (it won't compile without some very recent changes.) Then, replace your versions of render.h and render.cpp with the ones in the patch directory.
As with the last version of the patch, the smoothing may be toggled on and off by pressing Ctrl+E (eclipse shadows--it's just temporary.) I'm getting good results with OrbitPathSegments set to 400.

--Chris

[Cham]

I'll test it during the following days, most probably tonight, when I'll be back home.

[selden]

It seems to be working well for me. The "Cassini bump" is gone and cometary orbits curve smoothly. The partial intermittant orbital path segment that used to be drawn in front of Neptune isn't visible. I don't see any obvious slowdown, but it might be noticed on a slower computer.

I'm using the default 100 orbital segments.

System configuration:
2GB, 1.86 GHz E6300 Core2Duo; Windows XP Pro SP2
128MB Quadro FX 550; ForceWare v162.62

[ElChristou]

Work nicely with default package on my config.

[chris]

Thanks for the reports. I'll check in the code soon provided no one else finds any serious bugs. There's still more that could be done to improve the display of orbits, but I feel that with the new code, they look much better than they ever have before in Celestia.

--Chris

[Cham]

I updated and recompiled Celestia from CVS. Everything appears to work great for the moment (except for some few glitches described below). I'm using OrbitPathSegments set to 512. No noticeable slow down, even with all the comets and astreroids orbits and labels, grids, borders, galaxy labels, markers, etc. all turned ON.

However, I've noticed few glitches here and there. Here's a description of all of them :

1- I'm still able to reproduce some **pretty rare** holes on orbits. Especially while following the Kore moon around Jupiter, while comets orbits are ON :

cel://Follow/Sol:Jupiter:Kore/2064-03-1 ... 2358&ver=2

There are two holes showing on some comets orbits on the background.

Also, turning ON all comets and asteroids orbits, I'm able to have some holes on some asteroids orbits (on the background). Just sliightly rotate around Kore, from this URL :

cel://Follow/Sol:Jupiter:Kore/2064-03-1 ... 2358&ver=2

Despite these examples, I'm certainly experiencing MUCH less orbital holes than before, so there's a huge improvement here.

2- In the case of small bodies (Mars, and smaller objects like asteroids and spacecraft), the orbital curve doesn't always pass to the body's center. In the case of Cassini, I'm even getting some weirdness on its orbit. Here are two URLs showing the problems :

cel://Follow/Sol:Cassini/2064-09-16T19: ... 2358&ver=2

And more specificallly this weirdness :

cel://Follow/Sol:Cassini/2064-09-16T19: ... 2358&ver=2

3- In the case of our Moon, there's a weirdness on its orbit, which can be visible anywhere on the orbit, if we accelerate time. It's an artifact of our old discontinuity "friend", since the Moon's orbit isn't a perfect elliptical path :

cel://Follow/Sol:Earth:Moon/2064-03-14T ... 2358&ver=2

Or try this one (the same as the previous, with some shift in time) :

cel://Follow/Sol:Earth:Moon/2064-03-14T ... 2358&ver=2

So in conclusion, the new code still needs some adjustements/corrections.

[chris]

I updated and recompiled Celestia from CVS. Everything appears to work great for the moment (except for some few glitches described below). I'm using OrbitPathSegments set to 512. No noticeable slow down, even with all the comets and astreroids orbits and labels, grids, borders, galaxy labels, markers, etc. all turned ON.

However, I've noticed few glitches here and there. Here's a description of all of them :

1- I'm still able to reproduce some **pretty rare** holes on orbits. Especially while following the Kore moon around Jupiter, while comets orbits are ON :

cel://Follow/Sol:Jupiter:Kore/2064-03-1 ... 2358&ver=2
There are two holes showing on some comets orbits on the background.

I'm not able to see any holes; I'm sure that it's driver specific as before.

2- In the case of small bodies (Mars, and smaller objects like asteroids and spacecraft), the orbital curve doesn't always pass to the body's center. In the case of Cassini, I'm even getting some weirdness on its orbit. Here are two URLs showing the problems :

cel://Follow/Sol:Cassini/2064-09-16T19: ... 2358&ver=2

And more specificallly this weirdness :

cel://Follow/Sol:Cassini/2064-09-16T19: ... 2358&ver=2

Fixed that problem with the Cassini trajectory--turned out to be a typo in the code. There's more work to be done to make the orbital curve pass closer to a body's center, but it's already much better than it was before. I'm going to postpone further work until after 1.5.0.

3- In the case of our Moon, there's a weirdness on its orbit, which can be visible anywhere on the orbit, if we accelerate time. It's an artifact of our old discontinuity "friend", since the Moon's orbit isn't a perfect elliptical path :

cel://Follow/Sol:Earth:Moon/2064-03-14T ... 2358&ver=2

Or try this one (the same as the previous, with some shift in time) :

cel://Follow/Sol:Earth:Moon/2064-03-14T ... 2358&ver=2

Same old problem. I'll take care of it after 1.5.0. My plan is to calculate the osculating elements for the Moon and the planets and render an ellipse for the orbit. Rendering an ellipse is fast enough that it can be done every frame.

--Chris

[selden]

The new orbit code crashes Celestia when attempting to display MKruer's BlueVenus parasol & reflector.

See the thread at

http://celestiaproject.net/forum/viewtopic.php?p=95469#95469

Click on the thread's URL after installing the Addon. When orbit paths are enabled, Celestia "encounters a problem" and dies. This problem is not seen in Celestia v1.5.0pre4.

[Cham]

MKruer's models appear to be buggy, they are crashing my modeler.

[chris]

The new orbit code crashes Celestia when attempting to display MKruer's BlueVenus parasol & reflector.

See the thread at

http://celestiaproject.net/forum/viewtopic.php?p=95469#95469

Click on the thread's URL after installing the Addon. When orbit paths are enabled, Celestia "encounters a problem" and dies. This problem is not seen in Celestia v1.5.0pre4.

I can't reproduce the crash with either the BlueVenus add-on or the cel:// URL you sent to the dev list. I don't doubt that there's a bug, but I'm going to need some more help to reproduce it.

--Chris

[selden]

It seems to be related to my ScriptedOrbit/ScriptedRotation functions for controlling the Hale telescope. The presence of the BlueVenus addon was a red herring. Sorry.

Presumably I've omitted some orbital (period?) parameter that causes problems when seen from afar. Celestia built from cvs does not crash if I start it using a URL that takes me directly to the telescope; that's what I've been doing while working on the model and the associated scripts.

The non-debug build of Celestia (created by using the script makerelease.bat) crashes if I start Celestia by selecting its "run" icon or by starting it by selecting the aforementioned URL which views Venus. If I start Celestia using the Hale url, it crashes when I later select the Venus url.

The debug build of Celestia (created by using the script makedebug.bat) does NOT crash if I start Celestia by selecting its "run" icon. It does crash if I either start it with the Venus url or later select that URL. If I start Celestia using the Hale url, it crashes when I later select the Venus url.

I'll try to generate a reduced version of my Addon which crashes. It may take a while.

[selden]

I'm finding other crash provocations along the way...

Celestia from cvs crashes when it approaches a body defined in an SSC which specifies a ScriptedRotation but the Lua module file does not exist. Previous versions of Celestia generated error messages in the (tilde) console log. It also crashes if the file exists but is empty.

In particular, Celestia crashes shortly after startup while approaching the Earth with this SSC file

Code: Select all

"Hale_position" "Sol/Earth"
 {
   Radius 0.000001
   Mesh "invisible.cmod"

   OrbitFrame {BodyFixed{Center "Sol/Earth"}}
    FixedPosition [ -2407.995293963999 -4753.859694051927 3507.914571886229]
   BodyFrame       { EquatorJ2000 { Center "Sol/Earth" } }
   ScriptedRotation
   {
      Module "hale_control"
      Function "YokeRA"
      Viewpoint "hale_yoke"
   }

   Albedo 0.0001
}


[selden]

*sigh*

My most recent tests seem to indicate that the problem is somehow related to the FixedPosition declaration, not to the ScriptedRotation. Investigation proceeds....

[selden]

I'm sure people will be glad to know that Chris found the FixedPosition bug and stomped it.

[t00fri]

Despite all progress in orbit smoothness, please don't
forget that the present orbits DO NOT make PHYSICAL
sense for many configurations. Sensible orbit displays
depend on the frame of reference chosen, which is
generally ignored at present!

E.g. If I put Charon at rest, then every body, i.e. Pluto,
and all the solar system bodies should orbit around the
stationary Charon, with orbits correspondingly
drawn.

As you can easily convince yourself, right now, the whole
solar system rather "wobbles" around Charon on
physically nonsensical orbit displays.

I usually get DRUNK over watching the present orbits, hi hi...

Bye Fridger

[chris]

Despite all progress in orbit smoothness, please don't
forget that the present orbits DO NOT make PHYSICAL
sense for many configurations. Sensible orbit displays
depend on the frame of reference chosen, which is
generally ignored at present!

E.g. If I put Charon at rest, then every body, i.e. Pluto,
and all the solar system bodies should orbit around the
stationary Charon, with orbits correspondingly
drawn.

As you can easily convince yourself, right now, the whole
solar system rather "wobbles" around Charon on
physically nonsensical orbit displays.

I usually get DRUNK over watching the present orbits, hi hi...

Bye Fridger

I'll agree that there are situations in which trajectories should be shown in reference frames other than the ones in which they are defined, binary stars being the primary examples. However, switching the display of every orbit to a frame centered on the currently followed object would lead to terrible confusion, I think. And the trajectory of, say, Mercury in a Charon-centered reference frame is simply not what you want to see most of the time--it's visual clutter. Being able to see the orbit of Charon with respect to either Pluto or the Pluto-Charon barycenter is more interesting, and should be supported in Celestia somehow. But switching the display of *all* orbits would be a mistake, I think. I do want the capability to plot a trajectory in the reference frame of my choosing, just not the automatic switching whenever a new object is chosen as the center of the viewer reference frame.

I take issue with your claim that the present orbits don't make physical sense. They do make physical sense: they are plotted in the reference frame in which they're defined. In my opinion, that's no less arbitrary than plotting them in the reference frame of the viewer.

--Chris

[t00fri]

Chris,

what you are advocating is physically inconsistent.

In our usual non-relativistic approximation, the Universe must be Galilei invariant, i.e. the physics must remain unchanged wrto coordinate transformations between different frames in the framework of Newtonian mechanics.

You can e.g. perform a coordinate transformation to a frame, where Charon is at rest --relative to the observer-- at all times. But then you MUST transform ALL space-time points into the SAME frame such that the physics remains unchanged! What you advocate instead, is to leave certain sequences of points, namely the orbit points (i.e. the locus of Charon in the past and in the furture) untransformed.

That is inconsistent, sorry.

Since the reference system, where Charon is at rest at all times is uniquely determined, also Charon's orbit lines must correspondingly collapse into ONE point in the Charon rest frame. Instead, in Celestia, the old untransformed orbits continue to move around in space ...


Nowithstanding, it may be instructive to contemplate a menue offering fast switching between various popular reference frames.

Bye Fridger

[t00fri]

One well-known illustration of my general statements above concern Ptolemy's solar system model, which was geocentric, i.e. Earth was at rest wrto the observer. As many of you will know, in this system, the planetary orbits as projected to the celestial sphere are more or less crazy , and in any case highly complex.
To account for apparent anomalies in this geocentric view, such as the retrograde motion of the planets, a system of deferents and epicycles was used.

----------------------------------------------------------
Anyhow --in this Earth rest system-- these crazy planetary orbits cannot be changed, simply because Chris might find them not very practical
-----------------------------------------------------------


On the other hand, Copernicus then looked at the solar system in a heliocentric frame and all that complexity resolved into VERY simple elliptical orbits around the resting Sun...

Bye Fridger

[chris]

Chris,

what you are advocating is physically inconsistent.

I view it as a deliberate design choice to show orbits in the most familiar and intuitive frames.

In our usual non-relativistic approximation, the Universe must be Galilei invariant, i.e. the physics must remain unchanged wrto coordinate transformations between different frames in the framework of Newtonian mechanics.

You can e.g. perform a coordinate transformation to a frame, where Charon is at rest --relative to the observer-- at all times. But then you MUST transform ALL space-time points into the SAME frame such that the physics remains unchanged! What you advocate instead, is to leave certain sequences of points, namely the orbit points (i.e. the locus of Charon in the past and in the furture) untransformed.

That is inconsistent, sorry.

Since the reference system, where Charon is at rest at all times is uniquely determined, also Charon's orbit lines must correspondingly collapse into ONE point in the Charon rest frame. Instead, in Celestia, the old untransformed orbits continue to move around in space ...


Nowithstanding, it may be instructive to contemplate a menue offering fast switching between various popular reference frames.

I still say you're mad

Nevertheless, in the not-too-distant future, I will add code to plot trajectories in reference frames other than the ones in which they are defined. This is an extremely useful feature in some cases, e.g. viewing the trajectory of Cassini in a Saturn-centered frame, or visualizaing horseshoe orbits. We can experiment with a switch to change the reference frame for all orbits, but I'm quite sure that it will frustrate 99% of users, making them wonder what the hell happened to their nice elliptical orbits.

--Chris

[t00fri]

Chris,

what you are advocating is physically inconsistent.

I view it as a deliberate design choice to show orbits in the most familiar and intuitive frames.

Sure computer guys can code everything But please note that this way you are working in TWO frames simultaneously

In our usual non-relativistic approximation, the Universe must be Galilei invariant, i.e. the physics must remain unchanged wrto coordinate transformations between different frames in the framework of Newtonian mechanics.

You can e.g. perform a coordinate transformation to a frame, where Charon is at rest --relative to the observer-- at all times. But then you MUST transform ALL space-time points into the SAME frame such that the physics remains unchanged! What you advocate instead, is to leave certain sequences of points, namely the orbit points (i.e. the locus of Charon in the past and in the furture) untransformed.

That is inconsistent, sorry.

Since the reference system, where Charon is at rest at all times is uniquely determined, also Charon's orbit lines must correspondingly collapse into ONE point in the Charon rest frame. Instead, in Celestia, the old untransformed orbits continue to move around in space ...


Nowithstanding, it may be instructive to contemplate a menue offering fast switching between various popular reference frames.

I still say you're mad

I guess I will have to change my avatar into a HUGE glass of German beer.

Nevertheless, in the not-too-distant future, I will add code to plot trajectories in reference frames other than the ones in which they are defined. This is an extremely useful feature in some cases, e.g. viewing the trajectory of Cassini in a Saturn-centered frame, or visualizaing horseshoe orbits. We can experiment with a switch to change the reference frame for all orbits, but I'm quite sure that it will frustrate 99% of users, making them wonder what the hell happened to their nice elliptical orbits.

--Chris

Yes, indeed, think about all this a bit more

Bye Fridger