[Kstars-devel] HTM clipping of extended objects (long)

[Jason Harris]

Hi James,

Summarizing your proposal for extended objects, as I understand it:

Add a drawID variable to either SkyPoint or SkyObject.  There is a unique 
globalDrawID that is incremented on each draw cycle, and if a visible object 
is encountered whose internal drawID is not equal to the globalDrawID, then 
it is drawn to the screen, and its drawID is set to globalDrawID.

How big are triangles at level 4?  For most SkyObjects, this might not be 
necessary if the triangles are bigger than the objects.  Partially-visible 
triangles provide a natural "buffer region" of objects which are drawn, even 
though their central positions are slightly offscreen.

This reasoning doesn't apply to constellation lines/boundaries or the Milky 
Way, of course.  I think your drawID idea will work for these objects, but 
I'm trying to figure out if it's the best way to do it.  

I have another idea I'd like you to consider, that takes advantage of the 
hierarchical part of HTM.  Consider the pair of points in a constellation 
line segment.  They occupy different level-4 triangles, but they *are* 
localized on the sky, so they should occupy the same triangle at level 3, 2 
or 1.  We can just check the visibility of the smallest triangle in the mesh 
that encloses both of the points of the line segment.  So if the two points 
occupy triangles N01232 and N01231, then they are both in the same level-3 
triangle (N0123), so the visibility of that triangle should be checked.  I 
like this idea, because it nicely sidesteps the problem of what to do when 
the display is zoomed in so far that point A is offscreen to the left, and 
point B is offscreen to the right.

Of course, there will be cases where the two points don't even occupy the same 
toplevel triangle (e.g., any line that crosses the equator).  In this case, 
we'll just have to draw the line if either of the toplevel triangles is 
visible (even though the line will usually really be offscreen in this 
case...maybe there's a more clever way to handle it).

I think this method will robustly handle the visibility of these objects made 
up of groups of skypoints.  The downside is that it's somewhat inefficient; 
you will occasionally be drawing objects that aren't really onscreen.  
However, the number of these objects is relatively small, so I don't think it 
will be a significant performance hit.

So basically, I am proposing that we keep these extended objects out of the 
HTM object lists; those should be reserved for objects which are describable 
by one SkyPoint (i.e, all the SkyObjects).  Those objects which are pairs or 
lists of SkyPoints should internally store the identification of the smallest 
HTM triangle which encloses all of its constituent points, and the visibility 
of this triangle should be used to determine whether the object should be 
drawn.  

What do you think?

Jason

-- 
-------------------------------
KStars: http://edu.kde.org/kstars
Forums: http://kstars.30doradus.org