Write your own Einstein@home screensaver

OK, better late than never. I wish to call this the first 'official' release in that :

- I have bug and error tested until my exhaustion. :-)

- It has most features that I originally aimed to produce.

Linux Version

Windows Version

This is built from commit 87be229d42525b3be44992a3d4283c3887e28721 and tagged as 'V1.00'.

This is not to say that I don't have other things in mind to add later, and I'm sure some will find an issue or three that needs attention. Please do test and advise! :-) :-)

For instance I've just now remembered that I haven't included on the help HUD ( press F1 to toggle ) that you can use the mouse wheel to zoom the viewpoint in and out. Sigh .... well that's the first on the list for V1.1 :-)

Before I also forget : pressing "Enter" to toggle b/w fullscreen and window modes is no longer available. It was just too problematic for now ( don't ask ) to get this to work in Windows alas.

Plus when I work out which xml file to use and how to alter it to get it to run actually as a BOINC screensaver - I'll let you know.

Cheers, Mike.

Thank you Oliver ! We'll see how well it tolerates usage. :-)

{ASIDE} Also the multi-platform build framework as it now stands can be used for other things, and so I have plans there too. Maybe model a binary pulsar system where you get to scoot around such an animation/simulation, look at it in action from different viewpoints plus vary the relevant astrophysical system parameters on the fly, screen shots, SVG output etc .... the sky is the limit!! :-)

Cheers, Mike.

( edit ) Mind you the build framework itself needs further work too : extending to post v3.2 OpenGL contexts, graceful degradation of functionality for poorer performing video drivers, more aggressive management of MS Windows situations to name but a few directions. Fun! :-)

( edit ) That's just reminded me to check/review whether the Starsphere builds will still be OK with all these recent changes.

ARN : ErrorHandler::check_OpenGL_Error() - Reported OpenGL error with code : 1280 - no error : An unacceptable value is specified for an enumerated argument
INFO : WindowManager::tryMode() : attempt width = 800 and height = 600 using mode WINDOW

INFO : WindowManager::tryMode() : attempt width = 800 and height = 600 using mode WINDOW
WindowManager::tryMode() : glfwOpenWindow() first attempt returned false

INFO : WindowManager::tryMode() : attempt width = 800 and height = 600 using mode WINDOW
WindowManager::tryMode() : glfwOpenWindow() first attempt returned false
WindowManager::tryMode() : glfwOpenWindow() second attempt returned false

WARN : WindowManager::setWindowedMode() : Could not acquire rendering surface
WARN : ErrorHandler::check_OpenGL_Error() -

Looks nice Mike, Win7 did tell me I better not trust "SolarSystemWin32 zip is not commonly downloaded and could be dangerous" after the d/l but I told Windows you can be trusted here so it allowed me to take a look

Yes, that's what gave me the idea. Hmmm .... maybe I'll do something different then. Something orthogonal. :-)

[thinking out loud]
I've been thinking about what a gravitational wave "looks like", or how to at least render the gist of one visually. Of course it's really a spacetime thingy, and we're inside that.

Take a sphere represented as a polygonal mesh ( later to be textured and called Earth : already done that code ), define a line going through it's centre and extend that 'infinitely' either way. Call it the 'wave axis' and denote one direction along that line as 'incoming', or if you like singly parameterise the positions along the line. Thus you get a sense along the line according to the increase in the parameter ( call that the wave phase ). Also define another vector for the wave polarisation direction, that'll be perpendicular to said axis as GW's are transverse. Per animation frame :

- per mesh point, find the nearest point on the wave axis. This gives several useful things. First is the distance to that axis. Next is a direction from the axis to the mesh point, hence a vector in the plane transverse to the wave axis based at that nearest point. Lastly you can get the wave phase for that nearest point on the wave axis. Now given some model for displacement of points in the transverse plane ( it's a gravitational wave so traceless ie. contraction in one direction means expansion in the orthogonal ) then you can deduce an adjustment to the position of this mesh point! The displacement/strain will be phase dependent. Now texture the planet with the warped mesh ....

Next frame - repeat as above but subtract a small fixed amount ( same for all mesh points ) from the discovered phase values at each mesh point, so the distortion propagates as if from the incoming direction.

I think much can be pre-calculated. Indeed this begs for the use of a vertex shader! :-) :-)

Make the phase cycle/modulo and so repeating the effect. The Earth with ripples .... stick that behaviour in the GW variant of the SolarSystem screensaver. Per the current sky search position for the currently calculating WU. Giving a 'this is what it would like like if this work unit found a GW' ...

[/thinking out loud]

Cheers, Mike.

( edit ) Of course there are two polarisations, one rotated 45 degrees from the other. Minor detail for now. Succeed with one and then add in the other.

( edit ) And ramp up the strain magnitude by a few orders ....

Code Review Time

Oh Dear, I laugh! But I cry too .... :-) :-)

After two years I discover this statement in the OpenGL Wiki yesterday :

I'd worked out this behaviour by trial and error anyway - constructing a workaround in the meantime. No sensible logic supports this scenario. I can think of only one Direct reason for this situation ( which is probably just sufficient to avoid an anti-competitive claim ).

That, and the fact that : on Windows the entire OpenGL context gets thrown away and needs reconstitution simply upon a window resize ....

And that : on Windows all functionality post OpenGL version 1.1 ( 1997 ) must be dynamically linked ....

[ Still, on the upside, in resolving this and other issues I've discovered a huge open source community out there ... ]

Cheers, Mike.

( edit ) NB. A warning on using shaders ( which introduce user programmable behaviours into the previously fixed function OpenGL rendering pipeline, a required feature on 3.1+ contexts ) : one has to manage all relevant vertex attribute handling in the vertex shader. So you can't just program the bits you want and take some default behaviour for others. It doesn't work that way. If you want texture coordinates per vertex to be passed into and then out of the shader - for use further down the line - then you have to actually ensure that with the shader code you write. If you want secondary colors per vertex to be accounted for then ditto. Etc.

In effect this makes every vertex shader dependent upon the choice of attributes allotted to each vertex within some vertex set ( that said shader will act upon ). Specifically this implies that there is no universal 'pass-through' shader that merely hands on arbitrary vertex data. The minimal data allocation per vertex is it's position only, a four vector, the rest is optional.