[Kstars-devel] NOMAD 1e8 - the ugly way.

[James Bowlin]

On Sat August 9 2008, Akarsh Simha wrote:
> I was wrong in thinking that we might be able to support USNO A or
> other catalogs. I realise that there is a major hurdle in this whole
> affair, because USNO A does not use HTM but uses a simple
> partitioning by (IIUC) declination ranges.

I had wondered about this but then I though you might have been
referring to simply the star record structure.

> In this case, it might be best to just stick to 32-bytes and 16-bytes
> per star and have a parameter in the StarBlockList constructor or
> something to decide between the two.

Ideally, this would simply be a field in the binary file header and
each DeepStarComponent would figure out what to do when it reads its
file header.  But if this is going to cause you extra work, it is
fine to have the star record size for each file hard coded for now.
I've envisioned a DeepStarComponent ctor that is given the file name
as one of the parameters and it then reads in all/most of the 
particulars from the file header.  But again it is fine to hard code
some or all of this information for now (and perhaps forever).

I agree that just sticking to 32-bytes and 16-bytes for now is a good
idea.

> I think I should move the Tycho-2 mag 12.5 deep star architecture
> into deepStarComponent, as you recommend, and I think I'll go ahead
> and do it.

Great.

> Now, if we don't support other catalogs, we brings in a lot of
> simplicity - I can retain the relatively ugly fillToMag because a
> better solution is far too much code duplication and not worth the
> effort, IMO. Instead, I can rename the StarBlockList::deepStars as
> StarBlockList::useDeepStarData and use the same StarBlockList to do
> both the Tycho-2 deep stars and NOMAD.

Great.

> One issue I see in this is that we decided that the first block of
> each StarBlockList is going to contain the static stars. Now, how do
> we translate this into the new way of looking at things? 

Great question!

> I think StarComponent should have its own bunch of StarBlockLists (or
> even better, just an array of StarBlocks should do) to handle the
> static stars and DeepStarComponent uses its own bunch of
> StarBlockLists for the dynamic stars. I haven't worked out the details
> of this as yet, and will do so later.

The fact that you've implemented multiple meshes gives us a lot of
flexibility.  One approach would be to put the static stars in their
own DeepStarComponent and simply not do any dynamic updating of that
instance.  It does everything the other DeepStarComponents do and less.
I guess there would have to be a flag inside of DeepStarComponent that
would turn off the dynamic updating.  It would be set either with a
special constructor or with a simple function call.  I think this will
be cleaner and easier than appending a StarBlock structure to 
StarComponent.  The flag is checked just once or twice per draw cycle
per DeepStarComponent so efficiency shouldn't be a concern.

The downside of this approach (and any approach that moves the static
stars out of a data structure that also contains dynamic stars) is that
it will require an extra iteration through the list of visible trixels.
But this is probably not a big deal.  If you wanted to keep the static
stars in the same structure as dynamic stars then there might be a 
clever way of doing it by simply adding an extra parameter (to either
DeepStarComponent or StarBlockList) that's simply the index of the first 
dynamic StarBlock.  For the one DeepStarComponent that contains static 
stars, this parameter is one, for all the other DeepStarComponents, the 
parameter is zero.  Since it is a parameter and not a flag (with 
an "if" statement) there shouldn't be much of an efficiency penalty.

A third approach would be to simply have an empty StarBlock at the 
beginning of every StarBlockList for cases where there is are no static 
stars. This might be the easiest way to go at first but it might be the 
least efficient.

Anyway, these are three other options that you can consider.  I think 
the first one is the cleanest and the 2nd one might be a tad more 
efficient, but probably not by much.

-- 
Peace, James