The idea of implementing a planetarium using a 3-D graphics system is an obvious one. The basic idea is:
With WebGL, this can be done on a web page that anybody can access. With the three.js library, the 3-D part of the programming is relatively easy.
Star data comes from version 5 of the Yale Bright Star Catalog. (The catalog seems to have been captured by Yale's rival, Harvard.) The Planetarium uses those stars with magnitude less than 6. That is 5,024 stars, a bit over half of those in the catalog.
We convert star magnitudes to brightness according to the formula in the Wikipedia Magnitude article. Converting the brightness number to screen values is a matter of judgement which depends on the value chosen for a reference brightness.
Star colors are derived from the B – V color index of the star using a rough method derived from the table in a Cornell Ask an Astronomer answer. I would be happy to know a better way of doing it. The Bright Stars Table also contains the V - I color index, so we could use a method that relies on both.
I read that, viewed from space, the Sun looks white. Going by the RBG color that the Planetarium computes from its B – V value, about half of the Sun's blue light is scattered by Earth's atmosphere (making the sky blue). Therefore, when the viewer is off the Earth's surface, I have doubled the blue component of a star's RGB color to approximate what its color would be from space. So when you are in space the Planetarium makes stars look bluer than the B – V value in the catalog indicates. All this is rather rough, but compare how the Big Dipper looks from space in the Planetarium with the NASA photo ISS006-E-40544, taken from the International Space Station. I think the Planetarium comes pretty close to the photo. In particular, the made-up method for converting B – V to RBG must be not too bad after all.
Most common names of stars come from the Wikipedia Proper Names of Stars article.
For proper planets (not the Sun, which is at the origin, or moons of various planets), positions are computed from their Keplerian elements as given in Keplerian Elements for Approximate Positions of the Major Planets by E. M. Standish. Thanks to the miracle of the WebGL graphics engine, we only need to compute the heliocentric positions of the planets. The WebGL engine does the work of converting those to positions in the sky relative to the observer.
Orbital elements of other moons are taken from Planetary Satellite Mean Orbital Parameters at JPL.
Data on radii, oblateness, and rotation rates of planets are taken from NASA planetary fact sheets. Information on radii and rotation of their moons is taken from the satellite fact sheets linked to each planet fact sheet. But, in fact,
For planets that have an observable longitude – Mercury, Earth, and Mars – I have made the line of longitude zero correspond to the proper place on planet's image, which has always been either the left edge or the middle. I also found a map of Jupiter that gave longitudes and latitudes and followed that for longitude, though I don't know how useful that really is on a planet covered by clouds driven by high winds. For the other planets – Venus, Saturn, Uranus, Neptune – longitude is arbitray.
In any case, except for Earth, I don't have any information giving the rotation of a planet at any given epoch and the rotation rates I have are not especially accurate, so how they are rotated in the planetarium will not correspond to how they are actually rotated, if you have a powerful enough telescope to see that.
Synchronously rotating moons do not have this problem. The line
of longitude zero always points toward the parent planet (at least
in the Planetarium). I have aligned the images of the moons so that
their line of longitude zero goes through the point nearest the
parent planet. When a moon is not an oblate spheroid (all the
smaller moons), I have also oriented its shape so the longitude 0
end is closest to the parent planet.
I have probably got this wrong in a few cases. Send any corrections to firstname.lastname@example.org.
Each planet has its own ecliptic (purple line), indicating the plane of its orbit around the Sun. Declination corresponds to latitude on the planet. The line of right ascension 0 is the line orthogonal to the equator that passes through the planet's spring equinox point, the point where the Sun crosses the planet's celestial equator entering its northern hemisphere.
For moons, I have used the parent planet's ecliptic, since that is still the approximate plane of the moon's orbit around the Sun. I have treated declination, and right ascension as for planets. A moon also has a plane of its orbit around its planet, but in most cases this is very close to the moon's equator, so I have not represented it.
Almost all the moons represented rotate synchronously, once for each orbit around its planet. The Planetarium represents a few moons for which I don't have rotation information (such as Uranus's moons Ophelia, Cordelia, and Margaret). The Planetarium treats their rotation as synchronous, too.
Many of the moons represented in the Planetarium are not very round. For Phobos and Deimos, Thebe, Amalthea, Larissa, and Proteus there are old, not very detailed 3-D models by Philip Stooke, pioneer of the "geography" of small bodies in the Solar System. (I found them on the Small Bodies Data Ferret.) I used these models rather than newer, more detailed ones because they are simple, small, and computationally cheap. When there is a good image of a moon to go with the model (Phobos!), they seem pretty adequate. Even when there is no image, they seem more realistic that prolate ellipsoids.
The Planetarium represents non-spherical moons, with no 3-D model, as ellipsoids with axes as given in the "Bulk parameters" section of their parent planet's "Satellite Fact Sheet" under the NASA Planetary Fact Sheets page. For example, for Jupiter, the satellite fact sheet page is Jovian Satellite Fact Sheet Page.
Planet images (textures) come from various sources.
As of version 3.3, the Planatarium models the speed of light as finite (at 1 AU per 499 seconds).
The main effect is unobtrusive – planets and moons will appear to be where they were when the light left them, a few minutes or hours ago. One may also be able to see a planet turn or its moons move during a "slow" (non-instantaneous) jaunt. One can definitely see those two effects when backing away from a planet using the Altitude control, because it works exponentially.
The Planetarium does not try to model the red/blue shift of light color when moving at high velocity. During a "slow" jaunt, we may be moving at 500 or 1000 times the speed of light, so the shift does not really make sense.
Here are some things the Planetarium is not doing right.
The Planetarium can now represent the colors of stars, moons, and planets, using sound. There is, of course, no sound in space, so this is not actual sound coming from the heavenly bodies, it is just a representation.
To do this, an RGB color is made into a sound by translating it to HSI (hue, saturation, intensity). Intensity (a kind of lightness) gives total volume of the sound. Hue is translated into the pitch of a pure tone. Saturation determines how the total volume is divided between that tone and "white" noise (actually brown or red, or pink noise). High saturation gives a pure tone; zero saturation (white-grey-black) gives pure white noise.
My original idea of adding video was to have the Planetarium itself generate background music, especially for "silent" videos that are generated from a script. But I also find audio to be rather fun, and I hope it may help persons with impaired vision get more from the planetarium.
For now, audio is experimental. Its details are likely to change as my understanding of acoustics, a deeper topic than I had realized, improves.