Write your own Einstein@home screensaver

OK. Update OR "Beware The Template Expansion From A Third Party Library". First the good news :

and so we have 2D text on the HUD with the rotating 3D stuff in the background! Looking more like the good old Starsphere every day. :-)

Nailed it. The problem was the compiler's deduction of the template type for glm::mat4. If you consistently put in a type T eg.

m_orthographic_projection = glm::mat4{{1/800.0f, 0.0f, 0.0f, 0.0f},
                                      {0.0f, 1/600.0f, 0.0f, 0.0f},
                                      {0.0f, 0.0f, 0.0f, 0.0f},
                                      {0.0f, 0.0f, 0.0f, 1.0f}};

which is this case is a float indicated by the 'f' on the literals, then all will be good custard. If you don't do that then it will dumb-down/demote everyone to the simplest type. So even one implicit or explicit integer type and everybody goes that way. So in particular 1/800 => 0 and 1/600 => 0 ..... and the transform goes belly up because all coordinates map to (0, 0) { rather singular eh ? }. In the setting of my utility library this gives the right matrix :

m_orthographic_projection = glm::ortho(GLfloat(0), GLfloat(TransformGlobals::getClientScreenWidth()),
                                       GLfloat(0), GLfloat(TransformGlobals::getClientScreenHeight()));

.... coming out at runtime as :

m_orthographic_projection = [[0.00195312, 0, 0, 0], [0, 0.00260417, 0, 0], [0, 0, -1, 0], [-1, -1, 0, 1]] ie. there were zeroes where the 0.00195312 ( 1/800 ) and 0.00260417 ( 1/600 ) are. Groan. Three weeks to sort that out .... :-))))

You can see that the assumed screen dimensions here are 800 x 600. Interestingly with the fixed function aspect of pipeline one can set the transform from Normalised Device Coordinates ( a cube of side length two centred on the origin ie. [-1, +1] for each dimension ) to the screenbuffer ( using "window" coordinates ) via, say :

glViewport(0, 0, m_CurrentWidth, m_CurrentHeight); so to do the HUD stuff you specify in screen coordinates within the client code ( remembering that the sense of the vertical scale has flipped sign c/w world space ) eg.

 m_logo_1 = new TextString(glm::vec2(0.0f, TransformGlobals::getClientScreenHeight()),
                           glm::vec2(0.0f, -50.0f),
                           glm::vec2(200.0f, 0.0f),
                           m_FontLogo1,
                           "Einstein At Home",
			   TextString::SOLID,
                           color1);

which the orthographic projection transform squashes down to NDC ( plus clip & toss any z coordinate ), which is then inflated back to window coordinates just prior to the rasteriser. Neat huh? The orthographic projection is done inside the vertex shader :

#version 150

// This is a vertex shader. Creates a parallel sided quadrilateral
// area based at lower left corner, with offsets along the sides.
// Both dimensions of texture coordinates are bound/clamped to
// zero and one at extents.

uniform vec3 base_position;
uniform vec3 height_offset;
uniform vec3 width_offset;
uniform mat4 HUDMatrix;

out vec2 pass_text_coords;

void main()
{
// Start at lower left corner.
vec2 position = base_position.xy;
// With texture coordinates of zero.
pass_text_coords.st = vec2(0.0, 0.0);

// For odd numbered vertices.
if((gl_VertexID % 2) == 1) {
// Add the width_offset.
position += width_offset.xy;
// With the 's' texture coordinate is 1.0.
pass_text_coords.s = 1.0;
}

// For the vertex numbered two & three.
if(gl_VertexID > 1) {
// Add the height offset.
position += height_offset.xy;
// With the 't' texture coordinate being 1.0.
pass_text_coords.t = 1.0;
}

// Emit final position of the vertex.
gl_Position = HUDMatrix * vec4(position, 0.0f, 1.0f);
}

.... now if anyone has been following me in the least ( just remember to fake it until you make it folks ) this shader is very suspiciously like the one for rendering 3D text. Yep. You would be right. All the constructs are the same*, you just decide by using a certain transform matrix as to whether you'd like to leave the textured parallelogram apparently out there in the 3D world or slap it onto the near face of the NDC cube. In fact that suggests a certain code factorisation .... eh ? :-)))

Cheers, Mike.

* Indeed an even broader generalisation beckons. We have been doing linear/affine ( straight lines and line segment ratios preserved ) but if you want to go for something curvilinear eg. WAVES, then just make the right 4x4 matrix to transform with. The vertex shader won't know any different. Merely change the client side load pointer for setting the uniform variable values .... oh what fun awaits. But don't screw up the transform sequence aka matrix multiplications do not commute.

I wonder what the label is all about in the given context... ;-)

I've found this great new book about programming :

.... it has a terrific section entitled "Dealing with Answers On Stack Overflow That Start With 'You wanted to know how to do X but you should do Y instead because I said so even though it's not actually the answer to your question"

Cheers, Mike.

Just to surprise you all, here is a screenshot of my latest effort, which I dub "Starsphere II" :

The prize here is the Earth within the celestial sphere of course. It's an interesting problem to 

- create a mesh model for a sphere, then

- overlay the texels onto the mesh, with

- a coordinate singularity ( same point for all longitudes ) at each pole, plus

- the wrap around/sewing in longitude at the horizontal edges of the original texture, and

- all this done in using a set of abstractions of the OpenGL rendering pipeline ( version 3.2 and above ) that I call my ogl_utility set.

See https://github.com/hewsmike/Einstein-At-Home-Screensaver/tree/solarsystem-sdl2 for details. But don't get too excited as I haven't managed the cross compilation to Windoze yet. I just love Linux .... 

Cheers, Mike.

Congrats Mike....Just you just have to wait for Ubuntu 20 next week..lol