Re: [Stellarium-pubdevel] Sky Drawer

[Johannes G. <joh...@gm...>]

On 2007.11.19 16:59:51 CET, Fabien Ch=E9reau wrote:
> Johannes,
>=20
> I added a new class skeleton called SkyDrawer. It will be the one =20
> taking
> care of drawing point sources or disk sources and taking care of all =20
> the
> tricky FOV/Eye adaptation/color dependencies.
> My idea is that an instance of it will be part of StelCore, and it =20
> will be
> used by StarMgr, SolarSystem, and any other module which needs to =20
> render sky
> point sources or disk halos. This class will definitely simplify the =20
> code by
> having a centralized point for doing this central operation.
>=20
> Part of the code of the stars drawing should move into it (the =20
> MagConverter
> class).
> The problem now is to try to make something as fast as it is done in
> StarMgr, but with more generical interfaces, i.e. pre-computation of =20
> color
> and brightness by b-v/magnitude steps should ideally be hidden into =20
> it. I
> think it is feasible but the interfaces for =20
> drawPointSource/drawDiskSource
> might need to be changed a bit though (maybe it would be better to =20
> use an
> index instead of floating values for b-v and mag).
>=20
> What do you think?
>=20
> Fabien
>=20

Hello Fabien,

Sorry for the late reply. Yes, it would be good to have the same code =20
for drawing stars and planets. Planets, when they are small enough to =20
be drawn like stars.

I do not really understand what the difference between =20
drawPointSource/drawDiskSource is. Is this for the "point_star" feature =20
that is used in some planetariums? In this case I doubt that it is =20
necessary to have different functions. Indeed I think it would be =20
better to have just a single function.

On the other hand it is essential to split to drawing function in 2 =20
steps: precomputation and drawing. Currently the precomputation output =20
is bmag/vmag. This does not neccessarily need to stay this way, it =20
depends on what is necessary for the rendering itself. And since there =20
was agreement about changing the rendering, I suggest to wrap bmag/vmag =20
in some class that belongs to SkyDrawer. This way nobody would be able =20
to use the drawing function without doing the precomputation step, and =20
all star drawing is automatically consistent. Also once this is =20
established, we could easily change the star rendering without changing =20
the other code.

Still the big question of transition between surface drawing and point =20
drawing for planets remains unsolved. In my opinion this is a task of =20
the Skydrawer class.

Also I do not yet see any step in the direction of accomodating the =20
overall brightness to the brightness of the brightest object on screen =20
(Jupiter, the moon). But probably this must be solved outside of the =20
Skydrawer, although with the help of Skydrawer.

Yours,
Johannes