Summer of Code in Space 2016

From Stellarium Wiki
Jump to: navigation, search

Ideas for the SOCIS 2016 (ESA Summer of Code in Space).


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.

You should also become familiar with Stellarium's merge proposal review guideline, which outlines how your code will be reviewed before it's merged in Stellarium's code.

Suggested workflow

For each task that looks interesting to you:

  • Understand it - read the description and try to imagine what is required
  • Research it - if the description is unclear, you can ask for clarification and/or do some research and come up with your own ideas. Also, look at how Stellarium works with similar tasks
  • Sketch it - Check out Stellarium's code and build it (there are Bzr_checkout instructions on this wiki), look at what can be used and what needs to be done to implement your idea, how it will come together with the rest of Stellarium
  • All of this should prepare you to write a good proposal.


Irregular Solar System bodies

Brief explanation: 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 (textured "potatoid", optionally with normal mapped craters where high-res imagery is available), which should be loaded from models in the well-known 3D model format .OBJ. Rough shape data for about 20+ asteroids can be found somewhere on NASA's websites.

If the implementation causes visible performance degradation on weaker systems, there should be an option to turn the feature off. Many such features are enable/disabled via preferences.

Knowledge Prerequisite: OpenGL, C++

Mentor: Alexander Wolf (IRC: alexwolf)


Planetary surface nomenclature

Brief explanation: At the moment, Stellarium doesn't support the nomenclature for surface features on bodies of the Solar system. Nomenclature (naming topographical formations on the surface of the planet) should be enabled when a certain value for FOV has been reached, and marking should start with the biggest formations - like lunar maria. When user zooms further in, then labels for objects of first level (biggest formations) should be hidden, to make space for labels for the objects of second level, e.g. big craters and mountains.

This feature should support localization (multilingual translation) and should be enabled/disabled via preferences in case of visible performance degradation on weaker systems.

Knowledge Prerequisite: C++, Basic Astronomy, Geometry.

Mentor: Alexander Wolf (IRC: alexwolf)


Parallelize computation of planetary positions

Brief explanation: Most positional computation in Stellarium is done in the program's main thread on the central processing unit (CPU). Positions of minor bodies (asteroids, comets) are computed from their orbital elements following few well-known and not overly complex algorithms, which however require a few loops. However, in recent years CPUs come with several cores which allow parallel execution of several computations, and GPU computing became quite popular for SIMD operations.

There are 2 sub-tasks: First, computing the 8 main planet positions (and a few other "computational heavy" objects, like Pluto, the Moon and some other planetary satellites) should be parallelized, e.g. with OpenMP.

Further, it may be possible to compute positions of thousands of minor bodies directly on the GPU if loops can be limited to a fixed (short) number of iterations. This may require to first test a larger number of existing objects and count the typical number of required iterations depending on parts of the algorithms (e.g. trying various iterative solutions to Kepler's equation), and if the number of iterations to reach a certain accuracy can be identified, use this as fixed loop count in the GLSL implementation. Of course, if hardware is not capable of running the GPU implementation, a CPU-based fallback solution is still required.

Should that be too easy, of course the Satellites plugin can also profit from parallelizing the orbit computations.

This is mostly a software engineering task. If you are familiar with parallelizing computations and interested in GPGPU, this would be your place.

Knowledge Prerequisite: C++, OpenMP, GPGPU computing, some astronomical basics of orbital computation (although functions for CPU are already present. Algorithms from books available.)

Mentor: Georg Zotti



Brief explanation: The Scenery3D plugin allows walking in a 3D landscape with building models. This may be useful to plan observing locations near houses, but has been developed for archaeoastronomy. Some sites have developed over centuries, and it may be useful to study the site with changing appearance, e.g. when a stone circle has been rearranged. So, parts of the model should be visible only in certain years, and may be semi-transparent at the beginning and end of this period.

Given that this is only a relatively small extension of the current plugin, and given that there is a usable OBJ loader in this plugin, we would like to see this combined with the Irregular Solar System Bodies task (above).

Knowledge Prerequisite: C++, OpenGL, the OBJ/MTL format.

Mentor: Georg Zotti


D-Bus Interface

Brief explanation: D-Bus is an interprocess communication protocol which can be used to interface several programs running on the same computer. There is an idea (Wishlist entry) to link the three most popular open-source programs to make optimal use of the best features of each program. D-Bus is usually found on modern Linux systems as regular system component, and can also be installed on MacOS X and Windows.

Note that last year's SoCiS initiated a Remote Control plugin which allows controlling Stellarium via an http interface. This required major changes in the internal communication between Stellarium's modules (how the modules' properties are propagated). The D-Bus communication can make use of much of this new infrastructure, and should use a similar syntax. (The plugin is being finalized in these weeks and will be available around May 2016.)

Knowledge Prerequisite: C++, Qt, a bit of interprocess communication, and some experience with Stellarium, KStars, and maybe Cartes du Ciel.

Mentor: Georg Zotti


Your idea

You can propose your idea for Stellarium. If it will be great we can approve it.


Personal tools
in this wiki
other languages