Google Summer of Code 2012

From Stellarium Wiki
Revision as of 16:16, 16 February 2012 by Alexwolf (Talk | contribs)
Jump to: navigation, search

Ideas for the GSoC 2012 (Google Summer of Code 2012)

Contents

Common requirements

All of these tasks require knowledge of C/C++, as Stellarium is written in it, and some knowledge of the Qt framework (or willingness to learn the basics very quickly), because Stellarium relies heavily on it, especially for its GUI.

Ideas/projects

Support for collections of multi-resolution sky surveys

Brief explanation: Work has already started on this project and we have a working initial code displaying images encoded in the TOAST format. The image data for each sky survey needs to be pre-processed and stored on a server. We currently have a server hosted by the Free Software Fundation France with a potentially high bandwith for serving the (huge amount of) data.

Knowledge Prerequisite: OpenGL, Geometry, Astronomy.

Mentor:

Meteor shower calendar

See Proposals:Realistic meteor showers, Launchpad Blueprint: https://blueprints.launchpad.net/stellarium/+spec/realistic-meteor-showers

Brief explanation: At the moment, Stellarium can show meteors, but they are simply decorative - they appear at random points at a rate set by the user. The existing code of the MeteorMgr class can be used as a base for a plug-in that shows more or less scientifically accurate meteor showers. They are not random - the meteors appear to "stream" from a single point in the celestial sphere, the radiant.

This feature can take several forms:

  • Weak form: Allows the user to define a meteor shower and/or pick it from a list, and then to turn it on and off on a whim.
  • Strong form: Keeps a meteor shower catalogue in JSON format as with the other kinds of objects tracked by Stellarium, and shows only what should be in the sky for the given date. The catalogue should contain information about the radiant and the annual changes in the zenith hourly rate (as meteor showers typically have a peak and are active some time before and after that; a normal distribution function can do).
  • Very strong form: Use a professional model for predicting meteor showers, based on the orbits of the clouds of space particles that cause them.

Data about visual meteor showers can be found on the website of the International Meteor Organization (e.g. calendar for 2011)

The implementation should allow the user to toggle a marker showing the radiant.

Knowledge Prerequisite: OpenGL, Geometry, Basic Astronomy.

Mentor:

Realistic comet rendering

See Proposals:Realistic comet rendering, Launchpad Blueprint: https://blueprints.launchpad.net/stellarium/+spec/realistic-comet-rendering

Brief explanation: At the moment, Stellarium supports comets as solar system bodies, but displays them as star-like objects. More realistic and more scientifically accurate rendering of a comet requires the rendering of four elements - a core, a coma and two tails, oriented according to the comet's relative position to the Sun and its direction. The tails and the coma should appear only when the comet is close enough to the Sun. (See the Wikipedia article on comets for more information.)

As not all comets are identical, this feature should allow comet customization. The visual characteristics of comets should be stored along with their orbital elements.

Knowledge Prerequisite: OpenGL, some mathematics and astronomy.

Mentor:

Satellite and ring shadows on parent planets

At the moment, satellites and ring in Stellarium don't cast visible shadows on their parent planets and vice versa (solar and lunar eclipses are implemented as special cases).

The implementation should be done having in mind that not all computers running Stellarium can use OpenGL shaders and other OpenGL2 features. It should either provide a fall-back mechanism in case they are not available, or it should be implemented in a way that doesn't use them. If the implementation causes visible performance degradation on weaker systems, there should be an option for to turn the feature off.

Knowledge Prerequisite: OpenGL

Irregular Solar System bodies

At the moment, all Solar System bodies are rendered as spheroids. This is fine for all planets and large satellites, but unrealistic for all asteroids and some smaller moons (such as Phobos, etc.). Realistic rendering of asteroids requires the rendering of a simple 3D model, either in some accepted open 3D model format (e.g. COLLADA?) or in a simple format developed for Stellarium. Rough shape data for about 20+ asteroids can be found somewhere on NASA's websites. Working on this project should start with finding it and deciding which format to use.

The implementation should be done having in mind that not all computers running Stellarium can use OpenGL shaders and other OpenGL2 features. It should either provide a fall-back mechanism in case they are not available, or it should be implemented in a way that doesn't use them. If the implementation causes visible performance degradation on weaker systems, there should be an option for to turn the feature off.

Knowledge Prerequisite: OpenGL

Personal tools
Namespaces
Variants
Actions
in this wiki
other languages
Toolbox