[Stellarium-pubdevel] GSoC: Interested in participating

[No I. <kii...@gm...>]

Hello,

I'm Ferdinand Majerech aka kiith-sa,
a student of Informatics at University of Pavol Jozef Šafárik, Košice, Slovakia.

I'm interested in the "Irregular Solar System bodies" idea (or anything
else involving OpenGL or graphics in general).

So far I had a brief look at Stellarium source and got it to build
from the bzr repo.

Yesterday I was at the Stellarium IRC channel to discuss the project
and I was pointed to the mailing list. I still need some information
before applying to make sure I know what the project will involve.

As I said on the IRC, my first impression was that on the OpenGL side of things,
most of the work is done (i.e. the rendering itself). treaves said that there's
still a lot of OpenGL work to be done. Could someone clarify?
(my impression is that once you load the model, all you need is to pass
vertex/texcoord/normal array and transformation data to the
StelPainter class - which already handles the drawing part - what
other (GL) work is needed?)

Side note:
OpenGL code seems to be not well isolated (e.g. used directly in
objects being drawn) and rather messy and inefficient (e.g. no VBOs -
I understand the need for vertex arrays for e.g. some open source
drivers that don't support VBOs - but it seems most vertex data in
Stellarium is static once generated - and VBOs can bring huge speedup
there - so I think they should at least be optional) . Could
refactoring/isolating/optimizing GL code be another GSoC project?

Back to the project idea:
treaves said that NASA makes the models available in the .obj format.
(link? don't know what to google for)
I'd like to use this format directly, as it's trivial to load (very
straightforward, text-based format) (Assuming we're talking about the
Wavefront .obj, which is the most common one).
That said, since .obj is text-based, it needs to be parsed, and if the
vertex count is too
large, that might be slow. I could design a simple binary format if
that is the case, but
I'd rather first implement the .obj format and see how fast it is.

Another thing treaves mentioned is needed is orbital data for these bodies,
which will be needed to position/rotate them, and this data is available but
will need to be converted to JSON to be loaded by Stellarium.
I'm not an astronomer - not even a hobbyist, and I don't have the
needed knowledge
in this area. Where can I find this data, and what do I need to learn?
Is there any part of Stellarium source code I can look at to get a better idea?
(I.e. I'll need to figure out how to take orbital data and get the
position and rotation
(and maybe more parameters?) of a body at a given moment).


Also, are there any other significant things that need to be done as a part of
this project that I didn't notice?


Some information about me:

I'm a beginning open source enthusiast, mostly interested in game development.
Most of my projects are in Python, C++ and D. Recently, I started
working on various
small gamedev-oriented libraries for the D language.
I'm interested in graphics programming and anything related, and also
in (non-premature) optimization.


Some previous (one man, open source) projects:

MiniINI - a C++ INI parser and an experiment in optimization.
This was my toy project in some time - take something as trivial as INI parsing
and try to get it as fast as possible. Note that both the API and implementation
are designed for maximum performance, so they're not a good example of readable
C++ code.

miniini.tuxfamily.org
https://launchpad.net/miniini

D:YAML - A YAML parser for D.
What the title says, a YAML parser. This one is designed to be easy to use and
to have a nice API, although it's in D, not in C++.

dyaml.alwaysdata.net
https://github.com/kiith-sa/D-YAML


This turned out to be a wall of text. Sorry about that.


FM