In summary, the OpenGL code is stagnant, and needs to be cleaned up. You
mention isolation of code, and that's one thing. There are others; most of
the defects registered against the app have to do with OpenGL (or drivers).
I thought Alex was having a conversion with someone on orbital data; would
you clarify that Alex?
On Tue, Mar 27, 2012 at 10:47 AM, No Idea <kiithsa...@gmail.com> 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.
>
>
> ------------------------------------------------------------------------------
> 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
> Stellarium-pubdevel@lists.sourceforge.net
> 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
Stellarium-pubdevel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel
