[Kstars-devel] Quaternions & Co (was: Plans for threading in KStars)

[Aleksey Khudyakov]

On Sat, Nov 19, 2011 at 6:44 PM, Akarsh Simha <akarshsimha at gmail.com> wrote:
> On Sat, Nov 19, 2011 at 05:27:56PM +0300, Alexey Khudyakov wrote:
>> > So you suggest that we can get away with computing Alt / Az and
>> > precessed RA / Dec on-demand, since they are not really required for
>> > drawing.
>> >
>> Exactly. We can make one step further and store only equatorial (for
>> stars, planets, etc) or horizontal (zenith, satellites) coordinates. This
>> means that we have to store two set quaternions for drawing. One
>> for transforming equatorial coordinates and one for horizontal.
>>
>> This means that we don't need to keep equatorial and horizontal
>> coordinates in sync anymore. Costly EquatorialToHorizontal call
>> optimizes to nothing. Code would became vastly simpler.
>
> That makes sense.
>
> How about refraction corrections? They are altitude dependent, as is
> bending of light around the sun.
>
> So do we incur the additional cost of QuaternionToHorizontal()
> conversion only when these two settings are enabled? Fair enough, I
> would disable these settings for faster speed. Otherwise, we need to
> find a way of expressing them in terms of quaternions.
>
I forgot about them. With refraction enabled in horizontal coordinates
view

Object with equatorial coordinates
  1. Transform from eq. to hor. coordinates.
  2. Apply refraction correction
  3. Transform to project

For object with horizontal coordinates only two last steps are needed,


Refraction correction could be implemented for vectors similarly to what
we do now. We'll need two lookup tables. One for new Z and one for
factor for X and Y which are needed to keep vector unit.

And it's desirable to rotate sphere to some fixed position (e.g. (0,0,1) is
center of screen Y axis points up X right) because it's much easier
to project from specific position and easier to encode arbitrary rotation
(north could point not only to the top of screen) which is useful when
working with astrophoto.

As for relativistic correction for the Sun. I'm not sure whether we need
them at all.


>
> That's not a problem, since we are going to project anyway.
>
> Also, it's not hard to keep the "base" quaternion (J2000.0
> coordinates) in sync with RA / Dec. We could just sync it at load and
> make it private, so nobody can touch it. Also, (RA, Dec) dmses must
> become setRA() and setDec() inline functions, so that they can update
> the quaternion.
>
Do you speak about precession/nutation or proper motion?
Former could be represented as time dependent quaternion while
latter must be applied individually.

> Also, I suspect we have some non-J2000 catalogs. There could be bugs
> lying around because of this for ages, without us knowing. Something
> we should probably check while implementing this change.
>
Sure thing