Find this document at http://cheer.math.edu/reulab/web/wldavis

Base Modes:

Base Mode 1:

This project is being developed in concert with Mike Hutches' project, a program to simulate the Voyager Mission through the Sol System. This addition may add the opportunity for an Auxiliary Mode, which is similar to Base Mode 2 but follows a predetermined path - namely, the path of the Voyager - with the same feature of variable time present in the system. Also, the data collected under Mike's project will be essential in initializing the solar system accurately to a given time, which, as a further option, may be provided by the user (although it will most likely be restricted to the past). Reasonably, it should follow that the planets in each viewing mode will move in their correct orbits according to time.

Here are some examples of pictures that will be mapped to their planetary
spheres:

Earth

Jupiter

Saturn

**Update 4-28-08:** It turns out that for our image mapping to work onto a
gluSphere() (in its simplest form), we require .raw image files, not .png or
.jpg (although this is possible with extra libraries). Thankfully, ^{1}
UIC has a tutorial/homework assignment for just such a thing with all the
necessary .raw files, and a description of how to use them.

**Update 5-4-08:** It turns out this method of texture mapping is very
inefficient, as it creates a set of mipmaps for every texture for every step the
texture is drawn, which results in quite a slowdown of the program. This is
currently the greatest barrier in advancing illiSol to the "next level." If any
more work is to be done, it should be to integrate the texture mapping with
the Syzygy environment so that it can be done *far* more efficiently, and pave
the way for more improvements on the features and structure of the program.

Fortunately for us, a precise guide to calculating planetary positions is available online, courtesy of Jet Propulsion Lab at CalTech

It is fairly commonly known that planets generally follow a slightly elliptical orbit around the central body. An exception is Mercury, which has a much higher orbital eccentricity, and the comets in our system, which have a very high eccentricity. However, the plane that these bodies orbit in are not the same for each orbiting body - which is why we need a third coordinate to describe its "inclined" position. However, dealing with non-uniform orbits as such introduces a certain amount of complexity. The way we can deal with this complexity is solving it in a piecewise fashion.

By now we have determined that the plane of orbit is inclined from a

Because each orbit is unique and elliptical, we want to orient it in a useful way. To do this, we need to know a little bit about the characteristics of elliptical orbits (this next section assumes some prior knowledge of ellipses).

We can see, just from visual observation of our solar system, that not all orbits are oriented in the same way. Often, we define a sort of longitude in the reference plane, and we need a zero longitude. In our solar system, and hence in this project, the zero longitude in the reference plane is given by the point of vernal equinox, the point in the Earth's orbit when the equatorial plane of the Earth is in orbital plane and the Sun is shining directly at equator. For satellites of orbiting bodies, the reference direction is, for general purposes, parallel to the Vernal equinox vector. Interestingly, JPL has given us what they call the

The next two orbital elements used in position calculation deal with a sort of approximation. These are the

To continue the calculation, we need to find the

The resulting angle from the semi-major axis to the point where the line intersects the auxiliary circle is the eccentricity angle

Now that we have the eccentric anomaly, we can finally start to compute our coordinates. First, we find the heliocentric coordinates in the orbital plane, with the central body at the origin and the

We can then translate this position the reference plane, which the JPL documents refer to as the J2000 ecliptic plane. But once again, this is fairly straightforward since we know all the relevant angles describing our orbit. These equations will translate our planetary position for us:

See the JPL Documents (linked below) for more equations and detail.

And that's it! We now have compact way to calculate the position of any of the planets in the Sol System, and even some of their satellites, given only the date in a range from 3000 B.C. to 3000 A.D.!

It just so happens that the way this application is structured seems to mesh perfectly with how OpenGL works. To demonstrate this, let's provide a typical example. Let's say we have a planet that is in orbit around a central, stationary (for the purposes of this application) star. For further interest, let's say that our planet has a moon, as in the crudely-drawn diagram above. Let's examine how our system moves, starting with the smallest element - the moon.

However, as one can see, because of 2), the moon is

The way OpenGL works is through, essentially, matrix multiplication. The OpenGL design takes each pixel, applies a set of matrices to it, and immediately sends it out to the display (see Dr. George Francis' paper on Real-time Interactive Computer Animations here for deeper details)

Essentially then, we theoretically can have infinitely many levels of orbit. In other words, we can have satellites that have satellites that have satellites that have satellites... and so on, where the only limit would be the amount of stack memory allocated to the OpenGL process. This is because we apply each transformation matrix one at a time. For instance, we apply a single transformation matrix for a planet to put it in its orbit, and we then draw the planet. After that, we apply another transformation matrix and then draw the satellite. In this case, the planet would only have one transformation matrix applied to it, while the satellite would have both matrices applied to it. This is possible because of the

As seen in the Mathematics section, we first obtain the heliocentric coordinates of each planet it its own orbital plane

- All of the major planets in their proper orbits (sorry Pluto, you were the weakest link).

- A system that changes with time - the rate of change of time is variable, but always increasing. The initial date for now is August 20, 1977, around the time of the Voyager 2 Launch.

- All of the planets, and the Sun, now have surface images mapped to their respective spheres. Saturn also has a few rings to distinguish it.

- I now also have the ability to toggle magnification on and off. The planets are magnified by 100x and the sun is magnified by 5x. The distances between the planets remains the same, regardless of the state of magnification. Any larger value of magnification for Sol would engulf Mercury.

- The most recent touch was to add the date to the window text. The user can now see the Julian Day Number as well as the current date in the Gregorian Calendar, to get a sense of how quickly time is advancing.

I have also decided to remove the option of drawing the orbits of the planets into the Solar System. This becomes fairly memory intensive and and at least doubles the computational load on the machine. Since the application itself is already fairly resource intensive and not running as quickly as I would like, I have decided to focus my final efforts on optimizing the current computations and graphics rather than adding to the problem, which will most likely be magnified in the CUBE and CAVE anyhow. Also, because of time constraints, it will not be possible to complete viewing mode 3 (reference above).

Here are some screenshots of the progress thus far this was taken running on a quad-core processor with 4GB of RAM, running Windows Vista. You can see the frame rate as around 20, whereas, for comparison, on a normal dual-core processor with 2GB of RAM running Windows XP, the frame rate ranges from 7 to 12 fps.

illiSol: Earth

illiSol: Magnification Off

illiSol: Magnification On

To download, right click on the link and choose "Save Link As...":

Windows Executable and Data Files

Source Code, Compiling Instructions, and Data Files

To download, right click on the link and choose "Save Link As...":

Windows Executable, Data Files, and .dll files - illiSol can now be run on any Windows machine without Aszgard.

Source Code, Compiling Instructions, and Data Files