[Kstars-devel] Some user feedback

[Akarsh Simha]

Hi all!

Wow! HTM seems too complicated to switch over to, right now. I will
try to spare some time trying to work on making the Star Database into
something HTM compliant.

For the time being, however, I think that we could still split the
Hiparcos data further and gain some speed. This should be easier to
implement. What we could do is, as I mentioned earlier, divide the sky
into 24 RA Hour ranges and have a set of magnitude-sorted (like we
have now) catalog files for each of these slots. This way, we could
load whatever is in the range of view only.

Would this work? I don't mind taking up the task of converting the
data files to something similar to what I have described now. I will
also try HTM, but slowly.

On 5/29/07, Jason Harris <jharris at 30doradus.org> wrote:
> Hello,
>
> On Monday 28 May 2007 14:40, Alexey Khudyakov wrote:
> > > Adding more stars is trivial.  I think I even have the kstars-formatted
> > > Hipparcos catalog down to 12th magnitude on disk.  The problem is adding
> > > millions of stars without bogging down the program or having ridiculous
> > > memory requirements.  The way to do it is to selectively load faint stars
> > > only in the region immediately surrounding the current focus point, and
> > > only at high zoom.  We had someone working on the infrastructure required
> > > to do this, but we haven't seen the results.  Let me know if you want to
> > > know more about it.
> >
> > Yes I do. And how are stars and other objects stored in memory?
> >
> See kstars/kstars/skycomponents/README for a good start...
>
> To learn more about the infrastructure to allow for a much larger number of
> objects to be displayed, search our mailing list archive for "htm".
> I introduced the concept in this message:
> http://lists.kde.org/?l=kstars-devel&m=114840892829281&w=2
>
> The short version is, we had someone who put a lot of effort into implementing
> HTM for KStars, but he had to stop working on it before it was finished.
>
> > > > I can't set kstars to display globular
> > > > clusters brighter than 10m
> > > > and stars. When I searching for globlar clusters I don't need nor
> > > > galaxies nor nebulae.
> > > > And too faint objects only clutter window and slows down rendering.
> > >
> > > It's an interesting idea, but why don't you just create an observing list
> > > of all theglobular clusters?  That automatically highlights GCs in the
> > > map. We'd need a way to add this feature without cluttering the interface
> > > for the>90% of the users who wouldn't care about it.
> >
> > Yes, I can, and this is really nice feature. But it has one disadvantage
> > it's slow. Adding merely 129 planetary nebulae takes about 30 seconds. List
> > clearing take same amount of time. What can be cause of such slowness?
> >
> Adding objects isn't too slow for me, but I do see a big delay when clearing
> the list.  I'll look into it.
>
> > > > Third - deep-sky rendering. Deep-skyes are rendered as outlines. I
> > > > think, they should be filled
> > > > with some color. It's too easy to overlook them. And deepskyes smaller
> > > > than certain size should
> > > > be rendered as symbols. One pixel deep-sky is very hard to notice and
> > > > doesn't make much
> > > > sense.
> > >
> > > Good ideas; I would welcome patches for these changes.
> >
> > And this is connected closely to point above. Now there are a _lot_ of
> > faint objects on sky map. They are nearly invisible. If they will be
> > rendered as symbols map would be filled with faint galaxies. And we would
> > need to set cut off magnitude. May be manually, may be via some
> > auto-adjustment, may be via some combination.
> >
> To avoid overcrowding the map at low zoom, we should render objects with their
> true angular size, even if it means drawing the object as a point (in fact,
> maybe we can save time by not rendering very small objects at all when they
> will only appear as points anyway).  Only at high zoom should we switch to a
> minimum size.  What do you think?
>
> > > I don't want to put coordinates in the popup menu; they are better placed
> > > in the details window.  I'm also not excited about putting the magnitude
> > > there; you can already display stellar mags directly on the sky map, if
> > > that's what you are interested in.  I'd be more willing to put magnitudes
> > > and angular sizes in the "object infobox" (the floating box showing name
> > > and coordinates of the currently-focused object).
> >
> > Do you mean small label which appears near sky object when I hold mouse
> > cursor on it. It's simply faster to right-click on star than wait for
> > pop-up. This is matter of opinion.
> >
> No, I mean the three lines of text in the upper right corner of the window,
> displaying the name of the centered object ("Focused on: Andromeda galaxy"),
> and then its RA/Dec and Az/Alt coordinates.  We could add another line
> showing things like angular size and magnitude of the centered object.
>
> > > "not sufficient for me" != "bad or non-existent"
> >
> > I've forgot to mark that with four letters: "IMHO"
>
> Remeber the KDE wisdom: "you are not necessarily your users"
>
> regards,
> Jason
>
> --
> Jason Harris
> jharris at 30doradus.org
> _______________________________________________
> Kstars-devel mailing list
> Kstars-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kstars-devel
>


-- 
Regards,
     Akarsh
http://www.bas.org.in
http://www.nascent-technologies.com