[Kstars-devel] Interesting HTM timing results

[James Bowlin]

On Monday 29 May 2006 08:02 am, Jason Harris wrote:
> I think below-horizon stars will be more quickly clipped on the basis of
> their (already known) Altitude coordinate than with a half-sky HTM
> slice.

H'mm.  This assumes that the altitude of all the fixed stars is updated on
a regular basis which is almost certainly what is happening now.  I am
wondering what are the implications of only updating the fixed stars that
are actually on-screen?  Will this be a big time saver for us?  And if so,
will it break anything?  Can we fix it?

This makes me realize another issue you brought up much earlier.  If we
use HTM clipping then we will probably need at least two lists of all the
fixed stars:  the current list of all the stars and then the little lists
inside of all the trixels (the HTM folks call the smallest triangles in
their mesh trixels). 

In a previous message I had expressed concern that the HTM code may not
initially port well to different CPU's.  One thought that crossed my mind
was to make the HTM code a shared library and have its inclusion a
runtime option.  This might be waaay more trouble than its worth but I
was thinking about making a simple API for the clipping routines.  It
will have to be a bit more complicated than this but it could basically
boil down to:

   while ( reading HIP files )  {
      clipper->add_star( *star_object ) 
   }

   clipper->view_screen( coordinates )
   clipper->brightness_threshold( magnitude )

   iterator = clipper->visible_stars()
   while (iterator->has_stars() ) {
      star = iterator->next_star()
   }
   
The idea would be that if the HTM code fails on some systems, they could
fall back to manually clipping so Kstars would still function for them.
But even if we don't make HTM a runtime loadable module, creating a simple
API may be of some benefit for us.  It might make the transition to HTM
clipping easier since we can get the existing Kstars code working with the
current clipper and then just change one line to use the HTM clipper.

If we're clear on the API then the changes to the Kstars code don't have
to wait for the HTM code to be imported.  


> We should have this function, but for your purposes, it might be better
> to just add a "HTMComponent" to the skycomponents directory.  We could
> add a hotkey that toggles the HTM lines on/off.  I could pretty quickly
> add this component when the time comes.

I added two functions to the DCOP interface in the 3.5.x code:

  drawLine( ra1, dec1, ra2, dec2 )
  eraseLines()

I'll probably also add a drawColorLine( ..., color).

The lines are stored in kstarsdata.h as:

  QPtrList<CSegment> userLineList;

I can send you patches, or just the added code if/when you want.  It was 
very straightforward.  If I didn't do this I would have had to write an 
interface for gnuplot.

Unfortunately, their code is segfaulting when I ask it to give me the 
corners of the triangles.  This reminds me of something else I wanted to
tell you:  their top-level circleRegion() code didn't work properly when
I tried it.  One of the problems I saw was that they hard-coded in the
the level (20).  So I wrote my own, mostly by blindly copying the bits
of their circleRegion() that I liked and also taking hints from the
rect.cpp example code that I got from http://skyserver.org/htm/doc/.

FYI, here is how I implemented circle intersection:

        void intersect_circle(double ra, double dec, double rad) {
            SpatialDomain domain;
            RangeConvex cvx;
            double d = cos( 3.1415926535897932385E0 * rad/10800.0);
            SpatialConstraint c(SpatialVector(ra,dec), d);
            cvx.add(c); // [ed:RangeConvex::add]
            domain.add(cvx);
            domain.setOlevel(level);
            range = new HtmRange();
            domain.intersect(&htm->index(), range, false);
            iterator = new HtmRangeIterator(range);
        }

The reason I bring all of this up (besides the fact that I just got those
segfaults) is that I think I understand the major problem with their code.
When they first wrote it, they created their own class called ValueVector
which implemented some of what the std::vector class does.  I see a lot
of comments like:

//# Oct 18, 2001 : Dennis C. Dinge -- Replaced ValVec with std::vector

I think this conversion was incomplete.  For example, I think this is what
caused the two "typos" in src/SpatialInterface.cpp, one of which was fixed 
by GYF and the other that seemed to be fixed and then broken again.

I think they redefined ValueVector to be a certain kind of std::vector
and then updated some of the code to reflect this change.  I think the
nonsense results I got from their circleRegion() and the segfaults I'm 
getting now are both due to code not being updated properly.


-- 
Peace, James