Additional universe information patch completed
Posted: 09.07.2003, 17:02
Hey everyone. I just started using Celestia recently, and just love it; so, in the spirit of Open Source software, I worked on it a bit and added in some new informative capabilities (and put in the data that I could track down on the subject, along with formulas to approximate the information in its absence). The new information that shows up in verbose mode:
Moons and planets:
Surface temperature fields (mean, day and night averages, seasonal averages, planetary extremes) (K); mass (kg); atmospheric pressure (Atm); if they have an atmosphere, its contents and percentages (by volume).
Spaceships:
Mass (kg); Internal temperature (K)
Stars:
Mass (kg); Lifetime (years)
Masses are internally stored in metric teratons so as to roughly center the decimal place between working with small objects like starships and large objects like planets. Masses of most solid objects that aren't known (such as many of the asteroids and some of the minor moons) are approximated by a formula using 10*(radius^3.1), which seems to generally hit pretty close to the mark.
The temperature fields follow a more complicated formula when they're not known; it takes the default distance/albedo code, and factors in the atmospheric pressure to get the mean temperature. The day/night local temperatures are based on the mean, adjusted by how fast the planet rotates and the atmospheric pressure. The seasonal temperatures are based on the daily temperatures adjusted by the tilt, atmosphere, and year length. The global extremes are based on the seasonal extremes adjusted by the size of the object. I adjusted all of these formulas to try and get four bodies for which I know temperatures pretty well (Mercury, Venus, Earth, and the Moon) to match up with their actuals; it seems to get pretty reasonable values for other planets and moons as well. A new field - pressure - was added to the atmosphere section.
For all star fields, I added in some new lookup tables that are similar in structure to the current temperature lookup table.
For adding support for gasses, there are new fields that can be added into the atmosphere section (correspondingly, for the gas giants, I had to add an atmosphere section). These are GasNameX and GasPercentX where X is an integer from 1 to 10 (thus, you can have up to 10 gasses listed; you don't have to fill them all). If your gas percents don't add up to 100%, don't worry, it'll equalize it to 100 for you. The gas names are stored as their chemical formulae, for brevity. All of the information that I listed is accurate, although the percentages may be a little off on some of the trace elements of the outer gas giants, since those numbers were hard to come by.
I'm going to try to track down who to send the patch to... if anyone reads this and knows, let me know and I'll send it. On to my next project: enabling a new class of object that, now that we have masses, can "free-float" around, being tugged on by the gravity of the N nearest/heaviest objects. Naturally, we'll want to keep the number of objects like this to a minimum, as they'll actually use CPU even when you're not near them; hopefully, I'll be able to come up with a way to detect if they've entered a roughly stable orbit, calculate that orbit, and set them to it, thus making them a standard, low-cpu object until something changes again. Regardless, if I can get this to work right, we should be able to model things like gravity assists and simulate spacecraft trips.
Moons and planets:
Surface temperature fields (mean, day and night averages, seasonal averages, planetary extremes) (K); mass (kg); atmospheric pressure (Atm); if they have an atmosphere, its contents and percentages (by volume).
Spaceships:
Mass (kg); Internal temperature (K)
Stars:
Mass (kg); Lifetime (years)
Masses are internally stored in metric teratons so as to roughly center the decimal place between working with small objects like starships and large objects like planets. Masses of most solid objects that aren't known (such as many of the asteroids and some of the minor moons) are approximated by a formula using 10*(radius^3.1), which seems to generally hit pretty close to the mark.
The temperature fields follow a more complicated formula when they're not known; it takes the default distance/albedo code, and factors in the atmospheric pressure to get the mean temperature. The day/night local temperatures are based on the mean, adjusted by how fast the planet rotates and the atmospheric pressure. The seasonal temperatures are based on the daily temperatures adjusted by the tilt, atmosphere, and year length. The global extremes are based on the seasonal extremes adjusted by the size of the object. I adjusted all of these formulas to try and get four bodies for which I know temperatures pretty well (Mercury, Venus, Earth, and the Moon) to match up with their actuals; it seems to get pretty reasonable values for other planets and moons as well. A new field - pressure - was added to the atmosphere section.
For all star fields, I added in some new lookup tables that are similar in structure to the current temperature lookup table.
For adding support for gasses, there are new fields that can be added into the atmosphere section (correspondingly, for the gas giants, I had to add an atmosphere section). These are GasNameX and GasPercentX where X is an integer from 1 to 10 (thus, you can have up to 10 gasses listed; you don't have to fill them all). If your gas percents don't add up to 100%, don't worry, it'll equalize it to 100 for you. The gas names are stored as their chemical formulae, for brevity. All of the information that I listed is accurate, although the percentages may be a little off on some of the trace elements of the outer gas giants, since those numbers were hard to come by.
I'm going to try to track down who to send the patch to... if anyone reads this and knows, let me know and I'll send it. On to my next project: enabling a new class of object that, now that we have masses, can "free-float" around, being tugged on by the gravity of the N nearest/heaviest objects. Naturally, we'll want to keep the number of objects like this to a minimum, as they'll actually use CPU even when you're not near them; hopefully, I'll be able to come up with a way to detect if they've entered a roughly stable orbit, calculate that orbit, and set them to it, thus making them a standard, low-cpu object until something changes again. Regardless, if I can get this to work right, we should be able to model things like gravity assists and simulate spacecraft trips.