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