[Kstars-devel] Draft GSOC Proposal

[Henry de Valence]

Hi, I've been talking to Akarsh about the GSOC proposal idea for OpenGL support
in KStars, and I've written a first draft of a proposal. I would really appreciate any 
comments on it before I put it on the GSOC submission website. 

Henry de Valence

Proposal follows.

== Name: Henry de Valence

== Email/IM: hdevalence at gmail.com

== IRC: hdevalence (Freenode)

== Location: Toronto, ON, Canada in the summer, Kingston, ON, Canada currently;
        both GMT-5.

== Proposal Title: Improving the visual appeal of KStars via OpenGL

== Motivation/Goal: 
KStars has many advanced features, but its graphics lag behind
other software, such as Stellarium. This project aims to increase the aesthetic
appeal of the visuals in KStars via OpenGL painting support. This will allow
KStars to paint more complex, visually appealing graphics, without sacrificing
speed.

Specifically, I'd like to implement:
-- A second painting backend based on OpenGL;
-- Support for Bortle classes (light pollution);
-- Support for sky-shading and tone-mapping as in Stellarium;

Since not all computers have OpenGL capabilities, we will want to keep the
current painting system for those who cannot, or for some reason do not want
to, use OpenGL.

== Implementation Details:
In order to make use of OpenGL, I'll first refactor the current SkyMap class so
that it no longer inherits from QWidget. Instead, there will be two classes,
say SkyMapWidget and SkyMapGLWidget, that inherit from both SkyMap and
QWidget/QGLWidget. Whether the SkyMapWidget or the SkyMapGLWidget is used
depends on whether we are to be using GL or not.
Then each object that is to be drawn will have code to draw
that object using OpenGL: texturemapping, halo effects, etc. Since OpenGL's 3d
projections are used for the usual type of 3d scene, not the type of projection
needed for painting a sky, I'll keep the current approach of doing the
projection in KStars and painting in 2d. In order to keep common code (e.g.,
the code needed to draw a point light source realistically) in one place, there
will be a class, say, KSPainter or something similar, that provides these sorts
of functions, and allows for speed improvements by doing multiple drawing
instructions at once rather than doing them one at a time.

For the Bortle classes, we need to filter the objects to be drawn by magnitude
and, further, adjust the apparent brightness of the drawn object
(e.g., a star), taking into account the brightness of the sky. By keeping
common drawing code in a helper class, we can make it so that the individual
objects don't need to know about the sky conditions; that will be taken care of
in the helper class. There are various implementations of an algorithm to do
this, which was described in Brad Schaefer's article in the May 1998 Sky &
Telescope, "To the Visual Limits", one of which is in Stellarium.

The algorithms used in Stellarium to do the sky-shading and tone-mapping are
described in [1] [2] [3] [4] [5]; since Stellarium is a GPL program also, it may be
possible to directly adapt the code used there. If this is not possible, then
having the Stellarium code to refer to makes it easier to implement the
algorithms.

The graphics card on my laptop is an Intel X3100, and I'll be using this when I
develop the code, but I intend to test it on other graphics cards / system
configurations, by a combination of personally testing it on other computers I
have access to, and recruiting testers.

== Timeline (Tentative):
My last exam is at the end of April, and I won't have any other commitments
until the beginning of September, so I will be free to work on the project
full-time.
Up to May 24: Read and understand KStars code, Stellarium code, and study
        algorithms to be used.
Weeks 1,2: Refactor code and write prototype OpenGL methods for sky objects
        using basic textures.
Weeks 3,4,5: Make sky object GL drawing look more realistic: make bright stars
        have small halos, adjust the apparent brightness, implement Bortle
        classes, and more generally follow the techniques in [3].
Week 6: Implement realistic sky-shading and tone-mapping, as described in
        the four papers mentioned. It may be possible to adapt the
        implementation of these algorithms from Stellarium, or it may not.
Weeks 7,8: Optimize, test and bugfix: benchmark code, optimize for speed, check
        for bugs, and test code on graphics cards other than my own.

== About Me:
I am a student studying at Queen's University at Kingston. I am currently
finishing my first year, and am hoping to do a major/minor in Mathematics and
Philosophy, respectively. I have strong skills in Linear Algebra, and am an A
student.

I've been a KDE/Linux user for 4 years now, and I've been programming since
about the time I started using Linux. I've contributed to KDE in the past,
working on Marble, but unfortunately due to heavy coursework at university I
haven't been able to contribute much. I really enjoy making programs that do
visually interesting things, which is why I am personally interested in this
project.

I have a working knowledge of Qt C++, some knowledge of OpenGL and C, and
experience using various other programming languages/tools (e.g., Java, Python,
Processing, etc).

My contributions to KDE can be seen on CIA.vc at [6].

[1] "Tone Reproduction for Realistic Images", Tumblin and Rushmeier, IEEE
        Computer Graphics & Application, November 1993
[2] "Tone Reproduction and Physically Based Spectral Rendering", Devlin,
        Chalmers, Wilkie and Purgathofer in EUROGRAPHICS 2002
[3] "Night Rendering", H. Wann Jensen, S. Premoze, P. Shirley, W.B. Thompson,
        J.A. Ferwerda, M.M. Stark
[4] "A Visibility Matching Tone Reproduction Operator for High Dynamic Range
        Scenes", G.W. Larson, H. Rushmeier, C. Piatko
[5] "A Practical Analytic Model for Daylight" by A. J. Preetham, Peter Shirley
        and Brian Smits.
[6] http://cia.vc/stats/author/hdevalence/