3. Design considerations

So... how to represent comets in Stellarium? Here is some extra info to consider with some reference photos appended.

1 AU == 150 Mkm

Comets typically become visible 5 AU (Jupiter) from the Sun. This is the about the maximum distance that sunlight can vaporize water. They start out as fuzzy light balls indistinguishable from other beings except that they clearly move relative to the stars when tracked.

At 3 AU, the dust tail appears.

When the Comets near perihelion at 1.5 AU, the outgassing begins in earnest, and the ion tail appears.


Coma

The coma typically becomes bigger and brighter as the comet approaches the Sun, but when it is nearest, the coma actually diminishes because of some reasons. But overall, the brightness is proportional to (heliocentric distance)^(-4). Finally, the comet is typically brighter post-perihelion than it is pre-perihelion because of energy storage. For example, Halley's magnitude at (a) Outburst == 18.5; (b) Postperihelion == 18.5 to 8--; (c) Preperihelion == 25 to 10. The coma itself has a very bright center which diminshes to inverse r. The tails' brightness are relatively constant.

Outbursts are when comets because extremely bright, and can last for a few weeks. It doesn't have to do with how close the comet is to the Sun-- Schwassman-Wachmann I did it at 5 AU. Halley's (1991) brightness increased by 300 because it suddenly released a 300 Mkm radius of dust.

Split comets are when comets break into smaller comets. Comet Biela split into 2, but continued its orbit. The two parts formed tails, alternated in brightness, and even had a luminous bridge.

Tails

The ion tail is a streamy blue cone. The dust tail will be more like a fan in a plane, such that if viewed from the side it looks like a line. Depending on the composition, the ion tail or the dust tail will be bigger or not even exist. But this is unique to every comet and not contained in ordinary orbit data.

The ion tail doesn't actually point directly away from the Sun, but lags a few degrees due to aberration, which is how the solar wind's direction seems to change if we took the comet as the reference point. Since the comet itself is in fact moving, the solar wind's "direction" slants.

Disconnection events occur when the comets pass solar wind boundaries -- magnetic field lines of the solar wind reverses polarity -- or when pressure presses out the ionosphere and tail. The ion tail sloughs off, and soon the comet will grow another tail.

The appearance of an anti-tail is due to the parallax error of seeing the curve of a tail as another tail. This will depend on the observer's position relative to the comet.

Nucleus

There seems to be OBJ files of some prominent comets. If that is inadequate, it should not be hard to model some nuclei in Blender and export the models into OBJ files. If we were to be as accurate as possible, then the comets with existing OBJ files should be mapped to those files. As for unknown nuclei, there could be a small library of OBJ files to randomly choose from. I'm not sure when this is currently done in Stellarium, but this random choosing could be done during the swap from fuzzy coma to nucleus body.

The nucleus surface is somewhat smooth and doesn't usually have craters, because some dust that rises out during outgassing is too heavy and doesn't meet the escape velocity, so the nucleus surface is continuously covered afresh with dust. The shape itself should not be spherical- but irregular. They rotate and depending on which part is facing the sun, the vents in the comet body releases gas and dust.

Photographs do not accurately reflect the actual comet seen through a telescope. The necessary overexposure captures the coma as a simple fuzz ball without the details. The nucleus spews spiral and fountainlike shapes (drawings of Comet Tebutt)



Photos (expected appearance?):

2. Comet orbits and math

Some points

Kepler let us know that Earth and the other planets do not orbit in perfect circles around the Sun, but in ellipses. His laws apply to comets as well, and comets actually have highly eccentric and sometimes very inclined orbits.

Interpreting orbital elements (Page 159)
Calculating from the elements
Calculating from Kepler's and Newton's

The perihelion is the point where an object comes closest to the Sun, and some comets come so close that they become known as the Sungrazers. By Kepler's, comets also travel the fastest when they swing around the Sun. The dust tails become especially curved, and by parallax error, we might see a third tails sprout towards the Sun. Known as the antitail, it is actually the end of the curved dust tail.

The brightness is typically inversely proportional by (r^4) to the distance to the Sun, but if the nucleus is especially active, its magnitude could increase tremendously (17 to 2 for 17/P Holmes).

Eccentricity: the ratio of (distance between the two focus points) to (the semimajor axis). By Kepler's 1st Law, moving bodies orbit elliptically, with the parent (in the comet's case, the Sun) at one focus. Thus, for closed orbits, the eccentricity must always be less than 1. Otherwise, the path would be parabolic and we just have a single-apparation comet.

Conclusion: Comets are sorted into their orbital periods, and for Stellarium it's probably only worthwhile to consider short-period comets, or even just observable comets, and not long-period or single-apparition comets, since keeping in the database comets that only appear once in 97,000 years at the perihelion is kind of wasteful. By the next time that comet comes, Stellarium would probably have the AI to detect and display observable comets automatically =X

===

Equations

Finally, some math.

Kepler's Laws
Different formulas to calculate comet orbits
Modeling Comet Halley's rotating nucleus with dust ejection from discrete sources
Dust tail model [1]
Comet tail with radiation pressure and resistance due to orbit
[1]

1. Background info: Origins, Tails, Chemistry

So I did some reading about comets, some example comets, bow shock, comet nuclei and the tails. Below, I relate that info to the appearance of comets.

2 posts coming up: (1) Orbits and Mathematics (for orbit, brightness, tails); (2) Design considerations


The dust tail (yellow, reflecting sunlight) and the ion tail (blue, fluorescence).

In the beginning, the Solar System was just dust and water rotating about the Sun. Dust clumped together, water clumped together, and planets were formed. The closest-to-the-Sun planets are largely made out of rock because the heat of the Sun didn't let ice stay around, while the rest of the planets are giant bodies of gas and ice. Comets are the latter planets' left overs. They're known as dirty snowballs because they're largely made of ice, carbon monoxide, and other gases like argon, ammonia, and such. This is contained in a dark crust of complex organic compounds, which absorbs light. Comet nuclei are actually some of the darkest observable material. We don't easily observe this because when the Sun isn't close enough to light up the comet, the nucleus is too small. When the Sun is, the nucleus will be obscured by a large coma. There is an even larger cloud of hydrogen, but this is not visible to the human eye.

There are thousands of comets hypothesized to exist in Oort's Cloud in the outer solar system and the Kuiper Belt, which rotate Oort's Cloud accounts for long period comets (> 200 years) and the comets can stay there, undetected, and remain stable far from the Sun. Kupier's Belt is nearer and accounts for short period comets (<= 200). The comets lay dormant in the cloud, but due the gravitational pull from the planets, its orbit became highly eccentric- an elongated ellipse.Trom the highly eccentric orbits of the comets, astronomers have extrapolated their existence. Jupiter and other massive bodies gravitational perturb the comets, comets collide with comets, and so, in this way, comets leave the Cloud or Belt.

As the comets near the Sun, they receive enough heat energy (especially with their dark crusts) to start outgassing. In other words, the frozen H20 and gases sublime from solid to gas, not via water since Space is a vacuum, and spew out of the comet. Sunlight and the photoelectric effect ionizes water molecules into Hydrogen ions and Oxygen ions. Meanwhile, a great deal of solar wind is coming at the comet. Solar winds are ionized particles from the Sun moving at such high speeds that they escape Sun's gravity. Since the comet is traveling at supersonic speeds relative to the solar wind, a bow shock is formed. In other words, the high solar wind speed dips drastically and ions from the Sun accumulate because they arrive faster at the bow shock than they can leave. A magnetic field (magnetosphere) flows around the comet like a stream around a rock, and the ionized plasma from the comet will form the ion tail. This ion tail is long and narrow, and will point directly away from the Sun because of the magnetic effect. The ion tail is actually made of plasma, and is blue because of CO+.

There was dust, mainly silicate, mixed into the gas and water, and they also spew out of the comet. This forms the coma, which can hide the nucleus. Radiation pressure bounces sunlight off the dust particles, creating the dust tail. It reflects a lot of light, making it shiny therefore observable. The dust tail doesn't directly extend away from the Sun like the ion tail, but curves. This is because the nucleus rotates, and so sunlight doesn't hit the nucleus uniformly: indirect sunlight, less outgassing; direct sunlight, more outgassing. Thus the tail curves along the trajectory. Depending on the nucleus' rotation, the comet can either be propelled or repelled, affecting its orbital radius. That's why Comet Encke's period decreases.

There can be other hard-to-detect tails, such as the faint 50Mkm long Sodium (Na) tail of Hale-Bopp's. Sometimes, a comet will have multiple ion tails (Comet Donati), or when it breaks apart it can have a fan of tails (Comet West).

All this material-spewing occurs at "vents", or puncture points in the comet's crust that cracked under the pressure of the volatile material wanting to get out. We prove the existence of vents by studying the tail. In Hale-Bopp, the moving tail showed that the comet was rotating because depending on which side was facing the Sun, the volatile materials would spew out from the vents on that side.

Now, for the composition of the comets. It was once hypothesized that Earth's water comes from comet collisions, since it was suspected that the Deuterium (isotope of H) to Hydrogen was the same in both bodies. Comets also reveal a lot about the Early Universe. The above theory, however, is dubious because it was later confirmed via samples that the ratio is different. A comet's chemistry can affect their color (the gas may fluorescence under UV rays). For example, yellow Sodium tails and Argon fluorescence. The main thing is that Comets is made of (1) crust: complex organic compounds, silicates (metal like Iron and Sodium, silicon to form rock); (2) volatiles: H20, CO mainly, then Na, CO2, OH, NH4, HCN, CH4, H2S, Ar, etc.

Building Stellarium for Mac, and running on Qt

Follow these instructions first. If they work out, good:)
Else:
- Install macports
- sudo port selfupdate to sync
- If selfupdate fails due to rsync, then find port’s dir and change source.conf like this. If permissions denied (e.g. buffer is read-only) then type “sudo emacs source.conf” and this will give you control
- Use macports to install gettext and bzr
- bzr launchpad-login <username>
- Continue to follow instructions
- If cmake fails because QMAKE not found, search for CMakeCache.txt, find ‘Qt’ and replace FILE_PATH_NOT_FOUND. Change FILEPATH to e.g. /Users/<your_mac_username>/QtSDK/Desktop/Qt/4.8.1/gcc/bin/qmake
- Then run cmake ../.. again
- Run make
- Run make install
- Run make macosx_bundle
- if macosx_bundle fails, go to CMakeFiles, emacs Makefile2
Delete line 136 after the colon
- Run macosx_bundle again

If you have any patches that need to be added, just run “bzr pull”


=== Qt ===
Use "bzr branch" and "bzr init-repo" to create your branches and shared repository. The directories that you create will be what's used for "Development/StelRepo/branches/testA" below, which is just an example; name it whatever you like.


Then: Follow these instructions

Except for
D:\stellarium\trunk\builds\msys
should just be the same folder as your branch
<address_until>/<branch_name> // Concrete example below

To RUN a new branch, must change Run Settings.
Under Projects (on the left panel), go to Run Settings:
working directory: /Users/<your_mac_username>/Development/StelRepo/branches/testA/src
change to: /Users/<your_mac_username>/Development/StelRepo/branches/testA/

Files that are directly relevant to Comet

StelApp (hpp) (cpp)

Has the recognizable OpenGL init(), draw(), resize() functions. Gets pointers to all the main Mgr classes which manage the functions such as Sky Culture. The Comet class will be managed the StelModuleMgr.

Initializes the StelObjectMgr, then the SolarSystemMgr, then all the more specific managers like Stars, Milky Way and Nebula.

Here, in StelApp::init(), I would put:

// init comet manager
CometMgr* comets = new CometMgr();
comets->init();
getModuleMgr.registerModule(comets);

In StelApp::update(), each module is updated, and CometMgr needs its own update() function that changes due to delta time. Similarly, each module needs its own mouse click, etc., handling in moduleMgr->getCallOrders(*action*). moduleMgr is StelApp's StelModuleMgr pointer and getModuleMgr() returns this pointer. The use of either seems arbitrary in StelApp.cpp.

StelMainGraphicsView

Sets up the window and background and loads the display buffers. Depth buffer is for determining which objects should be drawn, so that time is not wasted drawing objects behind objects. Double buffer is so that we don't have poor graphics during animation- there is a buffer for display, and a buffer to draw to. After a buffer is drawn to, it is swapped. This way, the viewer sees a continuously animated picture that doesn't look half drawn as it would be if there was only a single buffer to draw and display to.

Also receives window resizing and keyboard/ mouse events. StelApps does the actual handling privately.

I have to make sure that the Comet class doesn't have too expensive an O(n) that the display buffer will not be drawn to in time.

StelCore


Oversees the display in Stellarium w.r.t. time using the MovementMgr and SkyDrawerMgr. The modules refer to StelCore for all kinds of astronomical coordinate systems and timing (e.g. Julian time, time speed).

StelMovementMgr (hpp) (cpp)

Handles movement (e.g. zooming, selecting, panning left and right) of the mouse, etc. Tracks selected object by flagging it. Has virtual draw() and update() functions <=-- handled by modules?

StelSkyDrawer (hpp) (cpp)


Like MovementMgr, SkyDrawer  provides a unified way for objects to draw themselves with respect to the viewer. Here is where the star's textures are loaded. Since that's currently how comets are displayed, as suns, but we don't want that, the comet texture needs to be loaded here too.

So in the .hpp file we need to add comet's shader:
QGLShaderProgram* cometsShaderProgram;

In the .cpp file:
StelSkyDrawer::init() - load texture images
texDustTail = StelApp::getInstance().getTextureManager().createTexture("textures/comets/dustTail.png");
texIonTail = StelApp::getInstance().getTextureManager().createTexture("textures/comets/ionTail.png");
texNucleus = StelApp::getInstance().getTextureManager().createTexture("textures/comets/nucleus.png");
texComet = StelApp::getInstance().getTextureManager().createTexture("textures/comets/comet.png");

StelSkyDrawer::update() - Re-scale comet's display size

StelSkyDrawer::DrawPointSource() - Store comet's drawing positions and vertex arrays

StelSkyDrawer::postDrawPointSource() - bulk of comet drawing/ shading
Attribute vertex, color and texture to comet

Remember to bind texture (for openGL texture binding). E.g. texComet->bind(). bind() is a function in the StelTexture class.

StelUtils


Provides general functions like converting coordinates and time, and computing exp and acos(x)

StelVertexArray


For openGL compatible vertex arrays. Vertex arrays are used, for example, to conveniently make a polygon and assign it colors, etc., without individually creating a point then assigning a color to it.

VecMath


For openGL compatible vectors. E.g. 3 floats, a (4x4)-matrix, etc.

StelObject


StelObject will be the Abstract Base Class for Comet. We can polymorphically refer to the Comet with StelObjectP (StelObject*). Holds data general to all sky objects. So, for the Comet class, I'll have to find all the corresponding information.

Virtual StelObject::getCloseViewFov(). For when the viewer zooms in on a Comet, we have to define it in some way so that the viewer can see the Comet in better detail E.g. easier to see the nucleus and the actual non-spherical body of the comet.

SolarSystem


Comet/ Minor Planets derived from this class. Their .hpp files are included in this .cpp file.

In SolarSystem::loadPlanets(), the eccentricity, semi-major axis and other orbital information is loaded. Comet orbits are very flat ellipses. There is a special branch for comets in line 495 that calculates the orbit specifically. loadPlanet() gets all the data from a file for all kinds of planets, including asteroids and comets.

Because we have to add tails and perhaps other features, the code here will be more than just getting its orbit.

Includes Orbit class, which has a special derived class for comets which contains more variables, and does calculations already.

Planet


Current Comet is directly derived from this, and Planets do indeed share some features, but if we're to get photorealistic features, Comet doesn't have an exact radius when zoomed into because comet bodies are not spherical. The current Comet code doesn't capture information about tails or a nucleus either. To keep comet under the SolarSystem class, however, Comet needs to remain a "Planet".

StelPainter (hpp) (cpp)

Provides functions for openGL drawing, so the bulk of the openGL-type implementations are here. It is probably the most important class to use after Comet.

Color and Light

Chapters 4 and 5 of the Red Book.

RGB v. Color Indexing

In OpenGL, you can specify either RGB or Color Index modes. RGB is more suitable than color mapping for Stellarium because we want to generate colors that are smoothed out, and just picking a range of indexes might get wildly different colors that so happened to be beside each other on the color map. Meanwhile, in RGB changing the individual R, G, B components vary the color in an unsurprising way.

Lighting

Each component is separately considered, then summed together.

Ambient - light from no particular direction, heavily scattered
Diffuse - light from 1 direction, heavily scattered
Specular - light from 1 direction, reflected in 1 direction (shininess)
Emissive - light from the object

Basic transformations for OpenGL

On to Chapter 3 Viewing of the Red Book. Matrices and Transformations determine how an object is shown on screen. To manipulate the different matrices, we first have to set the kind of matrix (texture, projection or modelview=default) with glMatrixMode(). And all transformations after that will apply to that particular matrix. Before every group of transformations, we have to initialize the matrix with glLoadIdentity() so that we work with a whole new matrix, not the previous matrix created.

Modelview

To rasterize 3-dimensional objects to the 2-d screen, the following kinds of matrixes are applied in this order:

(1) Viewing transformations

(2) Modeling transformations

Why this order? Transformations are applied to an object as functions, so if we let viewing matrix V be viewFn, modeling matrix M be modFn, and object be O, then the code will look like this:

viewFn();

modFn();

O;

In matrix form, it will look like this:

T(x) = VMx

This makes sense because we want to rotate an object, then look at it. The above matrices will make up the ModelView matrix.

Projection

The 3-D models are projected onto a screen. The projection can be:

(1) Perspective - Since further objects will seem smaller than nearer objects, we want to reflect this. One easy way to think about this is like a frustum, which has a larger base than the other side. The larger base is closer to us. We can transform the initial perspective matrix with glFrustum(). 

(2) Orthographic - The object is flattened directly onto the screen, regardless of the angle or distance that a viewer might see it in real life.

===

After drawing something, we can use gluLookAt() to see the scene from another angle. This is useful for when something looks correct from the front, but when seen at an elevated angle, is actually out of shape.

===

Matrix Stack

When creating multiple models that are related to each other, it would be useful to transform from one point at model_1 to make a model_2, then go back to the origin, and transform somewhere else to make another model_2. Thus, the two model_2s are created relative to model_1. This process of doing transform_1, undo, transform_2, undo, transform_3, undo can be contained LIFO-style, which is what a stack does.

Modelview stacks can contain 32 matrices, while Perspective stacks can hold 2 matrices.

===

Planet System tutorial

Demonstrated modelview and perspective transformations, matrix stacks and keyboard control.

Hello World with OpenGL and GLUT

So I followed the spin shape function (somewhat modified) from the OpenGL Programming Guide, a.k.a. the Red Book, and followed Chapters 1 and 2.

What it does is spin a square slowly. The original Red Book version spun really fast. And since I'm using a MacBook Pro, which only has a trackpad, the spinning pauses on Right-Click instead of Middle-Click.

Then, I modified the program to spin a 5-vertex polygon instead:

While the rest more or less follows the guide, here's the code that adds a vertex, reduces spin speed and changes button used:

About

<old> About the OpenGL-related posts: I won't go into details already covered by the Red Book, so the material here may not seem as comprehensive. I just uploaded stuff that I did while reading the Red Book and things that seemed especially pertinent. For complete coverage of the fundamentals and more advanced explanations, I'll go to Google or Red Book. </old>

UPDATE

This blog is now a project blog. Somehow, my proposal was accepted... It's my first time making something real, and I hope to complete what I set out to do. I'm excited about learning from my mentor and the Stellarium community, and contributing to open source.