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

[Akarsh Simha]

Hi James,

Thanks for your inputs. I'm yet to find time to read through the older
mail, but here are replies for this one.

> > 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).

This information is already there in the header, and we can make use
of it from there, as you suggest. I hadn't thought of this.

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

This makes things a lot more simpler.

> > 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.

Since I can read the record size off the header, I wouldn't be needing
this flag to be available throughout StarBlockList. It could just be
used in StarBlockList::fillToMag()

> > 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.

But wouldn't this remove the whole point of breaking StarComponent
into DeepStarComponent and StarComponent? Are you looking at a
NamedStarComponent and UnnamedStarComponent? That is going to be hard,
because we put both the stuff into the same data file.

I think we could do it this way:

-SkyMapComposite
    |
    |- StarComponent   [Handles static stars - named and unnamed]
    |    |- StarBlock [512];   // To store static Star Blocks.
    |- QList<DeepStarComponent *> [Handles dynamic stars]
    |    |- DeepStarComponent (Instance #1) [Holds Tycho-2]
    |    |    |- StarBlockList [512];
    |    |- DeepStarComponent (Instance #2) [Holds USNO NOMAD 1e8]
    |    |    |- StarBlockList [32768];
    |    |- DeepStarComponent (Instance #3) [Holds USNO NOMAD 1e9]
    |    |    |- StarBlockList [...........];
     

Maybe, as you suggested, we should move the QList<DeepStarComponent *>
into StarComponent, but I really amn't sure if that's the right way
(because DeepStarComponent and StarComponent are apples and
oranges). Maybe we could have a StarComponentComposite or something,
but I don't know if it is worth the effort. SkyMapComposite could
check up (for the presence of catalogs) and load Deep Stars as if they
were a different component altogether.

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/20080811/37071d68/attachment.pgp