Is a dynamic observer orbit possible?

[hharris]

Hi,

I've read in this forum that to put the observer in an elliptical orbit, the way to do this is to follow an invisible S/C.

I would like to do a rendezvous of the observer with the ISS or any orbiting spacecraft. Is it possible to dynamically create the orbit? I would like to give the user of my exploration script the option of the rendezvous of the observer with any orbiting spacecraft which would include approach and docking.

Henry

[selden]

If you use a Celx script, it should be possible to calculate whatever trajectory path you want and have the viewpoint follow it.

[hharris]

Cool. Sounds like I'm going to be honing my orbital mechanics chops.

I suppose the way to do this, in order keep the treasured smooth animation of Celestia, is to precalculate the trajectory and move the observer incrementaly along the intercept path?

Henry

[selden]

Certainly that would be my suggestion. The fewer calculations are done in between frames, the faster the framerate can be.

[hharris]

There's an obvious way to do this. Instead of pre-calculating a trajectory, all I have to do is calculate the force of gravity at any particular interval and do the math; however, this brings up an interesting question (well, at least to me it is). What kind of gravity models are used to calculate the orbit parameters for a satellite in Celestia? I would have to make the same assumptions about the gravity models, such as the number of harmonics, to do a rendezvous maneuver this way. Obviously, if the model had high resolution, I probably couldn't do it in real time. For that matter, is there even a standard model resolution used for all the trajectories?

Henry

[selden]

Celestia doesn't use gravity explicitly. It uses ephemerides and Keplerian elipses.

(It is designed so that the viewpoint at any instant of simulation time can be calculated without knowing the previous positions of any objects. I.e. time is the only independant variable. In particular, at any instant, it allows the user to specify another simulation epoch and Celestia will calculate the locations of all visible objects at that time. In other words, these calculations are redone for every frame.)

For planetary orbits, it normally uses the ephemeris known as "VSOP87 Theory" when a predetermined "CustomOrbit" is specified, although it also can use some JPL ephemerides. I'm not sure how many terms are in the polynomials that Celestia uses, but I think it's more than 1,000. You'd have to look at the code to be sure.

Does this answer your question?

[hharris]

Thanks! Yes it does answer the question and it is what I was theorizing. What it means is that I can't put the same amount of realism into dynamic orbits as those orbits that come from high-order gravity models of Earth and other bodies within the solar system. I applaud the ambition of the creators of Celestia. Of course, there are some bodies in the solar system and certainly bodies in other solar systems for which there is no data base anyway. And for the purpose of visualization, at least, it doesn't make much difference whether you're using a thousand coeficients or using a 1/r^2 model. If you're really need that much accuracy for mission design, for example, there are other tools (without the wonderful graphics) that do a much better job.

So, accuracy considerations aside, we can still have some fun. I can certainly fake rendezvous and docking with the tools already provided. I just spent 27 years in the real space program, and even ran an interstellar propulsion program, but the truth is, I'm only going to get to the stars with something like Celestia. I'd really like to know what it looks like.

Henry

[hharris]

After looking at the SSC file definition, I came to the conclusion there is a bit of confusion here. The SSC definition is for a simple ellipse. What you were talking about models the dips and changes in orbit due to non-spherical planets (not to speak of non-symetrical mass distribution). The SSC file doesn't contain that kind of information. I was thinking that the Celestia creators were really out there to build in such complexity, but it isn't true.

So my 1/r^2 observer would work perfectly fine since it's the same physics that's driving an ellipse.

So my real question is ... is it possible to dynamically load an SSC description? My guess is the answer is no. I haven't seen any documentation to suggest it is.

Which is too bad because it eliminates the possibility of world building on the fly. Why would anyone want to do that, you ask?

Well imagine you have a universe of a million stars. Are you going to create models for every object around each of those stars and load it in before you start? No, of course not, but if you could dynamically load in SSC information then you could, using statistical models and coordinate-driven keys, create an entire million planetary universe with an almost infinte variety to explore.

And that, my friend, would be cool.

Henry

[selden]

The SSC definition is for a simple ellipse. What you were talking about models the dips and changes in orbit due to non-spherical planets (not to speak of non-symetrical mass distribution). The SSC file doesn't contain that kind of information.

That's right, it doesn't. The VSOP and JPL ephemerides are implemented in hard-coded routines internal to Celestia and are invoked with CustomOrbit declarations. If both CustomOrbit and EllipticalOrbit declarations are present in an SSC entry, CustomOrbit is used. If CustomOrbit is invoked with a name that Celestia doesn't recognize, it's ignored. All of the planets and many of the major moons have CustomOrbits defined.

is it possible to dynamically load an SSC description?

Not yet. There has been some discussion on the developers' mailinglist of how that might be implemented, but it isn't obvious how soon that might happen. Right now, all objects must be defined in catalogs that are loaded when Celestia starts.

Also, Celestia currently cannot reliably draw stars when they're more than about 16K LY from the Sun. This problem has been discussed many times and is described in the "Preliminary User's FAQ" which is a sticky near the top of the Users Forum.

A variant of Celestia called Mostly Harmless was created which is capable of loading extremely large databases and includes database manipulation routines. Unfortunately, its author went on "walkabout" and never came back.

http://mostlyharmless.sourceforge.net/index.htm

[hank]

is it possible to dynamically load an SSC description?

Not yet. There has been some discussion on the developers' mailinglist of how that might be implemented, but it isn't obvious how soon that might happen. Right now, all objects must be defined in catalogs that are loaded when Celestia starts.

I've thought about the idea of replacing Celestia's catalog files with Lua code. It would seem to require only a slight change in syntax, and would be much more flexible. Celestia's current catalog parsing scheme creates C++ hashes as inputs to internal object creation methods. Using Lua tables as input would seem to be a fairly straightforward modification.

- Hank

[hharris]

Okay, I guess the next best thing for right now would be to write a planet file creation program that would take the information about a star and implement some of the planet models under development and refined since the sixties. Might be interesting to do that for the nearby stars at least. I'm not sure how textures would be handled however. Has anybody taken a crack at that?

Henry

[selden]

I'm not sure what you mean by "how textures would be handled".

Do you mean how would it create reasonable texture names for the planetary types that have been generated?

Celestia includes some generic planetary surface textures (exo-class1.jpg through exo-class5.jpg) derived by Celestia user "Chaos Syndrome" from the 2000 paper "Albedo and Reflection Spectra of Extrasolar Giant Planets" by Sudarsky, et al.

Also included is venuslike.jpg.

For other planetary types, you could either use the textures provided for our own Solar System's planets, or you might provide some generic ones of your own. Since they'd be representational, and not maps of actual planets, they probably could be low resolution, and needn't take up much space.