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

"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

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.

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.

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

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:

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.