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.