[Kstars-devel] XYZ Rotation matrix in 3.5.x

[James Bowlin]

On Thursday 15 June 2006 09:35, you wrote:
> + It looks like you've implemented your own XYZ system for skypoint 
> ("skyP->cx")...did you know that I already added XYZ members to SkyPoint in 
> trunk?

Yes, I knew that.  It was one of the reasons I did my experiment in the 3.5
branch.  I didn't want to pollute your work in the trunk.  


> + I don't think we need a function like slowToScreenXYZ() to compute the 
> rotation matrix.  The matrix elements can be derived directly from the RA/Dec 
> of the Focus point: [rotation matrices snipped]

That's fine.  My use of slowToScreenXYZ() was based 100% on laziness.
I was taught matrix math in my first year in college but unfortunately,
the hot-shot teacher defined matrices backward from the standard conventions.
This created a confusion in me that lingers to this day.  
 
It could have taken me several days to create the rotation matrix from
scratch.  The slowToScreenXYZ() method allowed me to treat the rotations
and scaling as a "black box".

> + The code to convert from RA/Dec to Az/Alt is already in 
> SkyPoint::EquatorialToHorizontal(), commented out.  I did some timing tests 
> of it just now, compared to the existing spherical trig method.  To isolate 
> the codepath, I added a loop over the Stars which only calls 
> EquatorialToHorizontal() for each one, and bound this code to a key.
> It also prints out the elapsed time for the loop.
> 
> In this case, I see no difference at all between the two methods!  Both take 
> 30 ms, on average.  There's some extra overhead in the XYZ method, because I 
> redefine the rotation angles for each object, when these should only be done 
> once.  So there are two extra SinCos() calls.  Still, not a huge savings, I 
> think.

This is good to know.  It sounds like we are in agreement that the XYZ method
is not going to be a big win for us.  I was very surprised by this result and
I am glad to see that  wasn't just due to a stupid mistake on my part.

I thought that the rotation matrix was a terrific idea.  I still do.  I was
hoping that it would make the 4.0 code faster than 3.5 in one fell swoop.
But it seems that my intuition about the relative speeds of sin() and * was
way off.  

Where do we go from here?  I feel torn between helping to speed up 4.0 and
porting the Milky Way clipping to 4.0.  Maybe something as simple as enabling
the Solar System toggle will be enough to make 4.0 more usable for my testing.

Here are my current 4.0 times:

kstars: Milky Way  : 8 ms
kstars: Coord grid : 125 ms
kstars: Cons Bound : 76 ms
kstars: Cons Lines : 8 ms
kstars: Cons Names : 69 ms
kstars: Equator     : 59 ms
kstars: Ecliptic    : 7 ms
kstars: Deep sky    : 59 ms
kstars: Custom cat  : 0 ms
kstars: Stars       : 173 ms
kstars: Solar sys   : 162 ms
kstars: Name labels : 0 ms
kstars: Horizon     : 54 ms

Most of the slower things (except the Solar System) I can turn off via the
toggles.

One thing that strikes me is that the coord grid, the equator, and the
horizon all seem to be taking a lot of time.  Here, they take 238 ms
combined which is more than either the Solar System or the stars.
They each take much longer than the Milky Way (which was fully present
when I did the timing above).  Perhaps this will point us to what is
taking so long.

I've also noticed some little blips on the equator line and on some of
the grid lines that I don't see in the 3.5 version.  The equator has
a blip where it crosses the horizon line, almost like on an older schematic
diagram that indicates that wires cross but do not connect.  I also note
similar blips on the grid lines of constant ra near dec = 77 degrees.
Maybe this would also give us a clue to what is going on.

-- 
Peace, James