Pencils down tomorrow (updated)

Thanks to my mentor Alexander Wolf, and Stellarium. The hard pencils-down date is tomorrow, so I'll clean up the code, add documentation, and do some last minute edits, then push the finalized branch tomorrow when I have a better Internet connection. Will post a link to that branch here.

The promised deliverables were pretty much met:
- Added comets to ssystem.ini
- Instead of control in Sky Tab, on Alex Wolf's suggestion, made functions for users to script and thereby control the tail/ coma appearance. Scripting is easy though, and I also provided an example script comet_control.ssc
- Drew plasma tail and dust tail realistically. However, implementation for dust tail can be improved in the future to be physically realistic.

Future:
- Was unable to do the optional deliverables (nucleus split, sun collision) during this time frame.
- To improve dust tail (and coma if needed)
--> Dust tail's drawing is not physically accurate, for now just looks feasible. Have to project fan-on-a-plane dust tail into 2D coordinates on the screen
---> after that, may need to implement coma-specific function

Misc notes:
- Overestimated what could be achieved within the time frame. Had school and exams during Community Bonding Period and first 3 weeks of GSoC, then last 2 weeks of GSoC.
- Changed implementation several times; the final solution was usually a lot simpler and different from what I thought it would be in the proposal
- Took some time to get familiar with code base, working in a large project, and using Bazaar
- Took too long on one bug, went the wrong route, spending 1+ months trying to even put something on the screen correctly

Comet control script videos (updated)

As demonstrated in the screencast below, the user can write scripts to:
1) control the coma size,
2) return to the default coma size,
3) increase/ decrease the plasma tail length,
4) increase/ decrease the dust tail length.

(View in full screen)

Note:
- The coma, dust tail and plasma tail size was enlarged so that it's easier to see in the video. The actual code makes the comet a lot smaller. For example, the currently only possibly visible-tails comet, P/2005 K3 (McNaught), which is less than 1.0 AU from the Sun and therefore the solar heat is enough to melt the ice for us to see the dust tail. (see below video for actual representation)
- At other times, the dust tail and plasma were more distinct from each other, but from this angle they overlap.

Video of actual size in Stellarium
How you would see it when the sizes are not artificially enlarged for debugging purposes:

(View in full screen)

Here are the public slots (a kind of Qt-unique functions) that are available from the CometMgr class:
void setDefaultComaSize()
Revert current coma size to the default size.
void plasmaTailLengthMultBy(float factor)
Multiply current plasma tail length by "factor". Not allowed to be negative number.
void dustTailLengthMultBy(float factor)
Multiply current dust tail length by "factor". Not allowed to be negative number.
void comaBurstTo(float new)
Set the coma size to "new". Note, the more negative, the larger the coma will be. Limited to -50 < new < 50
float getDefaultComaSize()
Get default coma size for when you want to adjust the coma more realistically according to how much you change the tail lengths

Future possibilities:
Illustration of nucleus split and collision with Sun.
But first, I would have to improve the tail rendering to be more physically realistic and clear bugs.

How to make the dust tail realistic?

In an old model, I got the 3d coordinates of the dust tail, then projected it to the 2d screen. This is because the dust tail in reality is considered to be on a plane, so viewed from different angles, it could either look like a line or a fan. (Note the oval was supposed to be a substitute coma for the time being)

Unfortunately, it didn't look realistic like the pictures online:

If I used a similar method to the plasma tail, however, it looked more like the pictures (from zoom in to zoomed out, view from Earth):

Plasma tail

Somehow coded the plasma tail to rotate. First it was written to be a cone, but this was too thin and unrealistic... you couldn't see the coma. Then I changed it to a frustum, and it turned out like this. And because it was rotating, there is a continuously changing streaky effect.

what I mean by unrealistic when a cone:

Working backwards, Comets to Sun

Found out that my initial getting of coordinates of comet and Sun was wrong, and they needed to be projected onto the 2d screen from their Right Ascension/Declination coordinates. Now, finally, the coordinates are correct. I drew a line from comet to Sun so that it would be obvious where the coordinates are.

Another issue was getting the Sun's coordinates, because in Planet.cpp and Comet.cpp, to a comet, the Sun's coordinates would always be (0., 0., 0.), which on screen is at the bottom left. So I had to get the Sun from Stellarium's SolarSystem via GETSTELMODULE.

With this, I have to rewrite the plasmaTail() and dustTail() functions, but it should be fairly fast now that the bug I couldn't get rid off is out of the way.

Process:

Tail bugs

General
1. Tails keep changing, but start at a fixed position
2. NEW: PlasmaTail, dustTail sPainter's are the same, such that dustTail's color and vertex arrays are the same.

Plasma Tail (blue)
1. One tail that starts from bottom left corner of the screen to wherever last clicked. Rotates too.
2. If in SkyDrawer::postDraw3dModel(), no "if(cometNoHalo) do_nothing;", then no plasma tails drawn except

Dust Tail (brown)
1. Line loop that outlines the plasma tail

CometMgr update

To let a user write scripts that control the comet's appearance (tail lengths, coma sizes, etc.), a CometMgr (StelModule) needs to be added for the Stellarium scripting engine.

Initially, the idea was the derive CometMgr from SolarSystem, and separate Comets with the rest of the SolarSystem bodies. But I found that this duplicated and was just messy and unnecessary. So instead, CometMgr will be a friend class of SolarSystem so that it has access to Stellarium's active list of comets, and the current comet that has been selected. Using CometMgr, we change the member variables of a Comet object.

Update July 25: CometMgr done.

Dust tail prep

How the dust tail is modeled


Dust tail to be represented as a quadratic equation (vertex points along the curve) Then tail will be planar. Dust velocity equation will act as axis of symmetry, axisDV
1. First get quadratic equation kx**2, where k is calculated from dust ejection velocity, and magnitude from heliocentric distance (k is determined by comparing those two values of many comets, via testing)
2. Get a list of vertex points, vertexArray
3. Since that equation's axis of symmetry will be x=0, we can get the rotation to aDV, A
4. Next, get the translation to the point in space, B
5. Combine these to the final transformation matrix T(x) = B(A(x))
6. Put all points in vertexArray through T


Finding k, which represents the magnitude of the dust tail, from comparing the usual case of dust ejection velocity (which takes into account heliocentric distance) vector length.

Min dust ejection velocity vector length: 5.2853 
Max DEV length: 23.2426
Usual DEV length: (10, 15)

k = DEV_length * factor // TODO: need factor? Can only determine after drawing

Still need to find projection from 3-D coordinates to 2-D window (screen).

Comet data and parse code below

Going slow

Unfortunately, with final exams and project deadlines coming up, this will be a slow week... I'll be back in high gear 11th June. I'll actually be able to concentrate fully on SoC then since most of school will be over.

Plasma tail bugs

Update: Added glBlend(). Now color looks like plasma tail (can see stars through tail). But rendering still has problems.

Currently, the plasma tail doesn't show up. To draw a cone, I'm calculating points that depict the base of the cone (2*pi*radius), and the tip (nucleus position). Using print statements, the comet's plasmaTail() draw function is actually being passed.

A vertex array of 1 comet. Cone has 12 slices, the even-numbered slices share the same vector because it's the tip.

Comet drawing comet_i

"0testComet" 0 6.01287 -4.51122 6.28631
"0testComet" 1 83699.8 -80468.1 92593.8
"0testComet" 2 6.01287 -4.51122 6.28631
"0testComet" 3 83786.4 -80418.1 92593.8
"0testComet" 4 6.01287 -4.51122 6.28631
"0testComet" 5 83873 -80468.1 92593.8
"0testComet" 6 6.01287 -4.51122 6.28631
"0testComet" 7 83873 -80568.1 92593.8
"0testComet" 8 6.01287 -4.51122 6.28631
"0testComet" 9 83786.4 -80618.1 92593.8
"0testComet" 10 6.01287 -4.51122 6.28631
"0testComet" 11 83699.8 -80568.1 92593.8  

Bug #1: drawing fake cone at wherever cursor clicks
Instead of originating from comets, the base of the "cone" is where the cursor last clicked. The cone is revolving, and is actually a square base with two sides' triangles rendered. There's only one such "cone" visible. This could be all 34 cones being drawn on top of each other. (I used print statements to verify that there were 34 unique comet vertex array sets.

Bug #2: flashing rectangle 
There's a rectangle that brightens up already-white areas, such as the Sun's starlight. And it flashes. This doesn't happen when I downsize from full-screen mode.

pushed cometTailDirFunctions

Pushed branch */cometTailDirFunctions

Functions added to Comet class:

Vec3d plasmaTailDirection();
- anti-sunward direction, radially off by 3 degrees

Vec3d velocityOfComet();
- tangent to comet's orbit; current velocity direction
- for dust tail (which curves with orbit)

Vec3d dustEjectionVelocity();
- for dust tail's anti-sunward direction vector
- to be used with velocityOfComet() to get final dust tail direction

float tailLength();
- Length of dust and plasma tails (equation does not distinguish)

void plasmaTail();
- to draw plasma tail
- note: not working yet. Need to figure out how to make it display on Stellarium and which function in Planet's draw function to put in.

void drawComet();
- virtual function in Planet
- to draw the comet tails in addition to what Planet does

Comet Class functions

Functions that currently exist:
Comet(), ~Comet(), getInfoString(), getVMagnitude(), setAbsoluteMagnitudeAndSlope()

Plan for the next 7 weeks:

= = = Comet.cpp = for comet representation

antiSunDirection()
- for getting plasma tail and dust tail directions
- dust tail direction calculation will be indirect (sum with comet's velocity vector)

dustTailDensity()
- Calculate via physical equation
- GL Blend to create fade away effect and since tails are quite translucent

dustTail()
- Rate of flow equations/ heliocentric distance for size of tail
- A parabola in a plane
- Calculate solar color? Or just 1 solar color
- uses dustTailDensity() and effectiveJetDirection()

seeDustTail() // observer's view of tail
- according to angle (i.e. head-on: fan; side-on: line)
- parallax for antitail
- bool dead or alive (by heliocentric distance)

coma()
- magnitude according to heliocentric distance
- shape more elliptical as it gets closer
- GL Blend(one, one) with dust tail

ionTail()
- cone // if not efficient enough, then use parabola
- streaky blue texture bind
- GL Blend for fading to let most of the stars behind it visible
- GL Blend to let dust tail take precedence
- length by heliocentric distance
- offset angle by 3 degrees
- bool dead or alive (by heliocentric distance)

projectorOntoPlanetView()

// same function as in StelSkyDrawer.cpp, but customized for comet since not Planet
postDrawSky3dModelComet()
- mip maps? Far away, comet looks like blurry oval. Near, level of detail is much higher
- transform with respect to viewer

effectiveJetDirection()
- Some angle ~45 degrees
- antiSunDirection() + velocityOfComet()

// not actual velocity, just easier to think about it like this for calculating effectiveJetDirection()
velocityOfComet()
- tangent to orbit path, a.k.a. velocity of comet (parallel to orbit's tangent)

period()
heliocentricDistance()


= = = Sky Tab

cometBurst()
- since bursts are random and nigh unpredictable, the viewer can control this. With a comet selected, adjusting a slider in Sky Tab will increase (a.k.a make more negative) the magnitude

= = = Misc.

Could potentially have a Tail class, since there is overlapping direction, blend, texture bind and heliocentric distance considerations. Then the functions ionTail(), dustTail() and dustTailDensity() would instead be:

Tail()
- texture()
- blendWithSky()
- blendTails()

DustTail(): public Tail
- parabola body (deformation and axis determined using effectiveJetDirection)
- dustTailDensity()
- texture bind to parabola
- size() // by rate of flow equations and heliocentric distance

IonTail(): public Tail
- cone body (axis determined using antiSunDirection)
- texture bind of blue streams/streaks to cone
- size() // a.k.a. length by heliocentric distance

5 Papers and others

(1) 0704.22532v1.pdf - A survey of debris trails from short-period comets. Reach, Kelley, Sykes
Mean anomaly (parameter relating position and time via Kepler's Law of sweeping out areas at equal rates)

Note: Beta is the ratio of radiation pressure to gravity (1 means they are equal) in terms of acceleration/force.
E.g. (from paper 2) Comet P/2005 U1 Read - particle size: 10-100 micro m, terminal ejection v = (0.2 -3) m/s, escape velocity = 0.2 m/s

(2) 0x810.1351v1.pdf - Physical Properties of Main-Belt Comet P/2005 U1 (Read). Hsieh, Jewitt, Ishiguro
Terminal velocity of particles ejected (then form tails). Jets are modeled like cones, with constant angles = 45 degrees. Reference ejection velocity = 24 m/s

After impact with another body, the particle ejaculation comes mainly from that side of the comet.

(3) 1105.0944v1.pdf Physical Properties of Main-Belt Comet 176P/LINEAR. Hsieh, Ishiguro, Lacerda, Jewitt

Comas can be modeled as ellipsoides, with c/a == b/a for simplicity. 0 < c/a < b/a < 1. Dust tail is assumed to be a jet-driven cone, with cone opening angle of 45 degrees, and its central axis points toward right ascension, and declination in the inertial frame. If rotation, the angle can be approximated about the axis. Assume that dust particles are released uniformly from a sphere and that emission occurs only from direct sunlight. Comet's obliquity can lead to significantly active dust ejection during "summer" time.

Tail size affected by amount of volatile ice in comet. Maybe some variable initially optionally manually hard-coded in ssystem.ini. Later implement in UI adjustable by slider? This would be a hopeful deliverable depending on how long it takes to model the tails and coma correctly.

(4) 1961ApJ./../.pdf On the study of comet tails and models of the interplanetary medium. Brandt

Getting the tail direction:

(5) 1968Apj./../.pdf Theory of dust comets. I. Model and equations. Finson, Probstein

Distinctive comet phenomena becomes visible at 1AU from the Sun. 10**5- 10**6 km is typical coma diameter. Light intensity decreases 1/r

Plasma tails are long (10**7-10**8)km and narrow (10**5-10**6), straight, lagging in the radial direction by 3-5 degrees. Solar wind = 500 km/s. Comet velocity tangent to orbit = 30-60 km/s.
Dust tails are shorter (10**7)km and broader and curved, lagging between the extended radius vector of the Sun and the orbit path. EM interaction on dust tails are negligible.

The presence or absence of tails can affect the tails' orientation. Comets some times only have 1 type of tail. When both are present, the ion tail can charge and affect the dust tail because of its high speed 10km/s.

More: Appendix B (pg24, 25) determines how the comet looks like to an observer on Earth by relating an vector to a point on the tail axis. This way, parallax error for the antitail can be determined.

======
Update (5/24/12)

Length of comet tail (From ProjectPluto)

The formula gives the tail length L, in millions of kilometers, as follows:

mhelio = H + K * log10(r)
log10(Lo) = -0.0075*mhelio2 - 0.19*mhelio + 2.10
L = Lo * (1 - 10-4r) * (1 - 10-2r)

where H and K are the usual magnitude parameters, and r is the comets' distance from the Sun in AU.

Drawbacks of formula:

- it does not distinguish between ion and dust tails
- it does not take into account the continuing heating for some
  time after perihelion, which results in a longer tail after
  perihelion than before for a given solar distance on average.
  Such an improvement, however, is on my project list...
  This shortcoming, however, can be partially compensated by using
  two different sets of brightness parameters, which many comets
  with q < 1 AU actually show (pre- and postperihelion).
- not a consequence of the formula but equally important:
  the assumption of a tail directed exactly in the anti-solar
  direction can affect the apparent tail length in a recognizable
  way in the case of deviating or bended (dust) tails.

Coma no halo

I put a fake comet for testing in Stellarium with these values:

[0testcomet]
parent = Sun
orbit_Inclination = 40
coord_func = comet_orbit
orbit_Eccentricity = 0.432778
orbit_ArgOfPericenter = 117.8131
absolute_magnitude = -50
name = 0testComet
slope_parameter = 4
lighting = false
tex_map = nomap.png
color = 1.0, 1.0, 1.0
orbit_AscendingNode = 207.8674
albedo = 1
radius = 5
orbit_PericenterDistance = 10
type = comet
orbit_TimeAtPericenter = 2456447.93229167

It showed up on Stellarium like this:

So there was the textures/halo.png. Normally it is only visible as a dot[1]. But putting tex_halo = NULL in ssystem.ini didn't help.

[1]At absolute_magnitude = -10, it looked like how it usually does:

There shouldn't be a halo even when the comet is large.

Tracking it down to StelSkyDrawer.cpp/postDrawSky3dModel():
SolarSystem::draw()
   for each(Planet &p, systemPlanets)
        p->draw()

Planet::draw()
    core -> getSkyDrawer()-> postDrawSky3dModel(); // last line

Added the following public member functions to Planet:
void setIsComet(bool is);
bool getIsComet(); // returns true
And the member variable bool isComet, which by default is false, until set to true in SolarSystem.cpp when comet object is initialized.

Then, in postDrawSky3dModel(), halo is skipped if the object is a comet. So now 0testComet only shows up as a fuzzy ball of light. Still, at this magnitude it should have tails and the coma shouldn't be spherical.

Update: knowing whether or not planet is comet throughout the rest of the code could be useful since the way draw() will work should be different.

Update 2: To draw comet,
(1) postDrawSky3dModelComet(), or
(2) a drawing laid on top of postDrawSky3dModel()
i.e.

Planet::draw()
    if Comet,
          comet->postDrawSky3dModelComet()
    core -> getSkyDrawer()-> postDrawSky3dModel(); // last line
(3) a comet exclusive function
i.e.

Planet::draw()
    if Comet,
          comet->postDrawSky3dModelComet()
    else
          core -> getSkyDrawer()-> postDrawSky3dModel(); // last line

Probably shouldn't completely separate Comet class from Solar System or Planet parent class.

Pushing 1st branch

Added 34 comets to ssystem.ini and pushed branch testA to lp.

From aerith's weekly comet page, I picked the comets that could be seen in good condition and had < 15 magnitude, or better magnitude, and that were also going to be visible in the future. I also checked out JPL Horizons and got comets from several observable locations, although all of those comets were available in the MPC. From MPC, I picked some older comets that would return to observation 2013-2014, and all the comets discovered in 2012, as well as some more recent comets. All in all, I just used the SolarSystemEditor (SSE) plugin to add comets to ssystem.ini because I didn't have a need for manual adding. Then I just replaced the branch's data/ssystem.ini with ~/Library/Application\ Support/Stellarium/data/ssystem.ini. So... nothing much other than just pushing a branch to lp.

List of comets added:

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: