Yes, I agree. the way the 'modules' are currently implemented is a very bad design.  It not only makes this difficult, but many other things as well.

This entire design could be refactored, but, again, that's a pretty major undertaking. I'm open for any suggestions in this area.

On Wed, Mar 28, 2012 at 10:36 PM, bdwashbu <> wrote:
I would like to help with anything OpenGL related.  I've been playing around in StelSkyDrawer and that needed quite a bit of refactoring to make the use of vertexArrays much less confusing.  A big issue I'm running into lately is draw order.  As Stellarium gains more post-processing effects especially, draw order is really essential and it seems to be something we have minimal control over.

For example, something I've been experimenting with is an atmospheric distortion effect (poor seeing), which could be a fundamental effect that not only distorts distant objects, but also makes stars twinkle for "free".  Since both of these phenomenon stem from the same process in real life, it'd be cool for the same effect to cause both in Stellarium as well.

I got as far as making the stars slowly distort and twist by using a pixel shader, but it turns out its really hard to apply the effect to both the stars and the planets/moons due to draw order!  So count me in.  

-- Brian

On Tue, Mar 27, 2012 at 7:16 AM, No Idea <> wrote:

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.

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++.

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


This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
Stellarium-pubdevel mailing list

This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
Stellarium-pubdevel mailing list