Most of the work on my project has taken a backseat to my presentaion. The last big implementation I have put in place is tying my gui in with the size and color of the central star such that the user is introduced to a mass selection gui at first and can see how the star grows and changes based on the number of solar masses they input. The mechanics behind this came from another piece of collaborative work with Dr. Olson. Given a selection of Main Spectrum stars I was able to draw relationships in excel between mass and temperature and luminosity of a star. Given the equations these graphical relationships yielded I was able to use the equation L = R^2 * T^4 to take user mass input and show them a real time object for their star with a color and size. This is one of the final pieces I will implement before my presentaion which I have been working very closely with Dr. Olson on to make tweaks. Wish me luck!
I've made a lot of good progress this week on improving my gui and adding in small useful features. I have switched from a log scaling feature to a square root scaling feature with Dr. Diederich and Dr. McVey's help and can now manage to fit 8 of our planets on screen which is about as large of a scale as I can imagine a user wanting to use. I have successfully implemented an Astornomical Units conversion window in my 'New Planet' interface so the user can get a better feel of the position and velocity they are inputing in relation to earth position and velocity units. I have also implemented a floating statistics interface for individual planets so the user can see their changes in real time. In addition, I am finally finding success in putting in an orbit tracing feature which traces a line to follow a planet's trajectory which I think will be useful in tracing orbital precession once the user gets a hold of editing orbit motion. Once I implement this feature (and deal with memory and scaling issues) I want to add in a 'suggested velocity' window to my 'New Planet' interface which calculates an initial velocity which will keep the user's planet in orbit given their initial position and give the user the ablity to select this pre-calculated velocity to use. Many new features are coming soon, I'm happy with where the project is and the progress I am able to make now that I have a good handle on how my interface/algorithm model wants to work and plan on taking advantage of this to make it as smooth, dynamic, and easy to use as possible.
This week has been all about stitching up my UI. I met with Dr. McVey and Dr. Diederich last week for the last patch up of my physics engine only to discover that it was operating exactly as expected. So... pending some final bug testing I have a working engine which can handle any parameters the user throws at it. As has been the trend the last few weeks, then, I continue to make the controls of this simulator more applicable to a learning environment. I just yesterday successfully got a planet zoom feature working and am now attempting to program in floating statistics. I do already have a current version of floating statistics (velocity, position) for each planet object but am finding that these HTML elements do not play well with my Orbit Controls library (which controls the users ability to spin the scene around with the mouse) and often disappear unexpectedly never to return. To have statistics only appear when the user selects a planet to zoom in on I can temporarily limit their ability to move the camera and potentially circumnavigate this HTML element issue altogether. Once I fix this UI issue I plan to focus on three elements: animated line vectors to show velocity and gravitational acceleration for each planet, animated orbit line tracing to track orbital periods, and an optional log scaling factor so the user can see planets which are farther out. Wish me luck, its crunch time.
Walkthrough week went suprisingly well but it make me realize how much my user interface is lacking. My project works very well for a walkthrough if I simply want to show off code or functionality but there are a lot of aspects of my project that aren't readily seen by the user that better controls might make more transparent. To begin, the scale of my universe sandbox needs to be shown to the user. While I am using scaling I want this to be a learning tool so I want the user to be exposed to a managable amount of numerical background. This means that I can implement scientific notation oriented controls into the simulator so the user can see how small scale changes (ex. x10^5 compared to x10^6) can factor into the end product. This also makes my job much easier because the amount of transparency only depends on how much I want to show the user. One of my next steps in this direction is to give the user the ability to see real time position and velocity data and be able to zoom into objects. These aspects will give the user a comprehensive but managible amount of internal system data so they can make a more educated use of this tool.
Finally a breakthrough! After many hours of testing my algorithm it finally works! I am able to calculate orbital accelerations, velocities, and positions in real time using managable numbers by extrapolating the scientific notation from each calculation in real time so it can be applied to my working variables at the end. This system allows me to easily scale my positions from meters into astornomical units (Earth-Sun radii) so instead of dealing with millions of units I am dealing with units ranging from 0-100 for a scale model of our solar system. This algorithm, I've discovered, is adaptable to not only to elliptical orbits (much like the earth model I used to initially build the algroithm) but will reliably iterate circular orbits given an averaged orbit velocity (which is the easiest statistic to get online) meaning that users won't have as hard of a time getting created objects to stay in orbit. In addition, I have successfully implemented a pause button and have wrangled a THREE.js orbit controls library so the user can rotate the scene so see different angles.
The next steps for me are user interface goals. I want to give the user the ability to zoom into and out of the scene at will and select objects such that the camera follows their paths for a 'single object view' with the goal that I eventually can display the object's orbital statistics along side when in this view. I want to give the user the ability to add their own created objects and change current attributes for existing objects. Lastly, I want to add in an orbital trajectory animation which traces the paths of orbits to make them easier to visuallize as well as let the user see how acurate their orbits are period to period.
This week I've been continuing to flesh out my scientific notation algorithm. The link below shows a written out equation for gravitational acceleration in the x dimension. This formula allows me to extrapolate the exponentials from the equation and apply them later to the final coefficient. This is important because the variables that are currently doing the heavy lifting are quite small but their calculation requires storing very large intermediate numbers. To successfully implement this algorithm would mean I can perform my animations entirely on javascript with no need for a python intermediate calculator.
Gx Scientific Notation Formula.pdfI had a short meeting today with Dr. McVey and Dr. Diedrich to discuss an interesting bug with my flask server, as well I discussed a possible workaround to having to use a python server in the first place. My flask server, it turns out can send and receive data in a working loop but is very delicate due to a circular reference. There is a possible fix but before attempting to find this fix I’ve been advised to opt for my JavaScript workaround first. My work around uses a slightly more complicated algorithm in order to separate coefficients and their scientific notation counterparts in order to avoid storing extremely large numbers. The next few days or week will involve attempting to implement this algorithm.
This week has been spent attempting to execute the plan set forth in my last meeting as well as my recent visit to the University of Utah's chemistry program. I am, admittedly, set back a little because of my visit but I am working hard to establish a reliable file-based, scheduled data stream between javascript and python. More updates are incoming but for now my main priority is catching up and finally bipassing my data transfer problems.
Today I met with Dr. McVey to discuss my data transfer model between javascript and python. So far I have been using the built in fetch API to pass GET and POST requests back and forth but have hit a roadblock when trying to pass the same piece of data while altering it at each end. This is because GET and POST requests happen based on the speed of the threads executing on both sides and because javascript and python do not communcate by default the data needs to be on both ends to begin with to accomidate which system acts first. My meeting yeilded a different approach: The use of an inital POST method in order to send the user's data (initial position) followed by a scheduled updating of a shared position JSON file which both the javascript and python have access to. In this new model python will continuously advance and update the library of orbital positions as javascript needs them.
This week has seen a lot of steady progress and the formation of many feasible goals. This blog post is coming a tad early because I'm in Boulder for the weekend but the meeting with Dr. McVey and Dr. Diederich as well as my overlook meeting with Dr. Olson right after has set my schedule for the next few days. My goal is to have a working and tested javscript animatied orbital model of the earth in 2 dimensions within the next couple days. I need to be able to pass usable data between python and javascript and use this data in order to point animate the movement of an earth-like object around an animated Mass that is much like the sun in mass (and hope it can do it accurately enough to not spiral out of control). Dr. Olson has shown me that a 2 dimensional model of a two object system is a ambitious enough goal for now and that's what I'm going to stick with.
Today was a big fixup for the two large facets of my program. Having not used Javascript before I have never attempted to invoke JS methods from another script. Thus far I have only ever tested using a local hosting environment meaning that to run an html document with embeded Javascript always worked. My project has necessitated use of Flask to pass computer data from Python to JS and back meaning execution of my project from a py script via a terminal and this invoction ultimately necessitated a virtual method of fetching JS scripts. Dr. McVey and Dr. Diederich (and Ali!) helped me to work to the fetching method listed here:
https://stackoverflow.com/questions/46349370/javascript-file-not-found-using-relative-path-during-flask-render-templateThe result was a Flask compatable invoction via python scrip yeilding a direct path between python and javascript which will ultimately hopefully all me to use Python as my calculation unit for the simulator.
My last blog post sums up my work this week very well. I have been dealing with animation software in a language that works really well with animations using large numbers on the same language that doesn't work well with large numbers. I have decided to try and learn how to convert my data into a json file notation and transfer it to python in order to solve this issue and am slowly but surely making progress with the help of Dr. McVey on Javascript typos. All the while I have been working with Dr. Olson to improve my orbital model so that once I am ready to implement my dual language software I have a robust mathmatic model to follow. Once this works I am excited to start to implement this same model using user input initial parameters and to go from 2 dimensions to 3 dimensions.
I met today again with Dr. Olson (and Dr. Diederich later on) who both suggested to use Python as a fast and light calculator for the large numbers my models deal with. The good thing about this type of number handling is that once Python spits out the resulting data the only numbers that have any meaning for my simulation is the X and Y (and eventually Z) positions. The problem I was running into before is that if I want to scale these large numbers into resonable units such as Astronomical Units (AU- the distance from the sun to the earth center to center), Solar Masses (SM- mass of the sun), and Orbital Periods (T- 365.25 days) it begins to make other variables such as veloctiy extremely small. With python handling the math for me and sending back coordinates I can convert these coordinates into usable, scaled quantities.
This week was marked by more experimenting with Three JS. I have made successful single object animations and am playing around with point lighting in order to experiment with the lighting of objects that emit radiation (stars, black holes, etc.). In addition, I have been experimenting with object spin and rotation but was not able to program accurate movement without an accutrate model. In my meeting with Dr. Olson he showed me how to create an iterative model of a year-long earth orbit that showed a fairly tight tolerace.
Orbital Model.xlsxOrbital tolerances are important, if an object in orbit does not come back to its inital position after one orbital period there is an indication of precession (hula-hooping) or spinning out. The excel above sheet allows me to design an orbital model that prevents objects from spinning out (as they do naturally) and give the user a better simulation to use. My next goal is to use my mathmatical model to animate an earth/sun model that responds in real time to user input.
Today I met with Dr. Olson to discuss orbital simulations and the math behind algebraic orbital modeling. He showed me a prominent, robust way of determining the current position, velocity, and gravitational acceleration of a particle based only on an initial position which would allow me to easily and predictably program an object to self-interate through it's orbit without having to keep a database of future points. My goal now is to assign an object a inital gravitational acceleration (based on the mass of a second object) and correctly animate its subsequent path around the second ("heavier") object
This week has consisted of experimentation with Javascipt animation libraries. Since switching tactics I have decided to use the Three.js library mostly for its prevolence but also for the sheer variety of animations it was demonstrated on. Being strong in both visuals and physics. I think this platform will give me the right balance of ease of use. Some attributes such as colors and positions can be set easily but the actual wrangling of these attributes as well as other more complex pieces such as equation boxes and interactions will be solely up to me. In addition, I have begun to roughly sketch out the design of my interface. I want to let the user pick the degree to which the detail of the system is shown. For example, on its surface the game might represent a simple playground with a simplified toolbox for objects but as the user clicks around attribute boxes for each object might be revealed to show equations, orbital trajectories, and perhaps heat. I want to be able to distinctly show which forces are acting in the simulators and their mathmetical background if desired. My current idea is to allow the user to pick their observation point whether that be observing the whole system, two objects in relation to one another, or a single object. This will allow me to better show the user the effects of time dialation (which is of course dependent on the observer), electromagnetic forces of stars by showing cross sections, and gravitational pulls of other objects.
After my first meeting with Dr. Diederich its become a lot clearer that using such a low level programming approach as OpenGL might have me in over my head. While I may be more comfortable with C++ the trade off of having to use such a elementary animation library negates the time I might save. I have started, then, to go in the direction of a Javascript pre-made animation language which will allow me to more effortlessly create objects instead of starting from the ground up for each object. This will hopefully allow me to focus much more on object interactions: gravity, collisions, and orbits.
Welcome to the first blog post of my project: Modeling Astronomical Behaviors! This project will entail skills I have very little direct experience with but will draw upon every fringe of my coding experience. This first week has entailed mostly planning which platform and language I will use to address the need for 3D animation in my project. While past capstone projects have had luck with a Javascript and PHP model for animation, as I planned I began to lean towards C++ as it is one of the preferred languages for 3D animation. I came across a helpful article which details the architecture for building an animation software showing how the finest of one’s animations can be dictated by the animation library one is using.
https://www.gamedeveloper.com/programming/architecting-a-3d-animation-engineDue to the fact that my project will start off as a basic modeling software using simple objects and vectors as opposed to complex visuals and physics I opted for a more basic animation toolkit. Therefore, I have started experimenting with OpenGL, an API animation toolkit which allows me to directly interface with my computer’s graphics unit through Visual Studio. I believe that by using the most bare-bones toolkit for animation I can better coerce my objective for this project to be a learning tool based on my own knowledge of astronomical phenomena. By having to program my own physics instead of using a physics engine I can make the functions of my animation tool very clear to the user, perhaps even showing the equations used to model gravity, radiation, orbits, etc. as well as allowing the user to directly see the animation attributes of each object such as mass, volume, and velocity. Overall, I hope by learning to use OpenGL I can begin to design a very simple but very robust animation software not reliant on pre-existing animation libraries, allowing me to take possession of every aspect of my code. And while it may not look as polished as a professional animation I will allow me to understand each step in creating an animation using the language I am most comfortable with.