[Kstars-devel] Binary star data loading accomplished in Branch!

[Akarsh Simha]

Hi,

> a perfect solution for dealing with them.  I think we may end up having
> to have the named stars kept in their own little list that gets drawn
> separately from the unnamed stars.   This may cause a much larger 
> problem with nearly duplicated code, which might be "solved" by 
> replacing the StarComponent class with PlainStarComponent and 
> NamedStarComponent classes.

Why will this be required? The if(...) statement in the
StarComponent::readData() seems to be doing a good job, atleast for
now.

> One problem we face is that my idea of promoting dim named stars to the
> global stars group was a bad idea because it breaks the simple idea
> of ending the draw loop as soon as we get a star dimmer than a threshold
> magnitude.

How will it break that? We aren't sorting the list of names by
magnitude, but we are sorting them first by HTM index and then by
magnitude.

In any case, the number of dim stars with names is definitely going to
be very small.

> We also face a difficulty that my simple idea of duplicating some
> high PM stars to account for proper motion probably won't work for named 
> stars. Maybe it would be okay but I forsee possible difficulties.

We could do the good old reindexing on global stars. It shouldn't take
much. If we really want to save on that, then we should probably be
putting HD numbers or (if they don't exist) some other unique named ID
in our star name files.

We still have quite a few bits left over in our starData struct, both
in the flags and unused bytes. We could, if required, have an
additional bit indicating how the HD number should be interpreted. For
stars with HD numbers, we could keep that bit off. For stars without
HD numbers, we fill some out-of-range UID into the HD number field and
turn the bit on. That way, we will be able to provide a UID for each
named star, without causing any damage to the starData structure.

But we could probably keep that change and the decision for later.

> Right now, I'm leaning toward keeping the named stars in their own list 
> (StarIndex structure) that gets drawn separately from the rest of the 
> stars.  The named stars would get treated the way we are currently 
> treating all the stars.  They would even have HighPMStarLists and if 
> necessary, we could re-index all the named stars.

Why would this be necessary, again?

> global stars) if this makes the initialization code simpler for you.

> For example, one way to move forward is to leave your existing binary 
> initialization code more or less as it is but only use it for named 
> stars.  Then start afresh with code for loading the (unnamed) global 
> stars into StarBlocks.  If you would prefer to keep the named stars
> in same file as the unnamed global stars, that is fine with me too.

Would it be required to move from a constructor to a memcpy() even for
named stars? I don't think it will be worth the effort. (We will have
to make changes to SkyObject and make QString name etc into QString
*name etc, so that they can be malloced when required)

> I'm sorry if this seems to pull the rug out from under your feet a
> little.  In my defense: 1) this was supposed to be my week off so I 
> haven't been concentrating on the extended catalog as much as I might 
> have otherwise, and 2) you have made much more rapid progress than I
> had anticipated.

Thanks for your support all through.

Regards
Akarsh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.kde.org/pipermail/kstars-devel/attachments/20080604/25318a3f/attachment.pgp