Write your own Einstein@home screensaver

It is really great that the screensaver thread is still alive. It is sad that I have no time to move on here from another way that was suggested by Bikeman - to write a plug-in for Celestia. But I keep it in mind ;)

Ah. You can bind more than one buffer object at a time, you just can't have more than one vertex array specified to render with! :-)

Hence no problem : one buffer object has a vertex array ( interleaved ) as before and another buffer object containing the indices into that vertex array ....

Cheers, Mike.

Brilliant ! That'd really blitz. Thanks Oliver ... :-)
Just have to tease the code a bit, as not all OpenGL commands can go inside a display list alas :

[pre]void Constellations::render(void) {
/// Plot the stars first ie. a color at a point.
glEnableClientState(GL_VERTEX_ARRAY);
glEnableClientState(GL_COLOR_ARRAY);

/// The GL_ARRAY_BUFFER target will be serviced by one buffer.
glBindBuffer(GL_ARRAY_BUFFER, buff_obj_points.buffer_ID());

/// Using interleaved color/position data
glInterleavedArrays(GL_C3F_V3F, 0, BUFFER_OFFSET(0));

// Lines above can't go in a display list.
// Convert to a display list the commands from here ...
glPointSize(Constellations::MAG_SIZE);
/// This does the rendering using the entire buffer.
glDrawArrays(GL_POINTS, 0, tot_stars);
// ... down to here.

// These can't go in a display list, but none-the-less have to come after the star rendering
// and before the links rendering
/// Not using color values now.
glDisableClientState(GL_COLOR_ARRAY);
/// The GL_ELEMENT_ARRAY_BUFFER target will be serviced by the other buffer.
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, buff_obj_indices.buffer_ID());

/// OK, set up the vertex array within.
glVertexPointer(COORDS_PER_VERTEX,
GL_FLOAT,
BYTE_STRIDE_PER_VERTEX*sizeof(GL_FLOAT),
BUFFER_OFFSET(COLORS_PER_VERTEX*sizeof(GL_FLOAT)));

// Convert to another display list the commands from here ...
/// Characteristics of the lines representing the links.
glColor3f(LINK_RGB_RED, LINK_RGB_GREEN, LINK_RGB_BLUE);
glLineWidth(LINK_WIDTH);
glLineStipple(LINK_STIPPLE_FACTOR, LINK_STIPPLE_PATTERN);

/// This does the rendering but only using selected vertex position data.
glDrawElements(GL_LINES, tot_links*INDICES_PER_LINK, GL_UNSIGNED_INT, BUFFER_OFFSET(0));
// ... down to here.
// Lines below can't go in a display list.

/// Disable various capabilities from the OpenGL state machine.
glDisableClientState(GL_VERTEX_ARRAY);
glBindBuffer(GL_ARRAY_BUFFER, Buffer_OBJ::NULL_BUFFER_ID);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, Buffer_OBJ::NULL_BUFFER_ID);
}[/pre]
This works fine! So this is proof of concept. This can easily apply to a celestial sphere grid overlay ( declination and right ascension mesh plus an ecliptic great circle ) by simple extension.

Now I've got a routine that generates sphere vertices ( stacks and slices ) plus normals and texture co-ordinates : so you'd use the interleaving pattern 'GL_T2F_N3F_V3F' within a vertex array in buffer object likewise.

It would seem that to get textures across to server side ( maybe high-performance/hardware-accelerated/dedicated-cache if present ) one :

(a) creates texture objects ( specifying all sorts of characteristics including the pixel map itself - possibly mipmap'ed ),

(b) declare them GL_TEXTURE_RESIDENT ie. a current working set, and

(c) then 'bless them as important' via the glPrioritizeTextures() function to recommend that they stay there.

Of course a given implementation on the day may not give you that, but that's the best you can do to influence the 'least recently used' strategm commonly employed by implementations to manage their dedicated texture resources if/when space is at a pinch. I guess at worst it defaults to client-to-server frequent loads ..... so no harm in trying.

Cheers, Mike.

( edit ) As a rule of thumb : OpenGL calls that set/get state values, or rely on client state ( which may have changed since the list was complied ), or might affect server side memory management, aren't executable within a display list.

( edit ) Or put another way : if such commands are put b/w glNewList() and glEndList() they will execute immediately and not be retained.

( edit ) Or put yet another way : whatever commands you do commit to a display list ought operate to the intended/desired effect when replayed despite some change in the OpenGL context/state. Evidently that is a question specific to one's rendering purpose .....

OK, have moved on to rendering a sphere, or more exactly a polygonal approximation thereof the Earth. Specify the radius, the number of latitudinal slices, the number of longitudinal slices, and a texture to apply in decal fashion. This has gone generally well, all data ( vertices, indices and pixel map ) being placed server-side. Well, barring a few goofy off-by-one fencepost-type looping errors ..... here's a few of the code comments to illustrate issues :

[pre] // NB Potential for huge confusion is that there are two indices used with
// each call to glDrawElements() during rendering. One is that into the
// server-side buffer denoted by the target GL_ELEMENT_ARRAY_BUFFER,
// the other being that into the list of points upon the sphere denoted by
// the target GL_ARRAY_BUFFER. The key point of the method is to have a
// server-side buffer of indices into another server-side buffer of
// vertices. At render time OpenGL will look up what's bound to
// GL_ELEMENT_ARRAY_BUFFER in order to retrieve a value which is hence
// interpreted as an index used to look up within whatever is bound to
// GL_ARRAY_BUFFER. We have THREE index buffers which will be consecutively
// bound to GL_ELEMENT_ARRAY_BUFFER at render time, one for each polar region
// and one for everything in between.[/pre]
[pre] // What size byte allocation are we after for this array of indices? For
// each point we have sizeof(GLuint) worth. What is the point count ?
// - one for the North pole (+1) , plus
// - one for each longitudinal slice (+EARTH_GRID_SLICES), but
// - the first slice is counted twice (+1) so as to connect up
// the triangles right around.[/pre]
[pre] // The indices of points on sphere at a latitude just one stack below
// the north pole, listed in sequence suitable for later use within
// GL_TRIANGLE_FAN pattern. The way this 'winds around' makes the convex side
// the 'outside' for OpenGL purposes. As it should be. NB OpenGL considers
// the 'front face' of a polygon to be what I have called 'outside', the
// sense of the winding is right handed : list in order a single
// polygon's vertices and they will form a right-handed system with the
// normal pointing out of the 'front face' of the polygon. Curved fingers
// of one's right hand follow the vertex order, the thumb points along the
// normal vector to the mutual plane defined by said vertices. Or if you
// look down the normal vector from it's tip to the tail embedded upon the
// plane, the vertices are listed in counter-clockwise order.[/pre]
[pre] // The indices of points on sphere at a latitude just one stack above
// the south pole, listed in sequence suitable for later use within
// GL_TRIANGLE_FAN pattern. The way this 'winds around' makes the convex side
// the 'outside' for OpenGL purposes, and is necessarily of the opposite
// sense to the northern cap.[/pre]
Recalling that this route is being taken as while gluSphere ( a 'quadric' ) is way simpler to code - because someone else has done it for us already within the API call - it inevitably involves much client-to-server transfer with each frame rendered. When I have suitably polished the code I will publish it on GitHub.

My reading seems to indicate that glPrioritizeTextures() isn't of large importance with a small number of textures - I'll probably wind up using four at most I think. NB that it's only the number of textures per OpenGL state machine instance ( 'context' ) that one can affect programmatically. Whatever else the video card is up to cannot be interrogated at API level .... you just don't know what else might be running. In any case my thinking is that I might take up about 20MB of server-side space ( most of which will be texture pixel maps, including mip-mapping ) by using the buffer-object paradigm, and in doing so free up CPU cycles. 20MB is likely not going to make the difference in room for even CUDA units, though of course executing the code consumes GPU cycles, while buffer objects keep down the bandwidth use to the card.

Cheers, Mike.

( edit ) The especial reason for fiddling with winding senses and faces is to instruct OpenGL to apply the texture to only one side - we don't need an expensive pasting of a pattern to the inside of the Earth, do we ?? :-)