Hi everyone. I am new to the MilkyWay@home project and will be working with the RPI group this summer. I am currently busy with the visualization of the data. Below is a screenshot of one of the wedges being worked on as it appears in the screensaver (no alterations). I am currently optimizing the screensaver draw-routines to get a decent frame-rate while displaying realistic blur circles for the stars. Suggestions are welcome.

The screensaver is almost fully optimized. For 8x8px-accurate blur circles I get 26 FPS rendering 100,000 stars on my Dell Inspiron 1501, AMD 64 Athlon X2, using a mainboard video card w/shared memory. For those of you that don't know, this laptop is not made for graphics. I am currently optimizing the floating-point routines to use fixed point math and trig-function look-up tables. From a few tests, it looks like it might double that frame-rate (fingers-crossed). Beyond that, optimization would require assembly-code which I am avoiding, because this application currently compiles on any platform and I hope to keep it simple, but fast.

I kicked a number around with the team. For now, we are planning to cap the screensaver CPU-time at around 10 or 15%. Luckily, the screensaver does not have to show all 100,000 stars at once, so by limiting the view distance for the majority of the time, the screensaver should be able to maintain its frame-rate. For those that need more speed, I am building in options to manipulate the blur-circle radius, average luminosity and cut-off distance, screen resolution, and a single-pixel rendering mode. It doesn't get any faster than single-pixel rendering, but some people prefer effects over speed.

Here are some screenshots of a frame from a simple test demo. I welcome any comments on the different modes. Transparent draws flatten the image, much like pixel-rendering, so the default setting is pixel-summed blur circles:


Pixel-summed blur circles 8x8px ( 26 fps ):

http://www.rpi.edu/~reills2/milkyway/100000%203.5%20.05.png

Sharp pixel-summed blur circles 4x4px ( 38 fps ):

http://www.rpi.edu/~reills2/milkyway/100000%201.5%20.15.png

Transparent-blit stars 8x8px (faster when graphics-card accelerated, otherwise slower than pixel-summing):

http://www.rpi.edu/~reills2/milkyway/100000%203.5%20.15%20-%20transparency.png

Single pixel-rendering ( 70 fps ):

http://www.rpi.edu/~reills2/milkyway/100000%20-%20single%20pixel.png

The pixel-summed blur circles definitely look best, but I'd actually say the single pixel rendering looks better than the transparent blitting. Either way it looks very nice :) If the whole thing moves slowly, perhaps you could limit it to 1fps or so to get a constant framerate and limit CPU usage as much as possible? Probably best to make it a serverside preference.

I have to agree keep cp to a minimum and I like 2 and 4 myself

Nice to finely hear that the screensaver is being worked on. I like the first option best but since there will be some preferences to choose from, it sounds nice.

Hopefully this will draw even more people to the project as well.

"If the whole thing moves slowly, perhaps you could limit it to 1fps or so to get a constant framerate and limit CPU usage as much as possible? Probably best to make it a serverside preference."
-Emanuel

The frame-rate may not be constant at all times, but the motion will be on a timer so the worst that will happen is that things looks a little choppy at times. Chop is also a result of faster motion, so as you pointed out slower movement will look fine at possibly even 8 fps. 1fps would not leave much room for visual effect, but it can be selected implicitly by choosing 1% CPU usage. To keep things simple for most users, I think it would be best to make a frame-rate cap adjustable in an ini-file.

The maximum server-side CPU usage could be something like 15% with the default at maybe 5 or 10%. Faster computers will not need the entire amount since the frame-rate will be capped at 15 or 30 fps by default. Television screens display about 24fps.

I liked this one most Sharp pixel-summed blur circles 4x4px ( 38 fps ).

---

I should probably mention they look different if they are zoomed in. Some browsers blend the pixels while shrinking the image. I will have more wedge images soon. I am working on visualization of an N-body simulation in addition to this.

Single Pixel Rendering looks purty :)

Edited to add : what's the performance loss from A-Z?

Fair dinkum, it looks like an ultrasound.

Here is another screenshot. It is a far view of wedges 16 and 82 with a bright spot representing the galactic center. The sun is located were the wedges meet. Click here for the full version of the wedge image.



Edit: this image was based on the mistaken assumption that wedge data was stored in ra/dec and magnitude. It was later confirmed that it is actually stored in l, b and distance coordinates. The result is that the wedges appear logarithmically elongated at unexpected angles. The issue is resolved now.

We want people to be able to give as much CPU time as they want to the project, so I think it is important that users can easily define the percentage of CPU that they want to devote to the screensaver. There will be the option of using the default BOINC screensaver for those that want 100% of their CPU time to go to the project, but does anyone have any recommendations on where the options should be? An ini file would be the simplest method, but a more user-friendly interface might be preferable.

There is an option in Milkyway preferences that you may just need to turn on called "Maximum CPU % for graphics".

That is convenient, thank you for the tip.

There are a few options for navigation. The proposal made was to start zoomed far out on the wedge being worked on and then navigate to the stream-estimations and current zones being integrated. I have tried many possible intermediate simulation effects.

It is possible to take a tour just over the surface of the wedge while navigating. It creates an effect similar to a flight simulator without offering the security of a safe landing place.

It is also possible to add a toggle for the interactive mode that is used to test it (by pressing F12 perhaps) if people are interested.

The stars being worked on can be made to flicker and the stars completed can be dimmed.

Other ideas are welcome as well as suggestions on these.

Looking back on the galactic halo from inside wedge 82 (full version here):

"Single Pixel Rendering looks purty :)

Edited to add : what's the performance loss from A-Z?"

-Aaron Finney

The application is far enough along now to give an answer to this. I do not expect things to get much faster. Now that everything is in look-up tables, rendering only takes a handful of multiplications and divisions per star even at 16x16 px. The rest is memory copying and operations with very little cost. These values are based on 100% CPU usage, so multiply the frame-rate by the desired CPU percent to get the expected frame-rate.

 . 1x1 pixel stars . overwrite . . . 81. fps . 100%
 . 1x1 pixel stars . pixel summing . 80. fps .. 99%
 . 4x4 pixel stars . pixel summing . 54. fps .. 67%
 . 8x8 pixel stars . pixel summing . 40. fps .. 50%
 16x16 pixel stars . pixel summing . 21. fps .. 26%

The problem with 1x1 stars is that they do not allow boundary blending, so even if the images look good in a still-frame, they look noticeably choppy when moving slowly across pixel boundaries no matter what the frame-rate is.

Transparency takes time similar to pixel summing on my machine. It might be significantly faster on machines with hardware-accelerated blitting.

Unfortunately, I think it would require a programmable graphics card to provide on-board accelerated support for pixel-summing. If you have one of these, then odds are it is already being used to integrate for the Milky Way Project so providing such support might be counter-productive.

The human eye can see at about 60-70 fps so we have the following options in the interest of speed:

a) render at various angles without motion during transitions (stationary rendering takes close to 0% of the CPU)
b) only move every 30 seconds or so and use ~25% of the CPU only during these brief transitions, 0% the rest of the time (stationary)
c) move very slowly
d) darken most of the stars, showing only the nearest ones while moving, all stars while relatively stationary over the wedge
e) remove most of the stars, showing perhaps 10,000 instead of 100,000
f) learn to appreciate chop

Here are the comparisons of the 5 test runs:

1x1 pixel (overwrite):
http://www.rpi.edu/~reills2/milkyway/1x1_pixel_destructive.png

1x1 pixel (pixel summing):
http://www.rpi.edu/~reills2/milkyway/1x1_pixel.png

4x4 pixel (pixel summing):
http://www.rpi.edu/~reills2/milkyway/4x4_pixel.png

8x8 pixel (pixel summing):
http://www.rpi.edu/~reills2/milkyway/8x8_pixel.png

16x16 pixel (pixel summing):
http://www.rpi.edu/~reills2/milkyway/16x16_pixel.png

I realized I did not mention the 3d to 2d conversion overhead. Since look-up tables are used, the overhead is there, but it is manageably small. The difficult part is quickly representing the sheer magnitude of the data (100,000 stars), which is handled by the custom 7-bit graphics engine (the 8th bit is used to perform 4 pixel sums simultaneously instead of 1 at a time).

The programming overhead for 3d rendering is about 20 lines of code in 1,119 total lines. 60% of the code is the blitting engine and graphics library, another 30% is code for graphics display look-up tables. The graphics library will not interact with work being done by the GPU's because it is designed to rely 100% on the CPU. This fact along with the need for a fast rendering method meant writing a display engine from scratch, something I luckily have a lot of experience with! The Simple DirectMedia Layer (SDL) library takes care of setting up the display mode and checking for keystrokes, etc.

If we do a a photo-shoot of different views over/in the wedge in 3D, changing images every 10 seconds with fade-in, the CPU overhead would be about 0.5%. Effects like star flicker for sections being worked on might add another 0.5%. For another 0.1% I can add a backdrop of the Milky Way Galaxy in the form of about 300 diffuse spherical halos, but I wonder if it would be distracting. These seem more like the numbers people had in mind so I thought I would throw the idea out there.

The frames-per-second overhead is as follow:

. . . . . . . . . . . . . . . . . . 3D . . . .. 2D

. 1x1 pixel stars . pixel summing . 80. fps . . 115. fps
. 4x4 pixel stars . pixel summing . 54. fps . .  67. fps
. 8x8 pixel stars . pixel summing . 40. fps . .  42. fps
16x16 pixel stars . pixel summing . 21. fps . .  21. fps

This is all sounding great! I don't like the blurry images though. The sharper the image, the better.

When TV was created, they determined that people only managed 24 frames per second, and that was bumped-up to 30fps. Old TV signals overlap 2 frames at 60 fps.

LCD monitors are based on liquid, so you can't really get much more than 30fps either.

In summary, you don't really need to worry about getting much beyond 30fps, but if you have already done so, that's great. That was also smart thinking to use trig lookup tables to cut calculation costs.

you mentioned you were looking for ideas.
Do you have code to review available somewhere?

I like the idea of toggling/blinking the area being looked at at the moment. It gives an interactive idea of what is getting done at that moment.

---

http://www.joescat.com/boinc/

I will be loading the code to a repository soon. We are migrating all our code to github.com even as I write this. The graphics library used to render the stars is multipurpose, so it will be listed separately on github under the GPL in case anyone wants to use it for their own projects and research.

The consensus so far seems to be credits over effects which I can understand since most of the time the screensaver will not be viewed. At the moment our plan is to alternate between 3 angles with a fade-in transition. This will easily use less than 1% of the CPU. Here are the proposed angles (10 seconds each):

1) over-head view - this is where progress will be shown and current area being integrated will be made to flicker




2) earth view (pans across entire wedge slowly)




3) far-off random view showing scale compared to the galaxy - this is where I would put the galaxy backdrop

If anyone would like to suggest additions or modifications to this list or other details of the screensaver (now or after the first release becomes available) feedback is always welcome.

Pictures are interesting, but for a user like myself, don't really understand what the wedges are. I'm guessing #1 is a wedge of space as seen from earth, thin at the centre and wide (rectangle) on the rim, and not like a cheese wedge, where it's just as thick at the centre as it is on the rim. Meanwhile, #2 is the wedge rectangle view as seen as from earth, and not like the cheese wedge seeing the rectangle from centre of circle to edge of circle.

Picture 2 might be interesting to see the initial picture, and the picture as it progresses, for example rectangles (original "above", progressing "below").

Have you looked at Einstein @ home? it has an interesting idea of showing where it's doing calculations in the sky, but it is only one view, while yours sounds very ambitious with 3 views in it.

---

http://www.joescat.com/boinc/