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

[James Bowlin]

On Sun August 10 2008, Akarsh Simha wrote:
> > 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? 

On the contrary, it would allow us to complete the split of 
StarComponent and DeepStarComponent because it will allow us to remove
a lot of code (from StarComponent) that is still repeated in those two 
classes.  You created DeepStarComponent (I presume) by making a copy
of StarComponent and deleting a bunch of code.  Ideally all of (or most 
of) the code that is now in DeepstarComponent, you will be able to
delete from StarComponent.

We have two different perspectives: you want to split things according
to static vs. dynamic and I want to split things according to the
data structures that hold the stars.

> Are you looking at a NamedStarComponent and UnnamedStarComponent?

As I mentioned before, I think the class structure should follow
the data structures.  The named stars are contained in a data structure
that is very different from the data structure that holds the dynamic
stars.  The unnamed statics stars are (currently) held in a data 
structure that is identical to the structure that holds the dynamic 
stars.  So, yes, the class structure I'm suggesting could (in theory) 
be called NamedStarComponent and UnnamedStarComponent. Or, as I said
originally:

> > H'mm. IMO maybe the data structures should drive the class design. 
> > I was thinking that StarComponent would only deal with named stars
> > (pretty much the old pre-GSoC behavior) and DeepStarComponent would
> > deal with stars that get dynamically loaded.  

> That is going to be hard, because we put both the stuff into the same
> data file. 

I agree with you that this will require that we put the named stars and
the unnamed static stars in two separate files.  I think this is what we
should do.  If you don't want to split that data up into two files then
we could always put the unnamed static stars in the same structure that
holds the named stars.  The downside to this approach is that the proper 
motion updates will take longer to compute because there will be more 
stars that we need to do the calculation for.

Another alternative would be to get rid of StarComponent altogether and
add the named stars to the static unnamed stars in a DeepStarComponent.
I'm not positive this will work, but it probably will.

> I think we could do it this way:
>
> -SkyMapComposite
>     |
>     |- StarComponent   [Handles static stars - named and unnamed]
>     |    |- StarBlock [512];   // To store static Star Blocks.
>     [snip]

IMO, one of the purposes of splitting up StarComponent was to get rid
of the situation where we have two different data structures holding
things we draw inside the same object.  IMO, having two draw loops
(one for each data structure) inside the same object is very ugly.
I think the code will be cleaner if we split off namedstars.dat from 
shallowstars.dat.  That way the datafiles and the class structure can 
reflect the data structure.  IMO, we want to make the draw loops clean 
and let everything else dance around it (i.e. split the data file) in 
order to make this happen.  I admit that this is more about beauty
than performance but I thought that that was what you were asking about.

ISTM that if you put (or keep) StarBlocks in StarComponent then you have
to repeat a bunch of code that is already in DeepStarComponent.  I've
been suggesting that we simply use the code that is already in 
DeepStarComponent instead of repeating it in StarComponent.

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

I agree that it is probably not worthwhile to migrate that code ATM.
That's why I said "I'm not sure this migration is the best thing to do".  

Also, as a side note, I see a big difference between a class holding
a data structure directly and a class holding an *object* that contains
another data structure.  The key difference in the case we're discussing
is whether there will be one draw loop or two in a given class.

PS: I realize that you had originally kept the named stars in a separate
file and I suggested that you to merge them with the unnamed static 
stars.  I was wrong.

-- 
Peace, James