# CS 488: Assignment 3

## 'Solar System'

Out: 10/21/03

Due: 11/11/03 at 2:00pm

This third assignment will again be a 3D visualization, but this time we will use solid polygons rather than lines, and we will use texture maps to make those polygons more interesting. What we are going to visualize this time is a solar system, in particular our solar system, but the program should be able to display the other solar systems that are being discovered weekly as well. As in Assignment2 where we exaggerated the depth of the earthquake hypocenters, here we will need to exaggerate aspects of the solar system to make the visualization meaningful.

There is a new shell here that will bring up a small program that will show you two spinning spheres with textures (the earth and the sun) mapped onto them. This code should give you a good starting point for creating your solar system. While there are libraries to load in all of the various image formats (tiff, jpeg, png, etc) we will use 'raw' images for this assignment since they can be read in simply by OpenGL.

Here is the new shell, shell3.c

You will also need to download the earth.raw and sun.raw files from the textures directory linked in below.

Each of the planets and moons and the sun itself are rotating about its axis; each of the planets is revolving around the sun, and each of the moons is revolving around their respective planet. For this simulation we will declare that 1 day of real time = 1 second of time in the simulation, so the moon should orbit the Earth twice a minute and the Earth should go around the sun in roughly 6 minutes. You may be surprised how fast some of the other planets rotate. I was when I first did a C.G. solar system.

There are lots of small objects in the solar system so we will limit the simulation to objects (the sun, planets, moons) with a radius greater than 500 km.

While there are equations on the web to accurately position each planet given a date we will not go into that level of detail. We will just start our simulation with all the planets in a line and let them start revolving from there at the appropriate rates.

Assignment 3 will have two windows, except in this case both windows should be the same size. As in assignment 2 the main window will allow the user to translate, scale, and rotate the solar system using the same interface as Assignment 2 to get a better view of the various objects. The other window will have a camera sitting at the center of the moon and looking at the earth which should give an interesting dynamic view as the objects in the solar system move (that is the surface of the moon should be culled out so it doesn't obscure the view). Both windows should update dynamically as time passes.

We will still use a perspective camera in this assignment, and keep the z-buffer turned on.

The sun should act as a point light source to light up the sides of the planets and moons facing the sun, and there should be some amount of ambient light to be able to see the dark sides of the various planets and moons.

Scale is a big issue on this assignment. While it is possible to create a computer graphics simulation of the solar system where everything is in scale, this unfortunately means that you end up looking at a black screen since space is really really really big. So we will not put everything in scale, specifically the radius of the planets and moons will be in scale with each other, but not in scale with the radius of the sun or the radius of the planetary orbits. The radius of the orbits will be in scale with each other, however. Once you start to get the planets and moons visible you should experiment to come up with a nice scaling factor. You also need to make sure that the various moons do not end up inside their parent planet, or too far away from their parent.

The orbits of the 9 planets should be drawn as white circles. You can assume that all the orbits are circular so you can ignore the eccentricity of the orbits in the datafile. However you should take the inclination of the orbit into account. The orbit of the earth around the sun, by default, is the plane of the solar system. The other planets orbits are all slightly off this plane except for pluto that is noticably off the plane.

You should also take into account the axial tilt of each planet. Each planet rotate around its own axis which is at some angle to the perpendicular to the plane of the solar system. The Earth is only tilted 23 degrees from vertical (which is why we have seasons) though other planets have more interesting axial tilts such as Venus that is basically 'upside down' and rotates backwards, and Uranus which has its axis in the plane of the solar system.

Even with this scaling it will be hard to find some of the outer planets, especially pluto since its so small. To make it easier for the user to find the various planets the user should be able to turn on and off a set of 9 arrows pointing to where each planet is in its orbit.

You may also want to put in a key to turn on and off the texture maps if you have a slower machine, since they can eat up processing time. Another place where you can have a big effect on the speed of the application is in the gluSphere function which specifies how detailed each sphere should be. You may want to play with the parameters to see how much polygonal detail you need. You may also want to have a separate simpler model for the various moons since they are smaller and require less polygons.

The four largest planets in the solar system have rings ... to get an 'A' on the assignment you should come up with some nice way to appropriately show them in scale with the orbits of the moons.

To get some extra points on this assignment, you can use some of the websites that detail extrasolar planets and create data files for other solar systems to show how they relate to our own. A good set to do would be: 55 Cancri, Gliese 876, upsilon Andreomedae (e.g. http://www.extrasolar.net/mainframes.html). Note that you may also want to change the look and size of the various suns of those systems as well. Also note that if you load in a system other than our own you should still show some relevant information about our solar system for comparison (ie the orbits of the various planets in our solar system or at least the Eart's orbit)

The data for the solar system will come from a data file. The actual data changes as measurements are refined, so I'm sure some of the data here is already out of date, but this is the data that we will use. solar.txt

The texture maps are available as well. Each of the textures is 512x256x3 colours. While there are some pretty nice texture maps of the various moons in the solar system, most of them will be too small to see in detail in this program. You should use the moon texture for our moon but can leave the others as just a white sphere. The texture maps can be found here.

Your program should be well commented and be a good example of literate programming.

Your program will be submitted electronically. This will be discussed further in the discussion section. You can compile your program using the OpenGL libraries or any of the implementations of the Mesa libraries, and whatever platform you chose, but be sure that it compiles and runs as submitted on the linux machines in the CS lab because that is where we will be compiling and running your program.

Once you get past parsing the relevant data out of the solar.txt file then the issue is how to manage all the nested transforms. I would suggest starting with the Sun and the Earth since getting the Earth right gets you most of the way there to having a general routine for any planet (aside from only having 1 moon and not having any inclination in the orbit.) Once you have the Earth working I would suggest getting the inner planets in, then the outer planets, then dealing with the other moons.

I would also highly recommend that you understand the code you are writing - you never know when you might need to reproduce it (hint hint).

Also note that shell3.c seems to run fine on the 'graphics' machines in the CS department linux lab - those are the fatter machines in the back of the room - but it does not run on the 'regular' thinner linux machines in the front of the room (you get an illegal instruction when it tries to draw a sphere). I'm guessing this is because of some library incompatibilities on the thinner machines, which I will try to work out, but in the meantime you may want to stick to the machines in the back of the room which have better (faster, stronger) graphics cards anyway