Changelog

Last thoughts...   11/14/08 3:23 PM

The "gravity" that I'm actually done hasn't quite set in yet, but I found this, and thought it an appropriate closing: more animals

Scilab Scripts/API   9/29/08 9:55 PM

The API is finally done! We have extensible bodies, camera views, and swappable Scilab scripts. Everything is now following the Object Oriented paradigm (yes, it was that sloppy before), and is using the Model View Controller architectural pattern, which makes for easy API creation/usage. Here is a partial UML diagram that I drew up to convey the overall idea of the thing: Enjoy!

API Coming Along   9/28/08 9:51 PM

Today I was able to finalize the separating out of the camera functionality from the actual simulation script. One thing I forgot to mention yesterday, was that I also modularized the Simulation script, so now everything is a class! I made a UML diagram too to hopefully help with the overall concept of everything. In addition to this, I also altered the front page of this website here to offer a downloadable .zip file that contains all the source needed to get this project going on anybody's machine. I will upload a new version every time I'm finished working on it for the time being, and the date on that will be updated as well, so you can know if it's a newer version than the one you previously downloaded.

Extensible Cameras   9/27/08 5:31 PM

I've separated out the logic of the cameras finally, something that had been looming for a long time. Now, we've got two of the main 3 features extensible. The two that are extensible now are the bodies and the cameras. Now, we have to give the user the ability to choose which ODE solver to choose. This one should be the easiest, really. How I plan to integrate it with the rest of the project, since it is a scilab script, is to let the user choose which script to use from the user interface. The UI will then employ whatever the user choses for the body calculation, and then the display script will read in the position values like it always has, in additon to any new features that the user specified. More work to follow later tonight and Sunday.

Camera Views   9/23/08 8:50 PM

You can now zoom in on a planet without clipping it! If you go from normal mode to scaled mode, the camera moves back also, so it won't clip the scaled body. If we leave the camera where it lies in the normal body mode, once we switch to the scaled mode, the camera would be inside the planet. That doesn't do us any good, so I fixed that.

Givens Rotations/API   9/21/08 7:22 PM

Last time, I was having problems with the orbit of the moon rotating in the opposite direction that it should have been. That has since been corrected, however the eccentricity of the moons orbit is still much higher than it should be. I don't know what's happening there. Since I couldn't figure that out after brooding over it, I decided to tackle the big task of re-writing my code so it's "API-friendly". At first I felt like I would keep hitting brick walls, but finally I've got one aspect of it down - which is being able to derive from a base "Body" class, and using inheritance, derive a subclass that can override the various methods such as draw(), and create the different shapes that one might need. In order to have these subclasses interface with the actual simulation script, I created a "wrapper" body class that allows us to keep our different subclasses in an array together, and call the common methods that all of the subclasses will have. To get a bit more detailed, I have one "BaseBody.py" class that is just what you think it is, which is the base class for a body object. Down the road, when someone wants to describe a different shape to a body, they can create a new class derived from "BaseClass". For the sake of argument, we will call our new class "SquareClass" (mainly because I've already created "SquareClass"). This class over-rides the draw() method of the base class, and instead of drawing a sphere, it draws a cube. Say we want to draw Mercury as a cube - we would open the project and edit Mercury's attribute for bodyClassType, which will be the name of the class that we want our planet to behave as. When the simulator reads in the bodies for the first time, the BodyWrapper determines which class to instantiate, and the simulator goes on as normal. All of our planets besides Mercury will be spherical in shape, while Mercury itself will be a cube. Voila! API for bodies can be scratched off the list!

Givens Rotations   9/17/08 11:21 PM

I got it working!! Well for the most part. I'm having problems with bodies that have parent's other than the sun. the orbit of the moon has a high eccentricity, and is going in reverse. LOL I know I'm computing the velocities wrong, but at least the moon is orbiting the earth now. The first couple of attempts, the moon was all by it's lonesome.

Installation/Z-Viewing distance/Clipping   9/17/08 12:28 AM

One thing that I forgot to mention in the last post was that I went through all the steps to install everything needed for this project on a virgin system. I did make a document, and I believe this belongs somewhere within the thesis, I just don't know where. I detail exact steps for everything. I'll post it on this site sometime in the files section. It's not too involved, which made me very pleased. I got Dr. Schubert's idea on using the Givens rotation matrix to alter the initial conditions of the bodies. I haven't implemented it, but did spend some time making sure I understood what is to be done. I suppose I should look into how the Givens rotation actually works also. I spent much more time on gluPerspective(...) this week than I wanted to, but it's starting to pay off. After more work with it tonight, I know I'm definitely going in the right direction. I got a pretty cool screen-shot of the earth/moon/sun in a cool configuration ((I thought)), but alas, it is lost. If I manage another cool one, I'll post it.

The Benchmarkers   9/15/08 10:07 PM

I spent a whole lot of time this weekend benchmarking different things. I benchmarked how long it took to calculate two, three, four, and five body problems. I benchmarked how long it took to go through a complete simulation of 2 - 5 bodies without trails, with 1000-step trails, with 1000/number of bodies trails. I realized that the trails were just taking too long, even doing them partially. So, I took it upon myself to re-evaluate how I was getting the trail coordinates. I was opening a file, reading in the values, and closing the file for EVERY DRAWING OF THE PAGE. D'oh! Of course that's going to be slow!!! So, instead of doing those horrendous operations for every drawing, I decided to read in the coordinates, and stick them in an array from the get-go, and just use the array to get the values I need. Ha! What a difference. Hellooooooo Capitan Obvious! (me) I also tinkered around with the camera views, and the clipping issue. I'm trying to find a good way of stopping the clipping from happening - I've tried a few things, and it's still not working to my satisfaction, so I'll keep at it. I think I just need a fresh set of eyes on it tomorrow, and it'll pull through. I'm also going to need help on the structure of the written part to thesis. I don't know if I should stick with the thesis proposal structure or what.

Correct Velocities   9/11/08 2:19 PM

Alright! So, here's the deal. I set up the animations to start at aphelion, but I was using the mean velocity values from the NASA website, and that is incorrect. The velocities that should be used are the velocities of the bodies at their aphelion, which in some cases (Mercury) are VERY different from the mean velocities. So, if you look at the screenshot from a couple posts earlier, then you'll see the old trajectories. In this photo, you'll see the correct trajectories, a result of using the correct velocities:

Benchmarking   9/9/08 12:11 AM

Well, I thought this would be much easier than it has been. I didn't have a problem at all with the scilab functions tic() and toc(), and was able to get the times it took to compute the position calculations for different celestial body scenarios. The animation posed a slight problem, however because as of right now, once the simulator runs out of plot points for the bodies, it throws an error and exits. I was finally able to creatively time the simulation tonight though, but not enough time to test all scenarios. I also was able to determine the velocities of the planets at aphelion and perihelion. My calculations were off, however, because I failed to remember to convert from kilometers to meters! I'll fix this though, and hopefully the simulation will render a more accurate path for all bodies involved. I looked into the "Orbital Inclination to Ecliptic", but didn't get much further than the NASA values for each of the planets. I'll have to figure out how to apply that into the equation, because even though the simulation is 3-D, I'm still only calculating in 2-D and plotting on the x and y axis only. I'm sure it can't be that much harder to incorporate that into the whole program, but then again... I *have* said that before... happy birthday to me

Textures   8/30/08 5:22 PM

Textures are working! It seems to either be an all or nothing sort of thing. I mean, if all planets have textures, then everything renders beautifully. If one planet has a texture and the others don't, everything renders ok, but take on the color of the textured planet. There should be a way to fix this - for instance, changing how the library renders the final RGBA values. I will look into that, but for now, feast your eyes! What you see here are the sun, mercury, venus, earth, and earth's moon.

Camera Views   8/28/08 9:30 PM

It keeps getting better and better, folks! I'm batting 1000 in 3 of 3 days! Yesterday, we got the tracer's working, and now, tonight, I've got the camera views doing spectacular things! You can move forward, backward, left, right, and up and down, which enables different views of the orbiting bodies. If you get confused with where you are, you can reset the view to it's default position. You can still change to different views of the planets by the '+' and '-' symbols also. More to come tomorrow...

GL_LINES   8/27/08 9:54 PM

Regarding the tracing of the planet's orbit, I was making it absolutely harder than it had to be. At the suggestion of my committee, I tried the most simple approach to creating the trace - by simply drawing a line. To my surprise, it worked better than I thought it would! The animation still starts lagging after a half-orbit of the Earth. I tried drawing the lines on intervals of 30 seconds instead of one second, and the animation is a tad bit choppy. As the planet gets re-drawn every second, and the trail gets re-drawn every 30 seconds, there is a bit of time that elapses where the trail is not visible, then grows abruptly. I would really like to draw it every second like the planet, but even every 30 seconds or even 300 seconds, it doesn't make enough of a speedup to be tolerable. I am happy that I got the trails ((kind of)) working for the time being though.

Copy To New Project   8/26/08 10:30 PM

I'm glad I decided to abandon the whole "body trail" thing, because tonight was a smashing success, and I feel renewed and validated. I added the functionality to be able to copy an existing project, and make a new project from it. The reason for doing this is to be able to create slightly different projects, and compare their histories to determine how different the system will behave given different tweaks. The feature asks the user for an existing project directory, which gets tested to make sure it's a project directory(by testing the project file within), and asks the user for the new project name. With this information, we create an exactly identical project, meaning that we create the new project folder, create a new project configuration with the updated project path information, and copy all of the body definitions from the old project to the new. Happy day!!!! Now for sleepy sleepy time!

Back In The Saddle   8/25/08 11:23 PM

Well, after the whole family surgery fiasco, I'm back. I'm still in pain, but it's becoming more and more manageable. So manageable that I was finally able to sit down with thesis yesterday and today. It's almost like riding a bike, I feel like I jumped right back into it with no problem, only I'm having problems. Currently, I'm working on trying to get a visual trail of the path that the body in question is taking, so we can see how the path varies with numerous passes around the sun. I haven't gotten very far, and I think it may be my lack of knowledge of the OpenGL libraries. I did try rendering a sphere every 60 instances or so, which did give a nice dotted visual of where the planets have been, but rendering an object for every instance consumes resources to the point that when the Earth gets halfway around it's orbit, the animation starts crawling. So, I think the trail is going to have to me much more mathematically intensive - and what I'd really like to do is use just one object and alter it as the body moves. I have been searching and reading, however, and have come up empty handed so far. I was thinking of using a GL_QUAD_STRIP object to create a trail polygon by polygon, but there has to be a better way. I think I'm going to temporarily abandon this, and move onto something different for now.

Tracer Line #2   8/3/08 9:40 PM

I think I've finally got the tracing ((kind of)) working, but it's definitely too slow. I have to come up with a better way of doing things, because with just two bodies, it takes for-e-ver.

Body Tracer   7/31/08 10:04 PM

Got started on adding a line (or other openGL object) that will depict the trajectory of all bodies involved with an animation. I've got the structure of everything done, but am hitting some walls with getting it to render. I'm sure I'm just over-looking something. I'll work more on that tomorrow.

Project Path   7/28/08 10:48 PM

Added the absolute path to the project's project file today. I'm still stuck on how to get the dang thing to run using the scilex command. Not having much luck here...

Comments!   7/27/08 4:57 PM

I got the comments working in the body configuration files, so now, we can add comments on any line using the '#' as the comment character, in both Python (it was already built into the Python configuration module), and also in Scilab (which was not built in)!

Project Type, Utilities, and Exponent Notation   7/22/08 11:26 PM

Since last week, a few advancements have been made. I set out to work on adding a 'ProjectType' field to the project's configuration file, and also to see if exponent notation could be incorporated into the body configuration files. I ended up doing just that. I added the 'ProjectType' field to the project file, which will be the indicator that the file is actually a project file vs. a body configuration file. I also added all of the logic to implement this feature, allowing the user to only open project files. They are restricted from opening any body configuration files as a project file. Incorporating the 'e' notation for very large or small numbers worked like a charm. I'm embarrassed that I didn't try that earlier. I added a Utilities.py file that houses generic Simulator functions. I also added a directory to house the body position calculations that the python file uses in order to plot the bodies. They were just floating around, so it's just a little bit more file structure, which is always good. Another big one is that I added an 'Add New File' feature, which starts out by asking the user what they'd like the name the new file. The named file is automatically saved, added to the navigation tree, and creates a body template in the window, making it available for editing.

File Editing and Menus   7/15/08 9:42 PM

Since last week, I feel like I've gotten quite a few things accomplished. To start things off, I'd like to share with you, a screenshot: I feel it to be somewhat important to not let people do things that they shouldn't be doing. This is a whole bunch of work, but hopefully it will alleviate a little bit of confusion. To start off this quest, when the application first starts, I only allow people to Open Project, create a New Project, or Exit the application. After creating a New Project or Opening a new one, the files get displayed in the project tree, which is nothing new, but now you can EDIT THE FILES! I know.. it's exciting! Not only can one edit the files, but you can also save and delete them too. This is still in the dangerous phase, as you can delete the actual project file, which would be bad. Well, bad if that's not what you intended to do. When you delete a file, not only does it disappear from the project tree, but if it exists in the tabs, it will disappear as well. You can exit the application via the fancy File --> Exit button now too. Horray! One more thing that deserves honorable mention is that when you right-click on a file in the project tree, a fancy(small) menu pops up, and allows you to delete and open the file in question. The work that I've done in the past week really paid off I think. I'm satisfied. I deserve to go to a concert, and bang my head until the sun comes up!

New Project   6/24/08 11:08 PM

I was able to pull myself together, and add the project addition component of the simulator. So, now we can effectively add a new project, which means that we let the user choose the directory in which they wish to put their project, we create a new folder with the new project name, and we also create a configuration file, also with the project name that contains various info about the project. Right now the only information that we are concerned about is the duration of the simulation. That's all working now, what I have left is to make the main program recognize the newly created project, and be able to start adding celestial body info!!

Update   6/20/08 7:52 PM

I really must get better with posting here. Since the last time, I have gotten my Python script that draws the bodies [dynamically] working! Not only have I done that, but I have also started using a Python library called wxPython to create a central desktop application that currently only runs the scilab script to calculate the positions of the body configuration files in a hard-coded directory, AND runs the Python script that draws the planets dynamically. So, I'd say that is a good deal accomplished in little over a month. The goal now, is to continue to build on that central application to allow different projects to be added/edited, as well as editing the actual planet configuration files themselves. I will try to post more frequently to keep you painfully up to date. ;-)

I got it.   5/14/08 9:05 PM

I found that the equation was the source of the weird numbers! I was missing a very important piece, and feel embarrassed that I missed it. So, I did get it working, and I decided to test the app a little bit further by throwing Venus in, and it was a success!!! Now, I want to configure my python script to draw everybody easily, and dynamically! We're on our way!!!

It's been awhile...   5/12/08 11:24 AM

I know it's been awhile since I've posted, but that doesn't necessarily mean that I haven't been doing anything. Since the last time, I have done quite a few things actually. Here's the breakdown: After converting everything to AU for the simulation, I turned my attention back to the Scilab scripts, so I could generalize how I compute the ODE for gravitational motion. In order to accomplish this, I first had to find a way to configure an arbitrary number of bodies (planets or comets), which I did with a python configuration script. In order to read the python configuration files for each planet, I had to write my own scilab functions, so I could use the values in my ODE solver. Once this was completed, I generalized the actual function, to take an arbitrary amount of bodies, which took quite a bit more work than I was expecting, but in the end I believe I got it right. Now, I'm in the process of testing everything. I did run into what we all thought was a "bug", however after this weekend, I see it was faulty input data (AGAIN! ARGH!). So, the values I'm getting for the Sun/Earth/Moon system are very close to that of the hard-coded scilab script. Now, the obstacle that remains is finding out which value I have to tweak in order to get the correct values. It could be that the equation computation is wrong, so I'm going to look there too for the solution.

AU   3/31/08 10:33 PM

I converted all measurements to AU instead of meters, and everything renders beautifully! No rings, no lines - just solid, beautiful, spheres. YAY!

Testing   3/20/08 5:08 PM

This is a test of my new rss feed for thesis.

Scaling   3/19/08 9:06 PM

I decided to abandon the textures for tonight, and try the scaling. I tried to scale everything down by multiplying it by 1/AU. (AU = Astronomical Unit). I thought I covered all my bases, but apparently I didn't because - SURPRISE!! - that's not working either. I think a re-visit of the entire code thus far is in order. It's getting messy, and there just HAS to be a better way - a more modular approach. I'm exhausted. Time for bed.

Textures pt.2   3/18/08 11:53 PM

ARGH. 3 Hours, and I'm in the same place I started. :-( Well... I do have this - I just can't seem to apply the texture to the actual animation:

Textures   3/17/08 10:54 PM

Much work has been done on textures this past weekend, and the latter half of today. I've done much reading, and through much trial and error, I almost have a textured sun. I was able to utilize some past tutorials and my single sphere attempt which yielded pleasing results, and now I'm trying to apply that to my file with the "real" data. Just a side note - it doesn't seem like one can use the "glutSolidSphere" while texturing. I ended up having to use the gluSphere in order to render my singleton sun. I believe I almost have this working in the actual file. More on this tomorrow, and hopefully I can get more scaling options thrown in for the user!

GLUT_KEY_UP   3/4/08 10:08 PM

After much fighting with camera position, I decided it was time to add controls that would allow the user to navigate themself. They are certainly not refined, but they are there after a whole lot of headbangin'. Turns out that one needs to utilize the "special" key function in order to recognize the arrow keys. Horray for stubbornness! At first I thought there was some python char(int) function that equated to the arrow keys, but those are generally ascii integers, of which the arrow keys are not included. It's a special GLUT constant as well as the glutSpecialFunc(function) needed in order to recognize those special, special keys.

More PyOpenGL   2/21/08 12:32 AM

Well, PyOpenGL is promising to be very much like the regular OpenGL library for the C++ language. It seems as if it's almost a direct mapping between functions, only the syntax is different. Anyhow, I finally was able to render our planets with this new library, and am working on the animation. I think I have everything in the right place to execute an animation, however something is wrong. It's not animating! It has to be a minor oversight. Hopefully we'll have a pretty cool rendering soon.

PyOpenGL   2/18/08 2:56 PM

As of the last meeting with the professors, my objective for the week is to eliminate the "flicker" that is happening with my animation due to no buffering, as well as make the whole system easier to view. So, over the weekend, I decided to look at different graphics packages to integrate with python mainly because the package that I am currently using - VPython is just not robust enough to do what I want my animation to do. I decided to go with the PyOpenGL package mainly because I'm familiar with the OpenGL library already, and I know that I will be able to control the things I must submit for this week's meeting. I finally got to the point where I *think* it's installed, now it's just a matter of figuring out how to put the puzzle pieces together. More later...

Success!   2/6/08 2:55 PM

Well, kind of. Using the equation for n-body I've succeeded in getting both the earth and the moon to orbit the sun. Obviously this shouldn't be the case - as the moon should be orbiting the earth rather than the sun, however after much frustration, I think I'm on the right path. Lunch break was up 45 minutes ago, so I'll try to get this running tonight. Hopefully I'll get a streak of luck, and will be able to get it working relatively quickly.

Error!   2/5/08 11:51 PM

Ohmygosh I found an error in the simple 2-body equation that I had written off as being ok! Through stydying the n-body equation, and trying to get that to work, I realized that : Was supposed to be: . At least that's cleared up. On to n-bodies!

N-Body   1/30/08 1:28 AM

Using the mathematical formulation of the n-body problem found on wikipedia, I tried to solve the problem of the sun/earth/moon case. This hasn't turned out for me so well, as I'm having problems getting the correct results. I've tried just about everything I can think of. Hopefully more luck soon.

Three Bodies   1/29/08 8:19 PM

I'm working on a three body problem consisting of the sun, earth, and moon. I *believe* I'm using the correct equations, but I'm not getting the correct results. I'm going to keep at it, and see if I am doing the right thing or not, and try to get it to work!

Progress!   1/17/08 12:05 AM

There was an awesome breakthrough in last weeks meeting - we actually got the NASA numbers to work! So, the next task I took on was two planets orbiting the sun, which turned out to be trivial. After that, I decided to take on the problem of the earth orbiting the sun, and the moon, in turn, orbiting the earth. This proves a little more difficult, but I think I'm on the right track. I'm getting division by zero errors, so I must not have something right. In the meantime, I have uploaded new files of the Earth/Sun/Venus code, complete with simulation! Enjoy!

Analyzing Data   1/7/08 11:47 PM

Well, I'm still trying to work out what is going on with my data. It seems that once RK4 goes through one iteration, the values jump by many orders of magnitude in the negative direction, and they keep getting larger and larger. I feel as though the RK4 method is not to blame, but my initial conditions perhaps. Maybe another method would suit this problem better, but I would like to continue to explore RK4 until it's completely exhausted.

Runge-Kutta 4th Order revisite   1/5/08 3:52 PM

I spent a good bit of the day just studying this method, and trying to figure out what parts I can improve upon for my particular problem. In order to do this, I implemented this method for use in the initial, and more simpler problem we were first working with. Next, I will analyze the data, and try to see where the method is failing with the immensly large and small data.

Kinks Worked Out..   1/2/08 9:22 PM

I managed to get all the kinks worked out with my implementation of Runge-Kutta 4th order, and am actually generating output. The data generated, however, is not correct. Next step is to determine how to modify it in order to arrive at the results we desire.

Runge-Kutta 4th Order   12/27/07 11:02 PM

I managed to dig up one of my old CS535 Runge-Kutta methods, and am in the process of re-visiting the concept so that I understand it. I am also starting to incorporate this particular ode solver with our current n-body problem. Now, it's just a matter of working out the kinks and bugs in my implementation of Runge-Kutta fourth order method, and finding out where the library routine fails, and tune accordingly.

Python   12/4/07 10:41 PM

Frustrated with not getting anywhere with 2Body.sci, I decided to start getting to know Python a little better.

Stuck!   12/3/07 11:04 PM

Tonight I spent a great deal of time working with the revised version of 2Body.sci from Dr. Schubert, trying to get it to integrate! No luck for me today.

ODE   11/28/07 8:02 PM

Refreshing my memory on how to set up this problem with the CS535 book, hoping it would give me insight on how to get more reliable initial conditions for my problem. I also cleaned up the code, and left it well-commented. Posted the 3-body simple solution on the site along with the python file to accompany.

Initial Conditions   11/26/07 10:07 PM

More work on the NASA values today, and I've narrowed the problem down to the initial conditions I've been using. I think this is the problem, anyhow. Following examples, I set the x(0) value to aphelion, and y(0) to zero, x'(0) to zero and y'(0) to many different things, all of which didn't work very well. I was trying to simply use educated guesses, but realized today that this is something that I should absolutely not be doing, and need to find a way to calculate more reliable initial conditions.

NASA Values   11/25/07 11:59 PM

I tried to input the statistical data of the planets from NASA into my program, to no avail. It doesn't like the large mass values of the Sun in particular, and if I introduce a third body (second body orbiting the sun), it all falls apart, which is why I dumbed down the three bodies to two. More work on this tomorrow.

Installers   11/25/07 2:18 PM

Started keeping a log of all installers needed to execute this implementation of thesis content, and added all listed installers to the code repository too for easy access.

Two Bodies!   11/17/07 9:34 AM

Current implementation includes two bodies orbiting one stationary body. Their orbits are calculated correctly, but still need to implement their correct initial conditions, and take into account their mass.

Camera View   11/14/07 1:40 PM

Changed the camera to not auto-scale, and positioned the camera to look at the center of the animation. No funky camera views anymore.

Change Log/Repository   11/12/07 1:55 PM

Changed the text formatting of the change log to be more streamlined. Formatted date. Last night, created a Subversion repository with Google Code. The link to this particular project's source code can be found here.

Website / Change Log Created!   11/11/07 7:55 PM

Main structure of website done. Data access to change log, and extraction of data to the main page of website completed also.