On Aug 6, 2011 9:13 PM, "Eleni-Maria Stea" <elene.mst@gmail.com> wrote:
> Hello! :)
> I m starting getting an idea on how stellarium code is organized
> (although I haven't find everything yet) and I would like to ask you
> for some clarifications and advice on how to change some things before
> I start doing my first commits:
> 1 - I would like to create a class that supports the major shader
> operations (eg loading, compiling, debugging, running a shader prog,
> setting the uniform variables etc) in order to use it wherever there
> is a need to use a shader. I thing the best place to put it is in a
> file in src/core/ and a good name would be something like
> StelShader.hpp/cpp or StelShaderMgr.cpp/hpp. Is this ok or you believe
> it is better to put the shader class somewhere else? I also wonder if
> there is already such a class but I didn't manage to find it because I
> ve seen that OpenGL ES is used in some places... If it exists could
> you please tell me where it is? I ve searched for some common OpenGL
> functions related to shaders to locate such a file with no big success
> :)

You should use the qt classes for that. They offer a (quite low level) layer over shaders operations. See the code in StelPainter using shaders. You try to write shaders compatible with both opengl es and desktop opengl (basically write for opengl es).

> 2 - I ve seen that there is a directory data/shaders with a .glsl
> shader program inside. Do I have to put there all the shaders or this
> is for OpenGL ES and I better create a new directory in src or
> src/modules/ for example? (If yes could I also name my shaders .vert
> and .frag instead of .glsl because it is less comfusing for the
> future?)

You can put new shaders there for the mean time. We can move them later if necessary. Also feel free to choose the names you want.

> 3- If I understood correctly, the planet attributes are loaded at
> using the SolarSystem::loadPlanets(const QString &) function line 699
> in file src/core/modules/SolarSystem.cpp from a qstring generated
> after parsing the file "ssystem.ini" and doing some process (If I am
> wrong please correct me!) In order to add an extra map (eg a
> "normal_map" similarly to the already existing attribute "tex_map") I
> thought of putting the normal maps in the texture directory, add an
> extra parameter [normal_map] to the ssystem.ini for these and then
> treat it like a second texture on the Planet class (after adding
> multitexturing support). Do you agree with this approach? Maybe I
> could just name the normal maps <texture_filename>_nmap.png and load
> them only when both the <texture_filename>.png
> <texture_filename>_nmap.png exist or do something else you propose
> (but the first idea seems more "correct" to me at the moment).

Sounds good.

> 4- Could you please tell me where stellarium textures are taken from
> so that I look for normal or height maps? (At the moment I generated
> some very very creepy and wrong ones using a gimp plugin but I believe
> that it won't be difficult to find height or normal maps of the
> supported textures)

As far as i understand, you need normal maps only for planets with craters, like the moon. I think this data can be found online, but the problem is that at some point we'll also need the rights to distribute the data in stellarium as well. Nasa data sets are usually public domain.

> That's all for now, sorry for my huge e-mail!! :)
> Thank you in advance!


> Eleni
> ------------------------------------------------------------------------------
> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Stellarium-pubdevel mailing list
> Stellarium-pubdevel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel