From: <fab...@go...> - 2007-11-19 16:00:09
|
Johannes, I added a new class skeleton called SkyDrawer. It will be the one taking care of drawing point sources or disk sources and taking care of all the tricky FOV/Eye adaptation/color dependencies. My idea is that an instance of it will be part of StelCore, and it will be used by StarMgr, SolarSystem, and any other module which needs to render sky point sources or disk halos. This class will definitely simplify the code by having a centralized point for doing this central operation. Part of the code of the stars drawing should move into it (the 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 color and brightness by b-v/magnitude steps should ideally be hidden into it. I think it is feasible but the interfaces for drawPointSource/drawDiskSource might need to be changed a bit though (maybe it would be better to use an index instead of floating values for b-v and mag). What do you think? Fabien |
From: Johannes G. <joh...@gm...> - 2007-11-20 08:42:10
|
Hello Fabien, it is certainly good to centralize drawing of point sorces (small bright objects). But I must still have a deeper look into the code, because I think this is no easy change. Johannes 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 > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel >=20 |
From: Johannes G. <joh...@gm...> - 2007-12-02 09:12:11
|
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 |
From: <fab...@go...> - 2007-12-04 22:36:42
|
On Dec 2, 2007 10:12 AM, Johannes Gajdosik <joh...@gm...> wrote= : > On 2007.11.19 16:59:51 CET, Fabien Ch=E9reau wrote: > > Johannes, > > > > I added a new class skeleton called SkyDrawer. It will be the one > > taking > > care of drawing point sources or disk sources and taking care of all > > the > > tricky FOV/Eye adaptation/color dependencies. > > My idea is that an instance of it will be part of StelCore, and it > > will be > > used by StarMgr, SolarSystem, and any other module which needs to > > render sky > > point sources or disk halos. This class will definitely simplify the > > code by > > having a centralized point for doing this central operation. > > > > Part of the code of the stars drawing should move into it (the > > 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 > > color > > and brightness by b-v/magnitude steps should ideally be hidden into > > it. I > > think it is feasible but the interfaces for > > drawPointSource/drawDiskSource > > might need to be changed a bit though (maybe it would be better to > > use an > > index instead of floating values for b-v and mag). > > > > What do you think? > > > > Fabien > > > > Hello Fabien, > > Sorry for the late reply. Yes, it would be good to have the same code > for drawing stars and planets. Planets, when they are small enough to > be drawn like stars. > > I do not really understand what the difference between > drawPointSource/drawDiskSource is. Is this for the "point_star" feature > that is used in some planetariums? In this case I doubt that it is > necessary to have different functions. Indeed I think it would be > better to have just a single function. > No the draw disk source is precisely the one you mention at the end of your email: it would be used to render halo for small disk like a zoomed-in planet. The class will hopefully consistently manage the transition between disk and point when using this method. > On the other hand it is essential to split to drawing function in 2 > steps: precomputation and drawing. Currently the precomputation output > is bmag/vmag. This does not neccessarily need to stay this way, it > depends on what is necessary for the rendering itself. And since there > was agreement about changing the rendering, I suggest to wrap bmag/vmag > in some class that belongs to SkyDrawer. This way nobody would be able > to use the drawing function without doing the precomputation step, and > all star drawing is automatically consistent. Also once this is > established, we could easily change the star rendering without changing > the other code. > Totally agree. There is also the question of whether it is relevant to make a special version of the drawPointSource() method optimized for consecutive calls, i.e, which avoids rebinding the texture or reseting openGL state. > Still the big question of transition between surface drawing and point > drawing for planets remains unsolved. In my opinion this is a task of > the Skydrawer class. > > Also I do not yet see any step in the direction of accomodating the > overall brightness to the brightness of the brightest object on screen > (Jupiter, the moon). But probably this must be solved outside of the > Skydrawer, although with the help of Skydrawer. Yeah, this should be done somewhere else, but it would be nice to add a method in Skydrawer which return the max luminance of the objects drawn during the last iteration. Fa |