Attn: Fridger, Guillermo & Other Celestia Physicists

[VikingTechJPL]

Could The Celestia Physicists Please Check This?

I don't know if this should be here or in BUGS, but here goes.

Oh, how I hate to find that things don't work the way I expect in my favorite program! And CELESTIA "IS" my favorite program. So I always try to double-check things to see if an unexpected behavior is a real problem or just the error of this humble user. (Most often it turns out to be the latter.)

I’m looking to Fridger, Guillermo and any other CELESTIA physicists to either confirm or disprove the following logic. Actually, I hope they’ll disprove it, because it’s making my head spin.

While looking at various transits and occultations involving two planets, I happened upon something that I thought at first was just a paradox. As it turns out, if the following logic is sound, then it points to something far more fundamental. These three links recreating Venus's 1818 transit of Jupiter (as viewed from Earth) led to some unsettling realizations:

Event with NO Light-Travel-Delay
Time shown on CELESTIA’s clock: 21:46:11
cel://SyncOrbit/Sol:Earth/1818-01-03T21:46:53.50351?x=lWTrwGZN4f///////////w&y=UgC3ibAYHw&z=qQlSz0SPBw&ow=-0.577625&ox=-0.0997407&oy=0.790954&oz=0.175481&track=Sol:Jupiter&fov=0.0133263&ts=4e-005&ltd=0&p=0&rf=302487&lm=49154&tsrc=0&ver=3

Event with Light-Travel-Delay: Jupiter tracked and selected
Time shown on CELESTIA’s clock: 22:37:49
cel://SyncOrbit/Sol:Earth/1818-01-03T21:46:53.50351?x=lGTrwGZN4f///////////w&y=UAC3ibAYHw&z=qwlSz0SPBw&ow=-0.57761&ox=-0.0998858&oy=0.79097&oz=0.175374&track=Sol:Jupiter&select=Sol:Jupiter&fov=0.0133263&ts=4e-005&ltd=1&p=0&rf=302487&lm=49154&tsrc=0&ver=3

Event with Light-Travel-Delay: Jupiter Tracked but Venus selected
Time shown on CELESTIA’s clock: 21:59:36
cel://SyncOrbit/Sol:Earth/1818-01-03T21:46:53.50351?x=lGTrwGZN4f///////////w&y=UAC3ibAYHw&z=qwlSz0SPBw&ow=-0.57761&ox=-0.0998858&oy=0.79097&oz=0.175374&track=Sol:Jupiter&select=Sol:Venus&fov=0.0133263&ts=4e-005&ltd=1&p=0&rf=302487&lm=49154&tsrc=0&ver=3

The differences in clock time between the first link and either of the other two were of no concern; this is the way Light-Travel-Time is supposed to work. It was the disagreement of CELESTIA's clock time on the two last links that revealed the problem. How could both (which are supposed to be Earth times) disagree? A little further thought pointed to the following startling conclusions:

1) CURRENTLY, CELESTIA DOES NOT “AND CAN NOT” ACCURATELY RECREATE TRANSITS AND OCCULTATIONS INVOLVING TWO PLANETS AT THEIR PROPER TIMES! THIS IS BECAUSE CELESTIA DOES NOT ACCURATELY LOCATE PLANETS IN 3-D SPACE.

2) LIKEWISE, CELESTIA CAN ONLY RECREATE ECLIPSES AT THE OTHER PLANETS WITHIN A FEW SECONDS OF ACCURACY, AND SUCH RECREATIONS ARE ONLY ACCURATE IF VIEWED FROM EARTH!

3) THE FURTHER WE TRAVEL FROM EARTH IN CELESTIA, THE MORE INACCURATELY CELESTIA PLOTS A BODY’S LOCATION IN 3-D SPACE!

Now, before any stalwart CELESTIA fans accuse me of heresy, let me remind you that I am one of you. CELESTIA "IS" my favorite program. So allow me to explain.

Celestia uses VSOP87 to "locate" the planets where they "appear" when viewed from Earth at any particular time. But, as we'll see, this is not where they "should be" if we go out to visit them in 3-D space. Because of the time light takes to get to our eyes on Earth, all planets have already moved along their orbits by the time we on Earth see them. The problem that arises does so because CELESTIA places all bodies where they “would appear” from Earth “if light traveled instantaneously!” This therefore introduces a fundamental inaccuracy in where it locates them in 3-D space. (A pause while I stop my head from spinning.)

It should be stressed that, though this inaccuracy is related to the fact that light has a finite velocity, the conclusion is not a relativistic one. It holds true whether you wish to employ a Newtonian or an Relativistic frame to the problem.

As mentioned in Number 3 above, the inaccuracy increases with any object’s distance from Earth. So that means that when we go out to visit a planet, we’re not really where we should be. (Another pause to counter my head-spinning.) We are instead where we would be if the speed of light was infinite. We’re where VSOP87 says we should be, but only if viewed from Earth by means of a light that traveled to Earth instantaneously!

I don’t know it there’s an answer to this problem. Fridger, Guillermo and you other physicists will have to decide.

My conclusion is this:
TO PLOT CELESTIAL OBJECT POSITIONS AND MOTIONS IN 3-D SPACE ACCURATELY, CELESTIA (AND ALL ASTRONOMY PROGRAMS FOR THAT MATTER) WILL NEED TO ACCOUNT FOR "EACH AND EVERY" OBJECT’S LIGHT-TRAVEL-TIME TO THE OBSERVER! AND THIS MUST BE THE CASE WHEREVER THE OBSERVER GOES AND NO MATTER HOW MANY VIEWS CELESTIA IS SHOWING!

The multi-view issue is particularly noteworthy, because it brings up questions of simultaneity (though not of the relativistic kind). If you have a view of an Galilean eclipse with the observer at Jupiter, he’ll have to see it from 35 to 51 minutes earlier (are those figures right?) than an observer watching it from Earth. Again, this is is true whether your frames are Newtonian or Einsteinian.

The fact that CELESTIA lets us travel out to planets much faster than light introduces some more intriguing corollaries. Even setting aside all Relativistic effects (like “view-tunneling” and “time dilation”), the following would have to occur when we do go visit a planet: “while we are traveling” out to it, we should see its rotation-speed increase during our travel and then slow back down to agree with CELESTIA’s Time Rate when we get there! This is because we’re catching up to later and later light waves as we approach the planet. Likewise, as we travel toward the planet, its orbital velocity too would have to appear to accelerate until we reach the planet, because we would be making up the "light-time" between the starting and ending points of our travel to the planet. Conversely, both rotation and orbital velocity would have to slow down if we travel away from it (and reverse if we depart faster than light!) (Another pause while I again counter my head-spinning.)

CELESTIA’s developers obviously were aware of part (if not all) of this issue, as Light-Travel-Delay has been implemented since version 1.4.1 or before. Light-Travel-Delay is great for more accurately timing eclipses on another planet that we view distant from it. Since moons are so close to parent planets, the light-time difference between most moons and their parents amounts to only a few seconds. But, because planet locations in 3-D space are not correct, such non-terrestrial eclipses are only reasonably accurate from Earth. Moreover, the farther apart two bodies are, the greater the need becomes to account for “light-travel-time to the observer”. With transits and occultations, “light-travel-time" from the farther planet to the closer planet must be taken into account, and then “light-travel-time" from the closer planet to Earth.

I don’t know of any astronomy program that ALWAYS takes “light-travel-time to the observer” into account. Maybe that’s just too complicated to allow for, and too draining on computational resources. With multi-views and the simultaneity question, the issue becomes ever the more daunting. Furthermore, CELESTIA does not currently take into account the proper motion of stars other than the component-motion of multiples, and that would seem like a more immediate issue. Still, there's something at least mildly unsettling with CELESTIA's current "infinite-light-speed" framework.

Anyway, Fridger, Guillermo, I hope you'll find some flaw in the logic, though I fear that you won't. Either way, CELESTIA “IS STILL” my favorite program. Even if it's not completely authoritative, it still is the program that comes closest to revealing the “true wonders” of the Universe—"the Universe that is not only stranger than we imagine, but stranger than we CAN imagine."

Sign me,
Going to see if aspirin works on head-spinning.
--Gary

[Fenerit]

Event with Light-Travel-Delay: Jupiter Tracked but Venus selected
Time shown on CELESTIA’s clock: 21:59:36
cel://SyncOrbit/Sol:Earth/1818-01-03T21 ... rc=0&ver=3

With that link my situation is so:



in which Venus is NOT in conjunction. I've read your previous posts, and seems that you use the 1.4 version: now, I wonder whether the 1.6 (as mine) can have correct that issue (I've not checked it before) through the passage to the Barycentric Dinamical Time instead of UTC and then through its improvements. I'm not sure of this, of course; just a thought.

[t00fri]

Gary,

it was me who implemented Celestia's light travel delay (LT) feature a long long time ago. 2002 or 2003 I guess. It's a simple and most practical addition that has been tested "to the second" dozens of times in case of many different mutual (eclipse) events, as calculated by our common friend Jean Meeus! or from using actual timed observations. You can find many of these tests that I did throughout the years somewhere in this forum. They include many mutual eclipses of the Galilean moons, Saturnian moons, Uranus moons and lots of mutual eclipses of the Pluto Charon system.
And also eclipses of our Moon, of course. Or Mercury passages etc. All these tests I have carefully documented through many images in comparison with the predictions in the scientific literature.

My LT feature does precisely what it was made for. Not more and not less. Certain compromises wrto special relativity are dictated by the limited CPU/GPU resources etc. Indeed, the Celestia observer is kind of a Superman who can travel with virtually infinite speed. But according to standard usage in theoretical physics, the observer is a perfectly consistent "object": he/she is nothing but a "test particle" that does NOT participate in the "Celestia dynamics", really...

Since on your new web site you are planning to exploit such eclipse predictions by Celestia and further scripting add-ons commercially, perhaps you will understand that I am not happy about this venture, notably since most mutual events you can find already documented and tested here (free of charge, of course),

Hence certainly, my help to you in this area will remain very limited! But never mind, I know that ChrisL is more open about such things...

Nevertheless... Over eight years of Celestia development, we have stayed away from asking money for our work...It was also meant as a role model for the fact that first rate software can also be created without money being involved. Please, think about it....and note, unlike yourself,

I was NOT touching on legal issues here.

Fridger

[Fenerit]

.
.
.

Nevertheless... Over eight years of Celestia development, we have stayed away from asking money for our work...It was also meant as a role model for the fact that first rate software can also be created without money being involved. Please, think about it....and note, I was NOT touching on legal issues here.

Fridger

TOTALLY AGREE!

[VikingTechJPL]

Massimo,

You wrote:

I've read your previous posts, and seems that you use the 1.4 version: now, I wonder whether the 1.6 (as mine) can have correct that issue (I've not checked it before) through the passage to the Barycentric Dinamical Time instead of UTC and then through its improvements. I'm not sure of this, of course; just a thought.

Event with Light-Travel-Delay: Jupiter Tracked but Venus selected
Time shown on CELESTIA’s clock: 21:59:36
cel://SyncOrbit/Sol:Earth/1818-01-03T21 ... rc=0&ver=3

With that link my situation is so:



in which Venus is NOT in conjunction. I've read your previous posts, and seems that you use the 1.4 version: now, I wonder whether the 1.6 (as mine) can have correct that issue (I've not checked it before) through the passage to the Barycentric Dinamical Time instead of UTC and then through its improvements. I'm not sure of this, of course; just a thought.]

My three links were from the standard installation of 1.6.0, Windows version. Here's what all three links look like on my system (1.6.0 on Dell Inspiron 1720 (laptop), Intel Core Duo 2.00 GHz, 3.00 GB RAM, Windows Vista, NVIDIA GeForce 8600M G/GT.) The only difference is that the time on Celestia's clock reads differently on each one.



I do not see the LT (Light-Travel-Delay) notation in the upper corner of your screen. Is it turned off? Doing so does displace Venus.


EDIT
Massimo,
I just ran the link again, and then turned off Light-Time-Delay; and I get Venus in the same location as you. And Callisto too toward upper right. Here's my screen capture.



Just a thought: you might want to check and see if your system is reading the Light-Time-Delay from the url. The url should be turning it on for you.

Regards,
--Gary

[Fenerit]

Even though the links above locks whatelse selection I try, (as you can see, isn't showed the HUD as well as "F", "Y", "T" keys doesn't work) your third link with the LT deactive ("-") get this situation:



in which the time is that of the first link and Venus is conjuncted.

[VikingTechJPL]

Massimo,

I don't know if you saw the EDIT of my previous post. I think it updated after your last post.

Is the HUD you're using from Vincent's LUA tools? If so, you might want to ask him to try turning Light-Time-Delay on and off with the three links to see what he gets.

Regards,
--Gary

[Fenerit]

I didn't have read your EDIT LATER.

Anyhow, after having discovered that is the key "V" which re-show the HUD, my situation is now so:

Third link without LT turned on:


Third link with LT turned on (italian traslation here must be "TL" as "Tempo Luce" (light time) or the text go out of screen) and Venus selected:


Third link with LT turned on and Jupiter selected:


Here is what you got, right? LT is observer based, so account also for the distance from the obs to the Earth in that views.
(Earth to Jupiter) - [(Earth to Venus) + (Earth to observer)]. Is plausible?

[VikingTechJPL]

Massimo,

I'm glad to see that the second and third links produce the same views on your computer as mine when LT (Tempo Luce) is turned on.

Yes, it is the Tempo Luce that is the issue, and it is "observer based", as you say. Since the second and third pictures in your last post show the same event, and since Tempo Luce is supposed to be "observer based" time, Celestia's clock times on them should agree. That they do not is what led me to look at how Celestia plots planet locations in 3-D.

I e-mailed Fridger who confirmed the limitations of LT (Tempo Luce) in its present form, and that he implemented it this way due to CPU/GPU resource issues. LT works great—excellently, in fact—for looking at extraterrestial eclipses viewed by an Earth-based observer. But it doesn't really apply to transits and occultations involving two planets. It's not an error; it's just a simplification.

I don't know if Fridger will implement something else in his CelestiaSci project that will address accurate transits and occultations. I hope so. I'm looking forward to his release of CelestiSci. Sounds awesome.

May all of your journeys be joyous!
--Gary

PS I see you've done some pretty awesome add-ons. Very nice work indeed!

[chris]

The short version of why Celestia doesn't calculate light time delay for every object is that it would hurt performance. The Celestia renderer could (and probably should) be rearchitected to minimize the performance impact, but it would be quite a lot of effort.

To elaborate... Certain orbit calculations are quite time consuming, especially the VSOP87 orbits used for the Sun and planets of our solar system. Celestia has a simple caching scheme that saves the most recently computed position and reuses it. This means that orbit calculations are basically free when calling the computePosition function over and over again with the same time, which is exactly what happens now in Celestia. To take the Jupiter system as an example, here's (very) roughly what happens in the rendering loop:

Code: Select all

// t is the current time
for each satellite of Jupiter
{
    position = satellite.orbit.getPosition(t) + jupiter.orbit.getPosition(t)
    render(satellite, position)
}


getPosition is called repeatedly, but always with the same value of t, so it's very fast. We can get a very reasonable estimate of the position with light time delay by computing the geometric position (with no light time): once to get the approximate light delay, then a second time to get the position at the light delay adjusted time. More iterations will improve accuracy, but I believe that they're unnecessary for objects traveling at the speed of the typical solar system body (definitely worth checking that though!)

Code: Select all

p0 = body.orbit.getPosition(t)
lightDelay = length(p0 - viewer.getPosition(t)) / c
p = body.orbit.getPosition(t - lightDelay)


Plugging this into the original loop:

Code: Select all

for each satellite of Jupiter
{
    position0 = satellite.orbit.getPosition(t) + jupiter.orbit.getPosition(t)
    lightDelay = length(position0 - viewer.getPosition(t)) / c
    position = body.orbit.getPosition(t - lightDelay) + jupiter.orbit.getPosition(t - lightDelay)
    render(satellite, position)
}


Now, the call to getPosition() occurs with many different values of time. The simple caching scheme becomes useless and we end up evaluating the complex VSOP87 orbit functions many times.

The problem is actually more complicated than I've described so far. Celestia uses several different techniques for culling objects that won't be visible to the observer at the current simulation time. Often, it can cull an object without even computing its position. These visibility culling techniques were not designed with light delay in mind and would have to be rewritten to account for it. It's certainly possible, and it's a very interesting problem. It's just that no one has had time to tackle it yet.

Celestia could offer an option for 'global' light time delay that simply ignores the efficiency issues. This is a much easier task than optimal light time delay calculations. If you use JPL ephemerides or SPICE kernels instead of the much slower to calculate VSOP87 orbits, performance might even be quite reasonable.

--Chris

[VikingTechJPL]

Chris,

Your suggestion that 'global' light time delay might be possible to implement at some future time is awesome, Awesome, AWESOME!

I'm trying to quantify how much Celestia's VSOP87-placed 3-D planet locations differ from where the planets actually should be in 3-D space. As I mentioned to Fridger in an e-mail today, I thought I read a a post where someone's SPICE orbit did not seem to be placing a satellite in the proper place, and I began to wonder if the discrepency might be caused by this light-time issue.

It does seem that 'global' light time delay would only need to be offered as an option, since in many cases, LT is far from being an issue. If GLTD IS ever implemented, Celestia would work "much more like the Universe actually works" and it would accurately show transits and occultations involving two planets. I suspect it might also yield other "observational bonanzas" that we can't even imagine right now.

Mindful of how busy you and the other developers must be, I am nonetheless excited by the possibilities. If I can be of any assistance, please don't hesitate to let me know.

--Gary

[selden]

Gary,

I don't think the same light-time argument can be applied to SPICE trajectories.

When using SPICE trajectories, Celestia usually places the Cassini probe less than a few km from where NASA posts claim it should be when it is doing its various flybys. I suspect that people reporting major discrepancies when using SPICE may be using the wrong combination of SPICE kernels. Unfortunately, getting SPICE kernels to do the right things in Celestia isn't as straight forward as one would like.

[VikingTechJPL]

Hi Selden,

Sorry I wasn't a little clearer. Yes, it's likely that some errors being reported are user-induced, but I'm wondering if the following might also be happening.

1) Celestia is CORRECTLY applying the SPICE orbit and placing Cassini in the proper location in 3-D space, but
2) Saturn is being located incorrectly in 3-D space by Celestia because it's using VSOP without Light-Time-Delay.

So whoever is using the SPICE orbit thinks he or she is doing something wrong or that the SPICE orbit is wrong, when it's actually Celestia's placement of Saturn in 3-D space that's wrong.

The unfortunate realization is that, while Celestia's infinite light-speed paradigm does make things look right from Earth according to VSOP87, it immediately implies errors in planet positions in 3-D space. So, without "global" light-time delay—as Chris appropriately calls it—the positions of all the planets (except Earth of course) must be assumed to be off by a bit. I'm trying to quantify, at least roughly, the amount for each. But had a long busy day today, so hopefully I'll post it tomorrow.

Thanks,
--Gary

[selden]

When you use SPICE trajectories, you have to use SPICE for all of the relevant objects. If you care about the placement of a space probe relative to a particular planet, for example, you have to use SPICE for both the space probe and the planet. Trying to use different ephemerides based on different coordinate systems with different error characteristics is not going to produce consistent results.

In some sense, I'm agreeing with you, but placing the emphasis elsewhere. VSOP87 is fine for looking at the approximate positions of the planets, but is inadequate for observations which depend on precision placement. If you want that, you need to use a different ephemeris.

[t00fri]

I am not convinced about more complex, (i.e. more time consuming) versions of Light Travel (LT) delay as e.g. mentioned by Chris above. In a way this is like "special relativity for babies", and hence this is a non-desirable hybrid setting in my view. Special relativity has many more interesting visualization aspects, but their consistent implementation would definitely be a major coding task and make Celestia presumably too slow.

My old LT feature is a useful addition for many applications without interfering at all with Celestia's present thoroughly non-relativistic framework.

Fridger

[VikingTechJPL]

Good Morning, Fridger, Chris, Selden, Massimo and any other participants in this thread,

Fridger, in the friendly spirit of "Celestial accuracy and improvement", I'm afraid I'm going to have to disagree with your previous post. The following figures have convinced me.

They point to how much Celestia's infinite light-speed paradigm incorrectly places the planets in 3-D space.

Because I used the average distance of each planet from the Sun (as if all circular orbits), the real story is actually slightly more severe than that presented. But this still gives a good beginning snapshot. The Min columns toward the right quantify the Light-Time-Delay error when a planet is on the same side of the Sun as the Earth. The Max columns show this when the planet and Earth are on opposite sides. The two extreme right columns tell the story, because they show how far the planet has actually moved in its orbit over the light-time interval. I've shown them in kilometers, Planet Diameters and arc-seconds.

As expected, Venus and Mars show the least Light-Time-Effect (hereafter called LTE for brevity) in terms of "raw distance", though they also show the greatest variation—all because they're nearest to Earth of course. Mercury's high orbital velocity makes it experience the greatest displacement in terms of Planet Diameters, but all Planet-Diameter displacements point to the fact that—in its current form—Celestia cannot accurately simulate transits and occultations involving two planets.

Probably like you, Fridger, I had hoped the LTE would yield lower (more insignificant) figures, as then it would not be so troubling. But given these values, the errors in 3-D space make me wonder how people are getting SPICE orbits to work in any cases involving close passages to moons. Visiting a planet and winding up a diameter or two (or six in Mercury's case) further from it than expected may not be noticeable if you're not sure how close you're supposed to be. But, when you miss a small moon by a planet diameter, all bets are off.

Fridger, one last item. I keep wondering why you are referring to this as a "special relativity" issue. At the velocities of planets in the Solar System, the Galilean and Einsteinian frames are so close as to be essentially equivalent for computational AND observational purposes. As a physicist, you obviously understand that what we're experiencing here is the same thing that Romer experienced with Galilean eclipses in the 16th century that pointed to the fact that light-speed is not infinite. Moreover, the LTE would be an issue whether "c" was constant in all frames (Relativity) or not (Newton). Even the gravitational effects of relativity are so small that only Mercury's perihelion exhibits any measurable precession; and that's insignificantly slow enough to be dismissed in Celestia over decades of time. So I'd appreciate your thoughts on why you are "injecting" relativity into the equation—so to speak. It's challenging my cranial cobwebs.

I've attached my spreadsheet so that anyone can look at the math (and hopefully find that the errors are not as large as they appear.)

Either way, I hope that this can be resolved so that Celestia eventually does more accurately represent planet positions in 3-D space, transits and occultations. But one thing is certain: you CANNOT use LTE as an excuse for being late to work this morning. The facts just don't support it!

Regards to all,
Gary

PS When I previewed this post, the Forum gave me an Error Message that "the extension .xls is not allowed". So I'm not sure if the spreadsheet was uploaded. If anyone wants me to e-mail it to you, let me know. Thanks.

[chris]

But given these values, the errors in 3-D space make me wonder how people are getting SPICE orbits to work in any cases involving close passages to moons. Visiting a planet and winding up a diameter or two (or six in Mercury's case) further from it than expected may not be noticeable if you're not sure how close you're supposed to be. But, when you miss a small moon by a planet diameter, all bets are off.

Light time delay is not a problem for visualizing spacecraft flybys in Celestia. The error is dependent on the distance between two objects, which is by definition quite small during a close flyby. If an Earth-based observer is watching Cassini zoom by Enceladus, he or she will observe a close approach even if the finite speed of light isn't accounted for. Of course, the position of both Enceladus and Cassini relative to the stellar background will be off slightly.

A bigger problem with SPICE trajectories is that it is difficult to combine them with the default orbits for the planets and satellites. Celestia's built-in calculations of planet and moon positions are not good enough to accurately simulate close flybys by spacecraft. For that sort of thing, you need to use SPICE kernels for planets and moons as well as the spacecraft.

--Chris

[t00fri]

Gary,

first of all, I am not sure I precisely understand what you really did in your table above. But never mind, I am quite busy these days. It is important in the context of this LT discussion not to mix various issues...(see also ChrisL's comments above my post). Moreover, it is important to keep general and special relativity issues apart (c.f. Mercury's perihelion precession!).

Fridger, one last item. I keep wondering why you are referring to this as a "special relativity" issue.

Well since the full setting of special relativity follows already from just TWO principles: 1) the principle of relativity that I assume you know and 2) the principle of a finite and invariant light speed c!

From the latter you can e.g. easily derive all of Einstein's kinematical formulae about time dilatation, length contraction etc. And much more that I was alluding to earlier: e.g. charactieristic frequency shifts in relativistically moving frames as well as distortions of the observer's field of view etc. All these relativistic effects should be jointly visualized, once we subscribe to consistently implement the implications of a finite and direction-invariant speed of light that is independent of the state of the moving source!

The Newtonian mechanics limit (Celestia's framework!) is formally obtained from special relativity by making an expansion around c=infinity! . Sure we do need a finite speed of light sometimes in Celestia but I wanted to emphasize that we should not get more into implications thereoff as urgently needed. Otherwise we should really devise for consistency a fully relativistic framework for Celestia, rather than focussing on more complex "plumbing" corrections around LT stuff ONLY...

Fridger

[VikingTechJPL]

Hi Fridger,

I'm so eager to see your Celestia Sci and Cosmo-Viz projects, that I hope this has drawn you away from them for only an infinitesimally small (relativistic) amount of time.

In a nutshell, here's what I did.

A planet's position from Earth according to VSOP87 without Light-Speed-Effect would place its 3-D spacial position incorrectly by very close to the following amount:
Light-Time(to Earth) X the planet's orbital velocity
(that's a straight-line calculation, but the amount of curve on such a small part of the orbit is infinitesimally small.)

So I calculated "Light-Time(to Earth) X the planet's orbital velocity" for each planet when Earth is "nearest to" and "farthest from it" and expressed the values in km, Planet Diameters and arc-seconds. Since I only used average distances to the Sun (as if circular orbits) the effect would actually be a bit more severe, though (if my math is right) we're definitely in the right order of magnitude.

A note: I didn't rely on Celestia's "info-listed" planet angular diameters but calculated them in the spreadsheet with:
ANGLE = 2 (atan ( Rad / Distance ) ). A quick eyeball check afterwards seems to confirm that they're right.

I'll e-mail you the speadsheet.

Otherwise we should really devise for consistency ... rather than focussing on more complex "plumbing" corrections around LT stuff ONLY...

I agree. "Plumbing" corrections have a way of "leaking" in unexpected ways further down the road.

Thanks,
Gary

PS Thanks for the information you e-mailed me on your implementation of Celestia's awesome galaxies. I hope to get a chance to take a look at it in a few days.

[VikingTechJPL]

Hi Chris,

To me, the SPICE orbit question is beginning to seem ". . . curiouser and curiouser," as the bard says.

Are you talking about a SPICE orbit that is continuously defined from Earth to another planet. For Saturn. for example, the SPICE orbit would seem to have to share Celestia's Light Time Effect paradigm and therefore not be accurate in 3-D space.

If the SPICE is only partial, and relative to the visited planet's frame, or if it contains some sort of "step" in it, then I can see where fly-by's present no problem. That would immediately "build-in" Celestia's LTE. Is this what's happening?

Thanks,
Gary