Week 23 - Planet View and Completion!

This week was the deadline I had set myself to complete the program, so - have I managed it?

Just about! I still have a couple of tweaks I want to make, and clean up some code, but effectively the program is now fully functional and as advanced as I am going to make it.

I've changed quite a bit this week, cleaning a few things up - I've implemented arrays in several places where I had lists of variables for each planet, and completely reworked my planet rotation method to fix an error where the planet would stop if the speed became too great. The main addition this week though is the implementation of "planet views", an option on the menu which allows the user to focus the camera on one planet, and the camera will follow along as the planet orbits the Sun.

Firstly, the arrays I've implemented. I've replaced four variable lists with arrays:

Previously there was a model variable for each planet, a size variable for each planet etc, but using an array instead cleans things up greatly, and hopefully improves the program speed a little as well. Example: mercSize is now size[0], venSize is now size[1] etc.

Now, onto the planet rotation. The problem was that the rotation value is given by the rotation amount times the speed factor. When that equals 360, the planet stops spinning. Example: Earths rotation amount is 18 degrees. When the speed factor is increased to 20, the rotation amount is 18x20 = 360, so the planet appears to be still when the speed of the program is at 20 times. Since each planet reaches it's fastest speed when the rotation amount = 180 degrees, I simply worked out when this was for each planet and stopped increasing the rotation amount at that point. It's all explained in the method comments, here it is:

Finally, the planet views. To implement these I had to create 8 new methods in the DrawSolarSystem class - one for each planet, called mercuryView(), venusView etc. I also had to modify the camera controls to use gluLookAt, so I could focus the camera on a position.
 So, in each view method I set the camera's position, and the camera's focus, using the X,Y,Z coordinates of each planet. For the cameras position, I had to move it slightly off the X,Y,Z of the planet so you could see it - I perfected each position by assigning a 'test' variable to be added or subtracted to the Y or Z, and controlled the increments with the keyboard. These keyboard controls are now commented out, and I replaced the test variables with an actual number once I'd gotten the best camera position. I also had to set certain booleans to false so they did not affect the camera. Here is an example of the mercuryView method:

The next step was to add this method into the DrawGLScene method. Since i wanted this view to be activated when a menu option is selected, a boolean trigger is required to be set to 'true' in order for the view to be shown.

Finally, in the menu responder I simply set the boolean for the planet view I want implemented to true (in this case Mercury), and all the rest to false.

I've also included an option to return to the default view, which simply resets the camera and loops through the planetView array, setting all the booleans to false.

I'm going to post a blog following this one, with screenshots of all the planet views.

Save for some minor tweaks, thats the program pretty much finished. I'm really pleased with the end result, and delighted I've been able to implement all the features I wanted to in the desired timeframe. Onto the report!

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.

Blog Week 4 - Design

This week and next will have been spent doing design work for the project. I intend to complete a Mind Map, UML Diagram and Storyboard in this process.

Unfortunately I have been ill over the past week so have not been able to complete these tasks yet. I have finished the mind map, which I will post up, and have made progress on the UML. I intend to complete the UML diagram and Storyboad by the end of next week.

Here is the mind map. It details design methods, initial class ideas and user interface ideas (click to expand):