Week 8 - Animation

This week I have been working on the DrawSolarSystem class. I've added quite a lot  - some initial keyboard functionality has been added (zoom, pan, rotate and pause), as well as mouse movement. This is in a very early form and I'm not happy with some elements, but it will do for now! The main focus of this weeks work was trying to implement the orbit of one sphere around another. I managed to implement this successfully, and went ahead to program the orbits for all the planets.

Another issue that was raised during my meeting with Rob was the slight difference in accuracy for my figures in the previous blog. I did some more research, and believe this is down to a difference in time. In the Utretch unversity page, they take 1st Jan 2000, 12 noon UTC as their start date. Their current date is 1st Jan 2004, 0:00 UTC. My program only calculates julian dates using day, month and year, where the time of day is as default 12 noon. This means theres a 12 hour difference between their current date and mine, which is I believe the reason for the slight difference in figures.

Firstly, I'd like to list major changes and additions to the classes.

• the drawOrbit method in OrbitalCalculations has been changed to a type void, and thus doesn't return the planet's vector anymore. I've created a new method to return the vector, so it can be retrieved by the program without doing the whole drawing orbit calculation.
• The Julian Date is defined as a variable julDate at the top of the DrawSolarSystem class now. This allows the julian date to have numbers added to it in order to increase the time.
• Planets are created at the top of the DrawSolarSystem class as well, instead of in initGL, outside all methods. This is so different methods can use them.
• For the same reason, instances of OrbitalCalculations are also created at the top of DrawSolarSystem.
• Two new methods have been added to DrawSolarSystem for camera manipulation. One called camera, and one called mouseMovement.
• A new method has been added to DrawSolarSystem to read in each model, so there are 9 methods of this type in total.
• A new method has also been added to update every planets position, so there are 8 methods of this type.

Now I'm going to run through how the program reads in a model, puts it into a display list, draws that list then updates the planets position.

Firstly the model has to be read in. I use a seperate method for each model, simply to ensure each model is read in correctly. For now I am only using two models - suntest.obj, a yellow sphere, and planettest.obj, a red sphere. Both were created and exported from 3Ds Max. Here's the code to read in the sun model, the rest are much the same:

Next, the models are put into display lists in initGL. Putting the model into a display list means it can be scaled before being called by the drawing method, so it only happens once at the start of the program. As all the models read in are scaled to the same size to fit in the matrix, they have to be scaled again in order to maintain size difference. At the moment my figures are pure estimates, just done to give an impression of the size differences. Lights are also defined in initGL. At the minute, all I have is an ambient light. Here is the code to place the sun model into a display list (note: the scale is so small so that I can zoom greater distances, you'll see why I need to later!):

Now before I call the display list in myDrawGLScene, I need a method to update the position of the planet. Since myDrawGLScene is redrawn all the time, a loop is not required, as the update method will be called each time the scene is redrawn. So all I need to do is increase the julian day every call to the method, draw the orbit and translate the model by the x, y and z coordinates generated. Here is the method for mercury:

Now the display list can be called in myDrawGLScene when the model is drawn. Here is the code for the sun and mercury:

All this resulted in the following screen shots. The first image shows the Sun, Mercury,Venus and the Earth. The second is zoomed out slightly to include Mars. The third is zoomed out a lot to include Jupiter, Saturn, Uranus and Neptune. As you can see, the distances all look to be in proportion, with a lot of zooming out required to see Neptune! At the moment it looks a bit 2D, but thats due to the fixed angle and lack of lighting to give shade. Note that all planets are reading in the same test model, which is why they are all red.

Thats it for this week!

Blog Week 5 - More Design

This week I have been focusing on producing a UML diagram showing my ideas for class content and class interaction. I've also made a short storyboard, showing how I envisage the final user interface to look.

Firstly, the UML diagram (click to expand):

As you can see, there are 7 classes; main, vector, point, ImportModel, CreatePlanet, OrbitalCalculations and DrawSolarSystem.

The main class just initialises OpenGL and creates the window that the program will run in. Vector and Point are simple classes - the models imported will be constructed of type point, and the X,Y,Z coordinates generated will be of type vector. The ImportModel class will allow 3Ds Max models to be imported and drawn in the program using OpenGL. At the moment I am intending to use the same import code as I used in an OpenGL module last semester, although I am not entirely sure if this will work - I will address this problem if it arises.

The CreatePlanet class creates an object with all the required planetary information needed for the orbital calculations - such as the eccentricity, semi-major axis value and the period of orbit. The UML diagram indicates that the planets would be created in the OrbitalCalculations class, but this is something I am unsure of at the moment. It may be better to create them in the DrawSolarSystem class.

The OrbitalCalculations class contains all the necessary calculations to generate the X,Y,Z coordinates needed. As time updates, so do these coordinates, and thus the planets orbit is drawn. The key method here is the drawOrbit method - this requires the current time and the time that the Planet was last at the point of perihelion (the closest point on a planet's orbit to the Sun) to be passed down to it when it is called. This means that if this function is placed in a for loop when it is called in DrawSolarSystem, with the currentTime increasing every loop, the planet should move in the correct orbit.

Finally the DrawSolarSystem class is where the actual drawing to the user inteface takes place. This is where the models will be imported and positioned, as well as all the user interface features such as zoom and speed up will be implemented.

I have made some simple storyboards to show how I see the user interface taking shape (click to expand):

That's pretty much it for this week. Hopefully next week I will be able to make a start on coding!

Interesting Link:

http://www.jgiesen.de/kepler/kepler.html - contains a JavaScript calculator to calculate the eccentric anomaly, as well as the true anomaly. Also gives the code for this calculator.