Celestia Forums

Now that I've successfully compiled Celestia, Im planning on playing with the following (in order from what I perceive to be least to greatest complexity)...

1.) New output descriptions for spacecraft
- Mission Elapsed Time
- Solar Power available per unit area (function of distance from Sun)
- Current mass (perhaps mass flow rate/ thrust magnitude for continuous-thrust missions)
- Position (x,y,z in J2000 or Lat/Long), Velocity in J2000
- One-way comm time to/from Earth


2.) Trajectory plotting changes for spacecraft
- Option to display orbits of any spacecraft simultaneously (is this already possible?)
- Indication of thrust and coast periods in trajectory plots

3.) More advanced trajectory plotting would subsequently involve...
- Plotting of the thrust direction throughout the trajectory with vectors
- Roll, Pitch, Yaw splines to match the spacecraft with thrust directions
- DOF implementation to animate the spacecraft


I'm confident I can achieve the first goal on relatively short order. The second objective is somewhat more difficult but should be doable, and the third would be very challenging (the DOF stuff). Granted, I just recently got the code compiled and I'm sure I have much to learn before I can really get into the code.

Questions...

Does anyone else have mission visualization goals for Celestia? If so lets start a dialog on them now.

Would anyone disagree to the incorperation of such features into Celestia?

Falck,

Some people would strenuously object to adding spacecraft features to Celestia: it's supposed to be an astronomy program, not an arcade game. If you want a space flight simulator, investigate Orbiter.

Other people would welcome it.

Chris Laurel has the final say. He's on vacation right now and apparently doesn't have network access.

Even if many of your mods never get accepted for Celestia's mainstream code, that shouldn't discourage you. You might consider contacting Marc Griffith about contributing them to the Celestia variant Mostly Harmless. See http://mostlyharmless.sourceforge.net. Or you might find out how to create your own project on SourceForge.

Good luck!

P.S. i think I know what Don G. wants you to do along the way

Thanks Selden,

I guess part of the reason I posted this was to get Chris' opinion, since its his baby. However I think you slightly misunderstand what I'm trying to do. What I'm going for is not a spaceflight simulator. I have other tools that will generate a trajectory for me. What I'm going for is strictly visualization, something better than gnuplot to show orbit plots Celestia already has this to some extent, via sampled orbits, I'm just looking to add upon that.

Falck wrote:Questions...

Does anyone else have mission visualization goals for Celestia? If so lets start a dialog on them now.

Hy Falck

Your objectives are very interesting for me. Yet very ambitious.
One feature that I would like to see implemented about trajectory management is a new format for xyz file.
See the related feature request on my website.

Bye - Paolo

Hello Paolo,

I would like to see an enhanced xyz file as well, although I still favor separating the xyz file from the ssc file. Primarily because I think it is easier to generate the xyz data in a separate file, incorporating it into the more object-oriented ssc file could be messy.

You suggested something like:

[T pX pY pZ oX oY oZ]

[time position-x position-y position-z orientation-x orientation-y orientation-z]

I would like to see even more optional columns added, though I'm still debating with myself which would be best.

Something like:

[T px py pz ox oy oz mass thrust]

Mass and thrust could be used to modify the trajectory plot, such that thrusting and coasting regions are displayed with a different color, or with different linestyles.

It might be more beneficial, since it could be used for various purposes, to include a "plot color" at each point

[T px py pz ox oy oz #FF0000]

Also, I have been tossing around the idea in my head, of having a list of optional parameters that could be output for any given on the upper-left corner of the screen. Then, in the ssc file, one could specify

displayParams = "temp, radius, mass, missionTime, etc"

In general, I dont see any major drawback to specifying a large amount of information in the xyz file, even if some of it is optional. Hard drive space is cheap, the only potential drawback is whether having 6, 8, or 10 columns instead of 4 will slow the program down at all, and I dont think it will.

Falck wrote:In general, I dont see any major drawback to specifying a large amount of information in the xyz file, even if some of it is optional. Hard drive space is cheap, the only potential drawback is whether having 6, 8, or 10 columns instead of 4 will slow the program down at all, and I dont think it will.

WAIT!! Don't forget about the HUGE download size for something containing all that data...!! Please don't forsake us poor people with 56k dialups...

Youre right. But I still think the potential should still be there for higher fidelity, larger models. Smaller files without all that data should still be accessible.

I believe someone mentioned accessing zip files in another thread. Perhaps all the necessary files for an addon (ssc, xyz, etc) could be contained within a single zip file, thus minimizing the size of the download and the complexity of installing the addin.

Hi Falck

My suggestion about the size of xyz file should be to convert them in a real key framing animation format.

So instead of specifying all the data of every type (time, position, orientation, and so) for every row we will specify only the changes and the interpolation system between one key and the next.

If some of you have used programs like 3Dstudio Max, Maya, Lightwave or Flash you will understand perfectly what I mean.

Instead of
[T px py pz ox oy oz AAA BBB CCC ... XXX ]

Something like this
[T tp px py pz it]
[T tp ox oy oz it]
[T tp AAA it]
[T tp BBB it]
...
[T tp XXX it]

Where T, px, py, pz, ox, oy, oz have the same meaning that we already know.

tp: is the key type (position, orientation, path color, thrusts, whatever you want)
AAA, BBB,...XXX: are the parameters for the new key types
it: is the interpolation method between the keys of the same type (usually linear or spline).

This system not only should limitate the increase of the new xyz format file size also if a lot of new data will be added, but furthermore should allow to reduce the size of the actual format becouse instead of a very long series of position points an interpolation should be used even to simulate complex orbits during flybys.

Should be nice to have a system that builds key framing splines from a raw series of points in order to convert current xyz format. For instance motion capture animations uses these systems. Perhaps free source code is available somewhere to take inspiration.

Bye - Paolo

Maybe this idea wouldn't work out at all, but here's how I reckon the xyz/ssc/etc seperation should work:

1. xyz files remain exactly the same!

2. ssc files should remain mostly the same, but have an extra line referring to a file something like:


3. What these lines refer to are external files, which show extra info and features of the mission. If these files are missing, the spacecraft will still show up (like what happens if a model is missing) but the extra features just won't show up.

4. The thing I came up with above is only an example, but there could be others also!

5. My ideas about how the orientation file could be structured...
It would be something like a script file, but it would actually affect the spacecraft physically in the simulation. You should be able to specify data like the orientation of the model in a 3-axis stabilised mode, rotating mode, etc.
You could set a "pointing axis", which could then "track" an object, thereby doing something like constantly pointing a HGA at the earth etc
You could get the object to point at one object at a certain julian date, and then point to another over a specified number of julian days (or a decimal or whatever)
The rotation speed and precession, and all those other values could be changed and re-changed in the script-style file.
You could set a random movement to the spacecraft- say for hubble, you could set it up to randomly point at a certain star or planet (like in real life) for say 6 hours at a time, and then move on to another object, taking 30 minutes to do so, etc etc.

Using a format like this would be SO much more flexible than inserting it all into the xyz file, and it could be changed again, much more easily. I mean, who the hell wants to go all the way through an xyz file to edit a load of values in different places?!

Sound like a good idea? Obviously i'm not a programmer (I would have tried this already if I was!) so this could probably be much improved, but it's a start anyway!
//edited for spelling/grammar

Another use for the orientation information would be to show Uranus getting hit and turned over long ago.

Brendan

JackHiggins wrote:5. My ideas about how the orientation file could be structured...
It would be something like a script file, but it would actually affect the spacecraft physically in the simulation. You should be able to specify data like the orientation of the model in a 3-axis stabilised mode, rotating mode, etc.
You could set a "pointing axis", which could then "track" an object, thereby doing something like constantly pointing a HGA at the earth etc
You could get the object to point at one object at a certain julian date, and then point to another over a specified number of julian days (or a decimal or whatever)
The rotation speed and precession, and all those other values could be changed and re-changed in the script-style file.

Hi JackHiggins

Your point of view should have some advantages regarding retro compatibility with existing xyz format.
But instead of some kind of scripting language it sould be possible to add other types of animation keys like:

[T1 tp "name1"]
[T2 tp ""]
[T3 tp "name2"]
[T3 tp random]

Referring to my previous post tp is the type of the animation key.
In this case if we say that tp should be a key for "point to",
"name1" is "Jupiter" and "name2" is "Ganymede" the previous 3 animation keys should mean:
From time T1 point the object (probe, ship, HST, ISS ect.) to Jupiter (orientation animantion keys are disabled),
From time T2 point to nothing (orientation animation keys are re-enabled).
Form time T3 point to "Ganymede"
From time T4 point to objects (stars, planets, moons, deep sky objects etc.) randomly.

And so...the system should be limited only by your fantasy in creating new animation key types.

All this stuff sounds very gorgeous but the implementation part will require a lot of coding.

I would like to ear your opinions specially from Falck and JackHiggins.

Bye - Paolo

Well, maybe a "script" wasn't the best way to describe it- during the summer I was actually thinking about this, and wrote out a whole file as an example of the kind of syntax which would be involoved... I can't seem to find it now though, which is pretty annoying!

The things that DEFINITELY should be in the commands (The file format itself can be sorted out later) are:



And then at the end of every command there should be an option when to start & stop the command, and how long it takes to change from each to each.

ie something like



You wouldn't need to say untrack to stop tracking earth though, another track command would be an auto-untrack itself. When you do an untrack though, the spacecraft would automatically stay pointing in the same direction as it was pointing at the last moment of tracking.

A "Tumble" command would be nice too, for spacecraft gone out of control! Maybe a degree of tumble, 1 to 10, showing how badly the craft was out of control... All just ideas!!

Paolo;
The ability to specify new types of animation yourself would be very good- although i'm sure with enough basic types combined together, you wouldn't actually need to make your own?!
Whatever file format is the easiest for celestia to read anyway...

Has anyone ever considered using XML for the input files in celestia? I believe everything that has been discussed so far could be accomplished using XML, from a simple X,Y,Z file to a complicated thrust, orientation, file all with the use of a single DTD file. I also think that adding this additional information would be a great idea. Now that Celestia has basically mastered visualization of the universe, I would love to see celestia begin to add features like orbit determination and power calculations which are availible in expensive programs like Satellite ToolKit (STK).

Yes, but XML wouldn't have backward compatibility- and with an ssc type orientation file you could edit it much more easily than you could with a big list of orientations in an xyz file.

Just my 2 cents, but I reckon the ssc/script file or whatever would be the better option. Maybe I'll start a poll about it...

Backward compatibility would definately be a problem causing both input file types to have to be handled. In the past I would have agreed with you as to just using the standard ssc file format but now that I have been messing around with another open source project called FlightGear I have been really amazed at the power in which XML brings. FlightGear uses another open source project called SimGear in order to process the XML and bases all of its input and internal storage on XML. I believe that it would definately be worth looking into how FlightGear is using XML and how this could benefit Celestia.

Ahhh now we've opened a colossal can of worms

I'm somewhat cautious of splitting the spacecraft definitions into several files. XML would probably be the best solution in the long run. As for backward compatibility, a simple perl script could be written to convert from the "old" ssc/xyz format into a new xml format, so backward compatibility shouldnt be an issue.

I like the way Jack proposes to handle rotations. Its similar to the way they are handled in the flight sims (although I havent seen Flightgear, I'll have to take a look at it).

If someone wants to get the ball rolling thats great, though I dont think it should be me. My C++ is so rusty that I'm going to start off with the simple things (1 and 2 on my list) before worrying about the complexities of animations.