[Kstars-devel] opengl_branch soon

[Jasem Mutlaq]

> I want to create an "opengl_branch" on cvs at some point, but I'm not sure
> if it's worthwhile at this point.  I'll list some of the biggest problems
> I'm facing now, and you guys can give your opinions on the matter:

> Problems to Solve:
>
> + One thing I was suprised by is that the constellation lines are not
> antialiased.  I was assuming that OpenGL automatically antialiases, but
> maybe that's a switch I need to turn on.
>
> +  The Milky Way is a surface projected on the celestial sphere with a
> complicated boundary.  Unfortunately, the way OpenGL works, individual
> polygons must be planar, and furthermore, large and complex polygons should
> be decomposed into a mesh of triangular facets.  So far, I have not found a
> convenient way to do this, other than manually defining each vertex in the
> mesh (in the correct order!).  This is a daunting task.  One idea I've been
> toying with is to forget about using the polygonal MW, and just use a
> bitmap image of the MW for an all-sky texture.  There are many really cool
> all-sky images available, such as:
> http://home.arcor-online.de/axel.mellinger/mwpan_aitoff.html
> http://www.ipac.caltech.edu/2mass/gallery/showcase/allsky_stars/index.html
> http://adc.gsfc.nasa.gov/mw/mmw_allsky.html

I like the first one, but having multi-wavelength all-sky paranoma is really 
cool. 

> + I added three more double variables to the SkyPoint class, which hold the
> X, Y and Z coordinates that OpenGL needs.  However, these values make the
> dms coordinate members somewhat redundant.  I haven't decided what to do
> about this; I haven't figured out yet how often it needs the XYZ
> representation compared to the RA/Dec representation.  If either of them is
> rarely used, we should not store it, we should just compute it on demand
> from the other. (This could very well be the case for XYZ; I construct
> lists of XYZ points during initialization, and OpenGL stores these itself
> in (video?) memory, so I potentially don't need the XYZ points after that
> initialization.  Both precession and the passage of time can be handled by
> simply manipulating the xRot,yRot,zRot values.  However, proper motion and
> atmospheric refraction will probably require new XYZ positions...)
>
> + The biggest issue is conceptual:  How are the new SkymapGL and the old
> Skymap going to co-exist?  I want to have a configure check to determine if
> the user has OpenGL, and compile support for it or not accordingly. 
> However, even if the user has OpenGL, we still may need the old drawing
> code (e.g., for printing).  It would be nice if we could have *one* SkyMap
> class, which includes both the GL and non-GL drawing and user-event
> functions.  I don't think this is possible, though.  I think we're going to
> need SkyMap derived from QWidget, and SkyMapGL derived from QGLWidget.  If
> so, I need to figure out how to minimize code duplication in this scheme,
> so that maintenence doesn't become a nightmare.

Would the following scheme work?

SkyMap2D : public QWidget, SkyMapAll
{
   All 2D drawing routines here ;
};

SkyMap3D: public QGLWidget, SkyMapAll
{
  All 3d drawing routines here; 
};

abstract class SkyMapAll
{
  abstract drawing routines;
};

SkyMap : public QObject {
  All non-drawing routines here;
 SkyMapAll *mapWidget;
};

That is, we need to seperate the 'abstractions' from the 'implemenations'. 
From a quick look at the code as it is, there is a tight coupling between 
drawing and events routines. The hard part is to write the drawing routines 
so that they have _one_ interface that the rest of the functions can 
interface with. This looks like a good case for the "Bridge" pattern.

> I know so little about OpenGL.  I worry that we'll find out later that I've
> done things in the worst possible way.  Oh well, I guess that happened in
> the early days of KStars too :).

I'm just learning OpenGL in class as well. Hopefully I can provide help in 2-3 
weeks when we start to dive in the exciting parts!

cheers,
Jasem