[Kstars-devel] opengl_branch soon

[Jason Harris]

Hello,

Just an update of the openGL stuff.  I now have a (severely crippled) version 
of KStars that displays parts of the sky using OpenGL.  Specifically, the 
coordinate grid, named stars and constellation lines are currently displayed 
(the stars are just white dots at this point, all the same size).  Adding 
most of the other objects should be pretty easy, except for the Milky Way 
(see below).  The display can be slewed with the arrow keys, and zoomed in 
and out with the +/- keys.

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:

Missing Features:

+ The "Focus" position is not used at all, the sky is oriented with three 
rotation angles (xRot, yRot, zRot).  I need to write code that converts from 
this to the RA and Dec of the center position.

+ Similarly, I need to update the functions that convert between screen pixel 
coordinates and the RA and Dec of that screen position.  Since this doesn't 
exist yet, you can't drag with the mouse, and the coordinates of the cursor 
in the statusbar are currently meaningless.  Also, when you right-click, 
there's no telling what popup menu you're going to get (because there's a 
"phantom" sky still using the old skymap...the mouse click has a 
corresponding RA/Dec, it just does not conform to the displayed sky yet :) 

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 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.

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 :).

regards,
Jason
-- 
-------------------------------
KStars: KDE Desktop Planetarium
kstars at 30doradus.org