[Kstars-devel] OpenGL: the beginning

[Pablo de Vicente]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El Jueves, 27 de Noviembre de 2003 19:58, Jason Harris escribió:
> Hello,
>
> I have started an OpenGL framework that I plan to evolve into a
> replacement for our SkyMap widget.  Actually, my plan is to include
> both SkyMap and SkyMapGL, and let configure determine which should be
> used.

Hello Jason,

That is very nice. 

>
> I'm just getting started, but I thought I'd share with you what I have
> so far.  Get the tarball here:
>
> http://www.30doradus.org/kstars/kglbasic-0.1.tar.gz
>
> Do './configure' and 'make'; there's no need to do 'make install'.  The
> class KGLWidget is what will eventually be SkyMapGL; KGLWindow is just
> a KMainWindow container.

In my case './configure' did not complain that I did not have the glutg3-dev 
package installed so when I typed 'make', it did not work. Now I have 
installed glutg3-dev and it compiles fine.

>
> Right now, it just displays the coordinate grid, and you can scroll with
> the arrow keys and zoom in/out with the +/- keys.  It seems really
> smooth on my system, but I have hardware acceleration, so I don't know
> how software openGL compares yet.

My laptop does not have graphics hardware acceleration and it also works 
smoothly here.
 
>
> OpenGL will require some fundamental changes in how we represent objects
> in the sky.  The paradigm is that you create objects in a cartesian 3D
> volume (with X,Y,Z coordinates) and then define a "camera" for
> projecting those objects into the 2D window.
>
> For KStars, this means that each object's RA/Dec coordinates will be
> converted to X,Y,Z such that each lies on the surface of a "celestial
> sphere" in the 3D volume.  Once this is done, everything gets much
> simpler compared to our current setup.  For example, rather than
> recalculating every object's pixel coordinates whenever the Focus
> position is changed, we simply tell OpenGL that the camera has moved,
> and it computes a matrix transformation internally and re-renders the
> scene.  Also, things like Precession and Nutation can be simplified as
> rotational matrix transformations of the fundamental J2000 Celestial
> sphere.  We don't even need to determine if each object is visible on
> the screen; we just define a "clipping volume", and OpenGL takes care
> of it (say goodbye to checkVisibility()!).  The only calculations we'll
> need to do as a function of time are updating the (X,Y,Z) coordinates
> of solar system bodies, and of nearby stars (if/when we include proper
> motions).  Pretty cool.

 If the way we represent objects changes perhaps we should define at least two 
more classes, a sort of 3dStaticPoint and 3dDynamicPoint. The first one 
should represent a vector in cartesian and spherical coordinates. The second 
one should inherit from the first one and should have a constructor with 
3dStaticPoint, t0, and v, where 3dStaticPoint is the (x,y,z) position at time 
t0 and v is (vx,vy,vz) to allow for proper motions. A position for time t 
would be obtained by doing:
 r' = r + v (t-t0)
SkyPoint should then inherit from 3dDynamicPoint. In this way the 
transformation of coordinates from spherical to cartesian ones will be very 
simple. We will also need some function to compute distances from magnitudes, 
when parallax is not available. Are there objects without a measurable 
parallax in the modified Hipparcos catalogs you made, Jason?. And I have 
another question, does the Hipparcos catalog have Vlsr for some sources?.

Oh, well these are just loose thoughts, I am just thinking aloud.

 Next version of KStars will be wonderful...

regards,

Pablo.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/x7pcSItUpHl6kJERAtxjAJ0T39v/zqBt0YGLoTmCik3RU5+72QCbB0vg
JkwW0SalkSTjPGE3O/DFcZg=
=KVnb
-----END PGP SIGNATURE-----