[Kstars-devel] Kstars-devel Digest, Vol 34, Issue 15
brian hurren
brianhurren at yahoo.com
Thu Jun 1 16:37:44 CEST 2006
thats exactly what I mean. merging kstars and kde desktop togeather. with everyone jump in on the 3d desktop band wagon, we could create somthing with substance and educational benifit.
also how do I attach images to the dome. I want to put up couple of photos of the magalin clouds. I was also going to do some drawings of the zodiac constelations in the stile of an old 17 century starchart. maybe siepia on black and I was wondering how to render them onto the dome? send them in see what you think.
I am also demonstrating kstars at our next astronomical society meeting. I am sure they will all be impressed. can you get kstars on a seperate bootable disk like a knopics disk or somthing, so my deprived windows using friends can use it also.
kstars-devel-request at kde.org wrote:
Send Kstars-devel mailing list submissions to
kstars-devel at kde.org
To subscribe or unsubscribe via the World Wide Web, visit
https://mail.kde.org/mailman/listinfo/kstars-devel
or, via email, send a message with subject or body 'help' to
kstars-devel-request at kde.org
You can reach the person managing the list at
kstars-devel-owner at kde.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Kstars-devel digest..."
Today's Topics:
1. HTM circle/rectange timing results (James Bowlin)
2. Interesting HTM timing results (James Bowlin)
3. kstars as a desktop (brian hurren)
4. Re: kstars as a desktop (Jason Harris)
----------------------------------------------------------------------
Message: 1
Date: Sun, 28 May 2006 15:17:49 -0600
From: James Bowlin
Subject: [Kstars-devel] HTM circle/rectange timing results
To: KStars Development Mailing List
Message-ID: <200605281517.49783.bowlin at mindspring.com>
Content-Type: text/plain; charset="us-ascii"
I created two simple timing loops (in C, not Perl) to test the timing
of intersect_circle() vs. intersect_rect(). I am using the Perl interface
which has been incredibly useful.
In these examples, I am using a level 5 mesh which will average 16 stars
per triangle.
For small areas, the circle beats out the rectangle by a factor of 4.3.
For an area of roughly 1 degree^2, both circle() and rectangle() find the
same three triangles:
10000 level 5, 1-degree rects took 6.11 seconds
1637 rectangles/second
10000 level 5, 1-degree circles took 1.43 seconds
6993 circles/second
This makes sense. The time is dominated by the construction of the
constraints and the rectangle has 4 times as many constraints as the
circle.
For a larger area, roughly 10 degrees x 10 degrees, about 70 triangles
are returned and the speed advantage of the circle decreases:
1000 level 5, 10-degree rects took 2.27 seconds
441 rectangles/second
1000 level 5, 10-degree circles took 0.85 seconds
1176 circles/second
Note that both the circle() and rectangle() significantly slowed down
on the larger area. The rectangle is over 4x slower and the circle
is almost 6x slower.
When we increase the areas to 100 x 100 degrees the slowdown continues.
Both circle() and rectangle() are returning about 500 triangles (out
of 8,192, which is about 1/16th of the total).
100 level 5, 100-degree rects took 1.60 seconds
62 rectangles/second
100 level 5, 100-degree circles took 0.96 seconds
104 circles/second
The lead of the circle is now less than a factor of 2. But the big news
is the overall slowdown as the number of returned triangles increases.
The rectangle is now 25x slower and the circle() is 67x slower.
Size Triangles Rect-Time Circle-Time Circle-Time/Triangle
---- --------- --------- ----------- --------------------
1 3 0.61 ms 0.14 ms 46 us
10 70 2.3 ms 0.85 ms 12 us
100 510 16.0 ms 9.6 ms 18 us
To put this in perspective, Kstars is clipping/plotting 200k objects
per second, which is 5 us/object. So the time to make a small circle
intersection is roughly the same as plotting 30 objects. The time
for the large circle intersection is the same as plotting 2,000 objects.
Conclusions:
1) The circle is significantly faster than the rectangle.
The only reason to keep rectangles around is as an
aid to diagnostics.
2) There is a significant speed cost when large numbers of
triangles are returned. In the test cases the time increased
by a factor of almost 100. We know that we can get a lot of
this speed back by adding additional, courser meshes for larger
views. I don't know if the time savings is worth the extra
complexity and possibly size. Perhaps, it will suffice to
just use a courser primary mesh like a level 3 or level 4.
I think I will look at these next.
One more thing. I'm still running kstars-3.5.x and perhaps this has
already been changed in the 4.x branch, but I think it would be really
cool to have the option to have the magnitude limit actually scale with
the zoom factor. Right now in the 3.5 branch there is one "zoomed in"
limit and another "zoomed out" limit. Likewise the "show XXX for stars
brighter than YY" limit could be made to scale with the zoom factor.
That way when the user zooms in, fainter and fainter stars appear and
more and more labels appear so that the density of stars and labels on
the screen roughly stays constant. Then as the user continues to zoom
in, the on-screen density decreases because we've reached the limit of
our catalog. I think these should be options in addition to the current
ones which do have their uses.
--
Peace, James
------------------------------
Message: 2
Date: Sun, 28 May 2006 19:39:16 -0600
From: James Bowlin
Subject: [Kstars-devel] Interesting HTM timing results
To: KStars Development Mailing List
Message-ID: <200605281939.16369.bowlin at mindspring.com>
Content-Type: text/plain; charset="us-ascii"
These results are so interesting that I suspect I have made a mistake
somewhere in counting stars. I wanted to find the effect that changing
the mesh level had on the intersection speed. The courser meshes were
significantly faster as expected. I then counted the number of stars
returned by each intersection. The finer meshes should return fewer
stars for each intersection since they are a better approximation to
an actual circle and the algorithm needs to err on the safe side.
Then I tried to estimate the total time to draw the sky with this
simple formula:
total_time = intersect_time + time/star * stars_found
This is a gross approximation since the time it takes to clip a star
is going to be less than the time to check the clipping and then
draw the star. But if graphics hardware is decent, it could well be
that the time to draw is much smaller than the time it takes to
do the manipulations before the clipping check. In that case, this
is a very good approximation. I used two different estimates for
the time to clip/draw a star. Jason said Kstars could draw 200,000
objects per second which comes out to 5 us (micro-seconds) per star.
I used this value for one estimate, but then I estimated again assuming
1 us per star. This estimate would apply if we get a factor of 5 speed
up from removing the transcendentals from the transformations or if the
drawing took up 80% of the time in the current scheme.
The surprising result is that with either of those estimates, it is almost
always faster to have as fine a mesh as possible, even a level 6 mesh with
only 4 stars per triangle! Although I think for our problem, a level 4
or 5 mesh is optimal. Here is the data. Columns are described below.
size level trixels iter us/circ stars time(5) time(1)
1 3 1 10000 101 246 1331 347
1 4 1 10000 119 61 426 180
1 5 3 5773 145 46 376 191
1 6 7 3779 238 26 372 265
10 3 10 3162 180 2460 12484 2641
10 4 25 2000 380 1538 8070 1918
10 5 70 1195 1037 1076 6420 2114
10 6 92 1042 1822 353 3591 2176
100 3 131 873 1922 32238 163114 34161
100 4 264 615 4062 16242 85272 20304
100 5 520 438 10238 7998 50229 18236
100 6 620 401 16110 2384 28030 18494
size: the opening angle of the circle in degrees.
level: the mesh level.
trixels: the number of triangles returned by the intersect.
iter: the number of iterations used for timing. You can ignore it.
us/circ: the time to do one intersection in micro-seconds.
stars: the average number of stars in the returned trixels.
time(5): time to draw the sky assuming 5 us/star.
time(1): time to draw the sky assuming 1 us/star.
I find this result very interesting. Don't bet the ranch on it because
I could well have made a terrible mistake somewhere, but if it holds up
it implies that even though intersections on the finer meshes are more
expensive, it turns out to be time well spent since it is saving us time
in the long run by doing a better job of reducing the number of stars
that need to be clipped manually. It would also mean that my idea of
saving time by using a courser mesh for the wider views would have
actually slowed things down! Of course in the wider views, people
generally clip the dimmer stars in which case the benefit of the finer
mesh would be greatly reduced. AFAIK, the HTM's will at best give us
a factor of 2 speed improvement when it comes to drawing the entire sky
(I think we only draw 1/2 of the sky at a time). This makes me think
that we also might be able to use the HTM to clip stars that are under
the horizon when we are in the mode of just drawing that area as green.
The chart above was produced by 21 lines of Perl code. I'd be glad to
post it if anyone wants to check my work. Please consider these results
to be an alpha release.
For debugging purposes, I'd really like to try to implement the dcop
drawLine() feature. Actually, I'd like to implement drawLineRaDec()
so the lines would be somewhat fixed to the sky. Then we would
just need an eraseLines() for starting over. The lines could all
be stored on a stack somewhere. I would draw the triangles
so we can get an image of what is going on with these meshes and
intersections.
--
Peace, James
------------------------------
Message: 3
Date: Sun, 28 May 2006 19:31:00 -0700 (PDT)
From: brian hurren
Subject: [Kstars-devel] kstars as a desktop
To: kstars-devel at kde.org
Message-ID: <20060529023100.8429.qmail at web51308.mail.yahoo.com>
Content-Type: text/plain; charset="iso-8859-1"
Has anyone thought of turning Kstars into a desktop. the idea of having all my files projected onto the inside of a stary sphear is an intreguing one. I think that it would be highly efective as a thee d desktop and quite simple and elegent. Kstars is already a very good database for astronomy and it is a simple and elegant way of graphicaly representing data in this case astronomical data, if it was extended to be a desk top then it could also desplay other data... what do you think?
---------------------------------
Be a chatter box. Enjoy free PC-to-PC calls with Yahoo! Messenger with Voice.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kstars-devel/attachments/20060529/8303c120/attachment-0001.html
------------------------------
Message: 4
Date: Sun, 28 May 2006 19:44:24 -0700
From: Jason Harris
Subject: Re: [Kstars-devel] kstars as a desktop
To: KStars Development Mailing List
Message-ID: <200605281944.24723.kstars at 30doradus.org>
Content-Type: text/plain; charset="iso-8859-1"
Hi Brian,
Do you mean like this? http://www.30doradus.org/desktop_july04.png
That's KStars running as a dynamic wallpaper, which can already be done using
the "--dump" option on the command line, and adding kstars to the Advanced
wallpaper section of KConfig.
However, from your mail, I guess you want to do something more than just have
a non-interactive image as the wallpaper. You're thinking of being able to
"attach" icons on the desktop to the spherical projection of the sky, right?
It could be interesting, but it doesn't really have much to do with KStars.
With KDE-4.x, one could pretty easily write a desktop applet script that
attached icons to a spherical coordinate system.
It's possible that I don't yet understand what you're asking about, can you
elaborate a bit?
regards,
Jason
On Sunday 28 May 2006 19:31, brian hurren wrote:
> Has anyone thought of turning Kstars into a desktop. the idea of having all
> my files projected onto the inside of a stary sphear is an intreguing one.
> I think that it would be highly efective as a thee d desktop and quite
> simple and elegent. Kstars is already a very good database for astronomy
> and it is a simple and elegant way of graphicaly representing data in this
> case astronomical data, if it was extended to be a desk top then it could
> also desplay other data... what do you think?
>
>
>
> ---------------------------------
> Be a chatter box. Enjoy free PC-to-PC calls with Yahoo! Messenger with
> Voice.
--
KStars: http://edu.kde.org/kstars
Community Forums: http://kstars.30doradus.org
------------------------------
_______________________________________________
Kstars-devel mailing list
Kstars-devel at kde.org
https://mail.kde.org/mailman/listinfo/kstars-devel
End of Kstars-devel Digest, Vol 34, Issue 15
********************************************
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kstars-devel/attachments/20060601/226dc9b1/attachment-0001.html
More information about the Kstars-devel
mailing list