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.
http://www.flickr.com/photos/81471534@N00/7025578313/in/photostream/
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 <[email protected]> wrote:
> 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
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> Stellarium-pubdevel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
>
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Stellarium-pubdevel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
