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!

Week 7 - More Programming

This week I have been working further upon the OrbitalCalculations class - namely, trying to prove that the figures being generated are correct by following through an example from a trustworthy source. The source I used was the following from Utrecht University - http://www.astro.uu.nl/~strous/AA/en/reken/hemelpositie. In getting this result, I have edited the class quite a bit, and will detail those changes later. I have also worked on getting a proper import code, that will allow my program to read in 3Ds max models and their materials.

Firstly, the changes to the orbital calculations class;

• getV has been replaced with getTrueAnomaly, and the variables likewise - so double v is now double trueAnomaly. This was mainly to help myself, I had not realised initially that the variable v that I was calculating was the true anomaly. I also changed the code, to give a more accurate result. I adapted the code from the same resource as the eccentric anomaly code - http://www.jgiesen.de/kepler/kepler.html.
  
• variable perihelionTime has been removed. After discussions with Rob it became clear that the current method of calculating the mean anomaly could not work, as there was very little to no data available on the date of perihelion passage for any planet other than Earth. The new method requires a start time which the orbital elements are valid for (01/01/2000) and the current date.
  
• Using the method of calculation detailed in the Utrecht University website, it is no longer necessary to calculate the X,Y,Z values in two parts, so x1, y1, z1, x2, y2, z2 and their associated methods have been removed and merged into one for calculating x, y and z on their own.
  
  

Now onto the big problem I had in getting the numbers my program output to equal the ones that website said I should be getting - radians and degrees. You see, the computer computes sin/cos/tan functions in radians, and the data I input and want output is in degrees. This gave me quite some trouble, but essentially each variable which is an angle had to be converted into radians before the calculation is carried out, then converted back into degrees if it is returning an angle. What I did was create a variable called k, and make it equal to Pi / 180. This means that multiplying an angle by k will convert it from degrees to radians, and dividing an angle by k will convert an angle from radians to degrees.

I'd like to run through the example on the Utrecht University website for calculating the X,Y,Z position of Jupiter. 

The first step is to calculate the mean anomaly. Here is a screenshot of my new mean anomaly calculation:

The UU website states the result should be: 141.324°

Next, the true anomaly. Here's my new code to calculate the true anomaly:

The result for the true anomaly should be: 144.637°

Next up, the distance to the sun, which is r. My code to calculate r hasn't changed actually, but I did have to convert the true anomaly used in the calculation into radians first.

The result for r should be: 5.40406 AU

Finally, the x,y,z coordinates. I'll post an image of my code to calculate X, the other two are similar. Notice that each angle has to be multiplied by k - this is not shown on the website, and gave me lots of trouble!

The x,y,z coordinates for Jupiter should be: −5.04289, 1.93965, 0.10478

Now, here's a screenshot of my results:

and a side by side comparison. Target results in red, my results in blue.

Mean Anomaly: 141.324° | 141.365°

True Anomaly: 144.637° | 144.036°

r: 5.40406 | 5.40417

x: −5.04289 | -5.04431

y: 1.93965 | 1.93624

z: 0.10478 | 0.104829

Pretty close! I'm very happy with how the calculations are working. 

The second part of what I was working on this week was importing a basic model from 3Ds Max and getting it displayed on screen. This proved quite difficult! The code I was planning to use from last semester proved instantly unusable - it requires models to be of .txt format, and 3Ds Max does not export to this format.

I spent many hours trying and testing different loaders, and eventually settled on an object loader (it loads models of type .obj) called GLM from this website: http://www.3dcodingtutorial.com/Working-with-3D-models/Getting-GLM.html. I imported the files into my project and put them in a seperate folder - this means that the ImportModel and point classes I had made are no longer needed. 

With a bit of tweaking, I've managed to get a geosphere with a material of an alien's face that I created in 3Ds Max, to display in my viewport window. Here's a screenshot:

All in all, some good progress made. 

More next week.