Write your own Einstein@home screensaver

OK : after a ton of testing, trial and error, getting absolutely every rake hidden in the uncut lawn grass to hit my face, but including acquiring some really cool GL and GLSL tools, also while paying my son in apple cider to debug & flog it, I have written a pretty neat ( says he ... ) user friendly abstraction layer above all the shader crap. Here is 'first light' on that as an integrated executable :

.... woo woo woo & what a lovely triangle we have ! By the by I have also ditched the ES for good. It is just too cut-down for my liking. Specifically ES 2.0 doesn't have Vertex Array Objects ( VAO's ) and so having to continually reconstruct the graphics pipeline's input end ( how you shovel the data in ) for each and every frame is way too clumsy. The above is an Open GL 3.2 CORE effort using GLSL 1.5, on the existing base of GLEW, BOINC Graphics API subset, SDL & SDL_TTF, Freetype 2 and LibXML.

There is a spider's web of sequence dependencies in the 'modern' GL state machine. It will blow up quick slick if the wrong functions are called when the current state is just not quite right. This is especially relevant to the state of the rendering pipeline in detail. You know, the bit that prior GL versions gave you blissful ignorance of. I have hopefully successfully buried that ordering inside the C++ classes. That's what they are for ! :-)

One annoying error to debug has finally today been marked with the enumerant MIKE_IS_A_DUFUS, that being : expecting a pointer to a local/stack array to persist on function exit. You still have the pointer of course, it's an address, it doesn't seg-fault at all, but the data becomes crud. Right. Good one Mike. That's straight from Code Boners 101*. You just don't get that time back do you ? :-)

Cheers, Mike.

* Having said that I believe such venom bites do have an immunising effect though, by virtue of persistent memory of the pain from realising that the effort/time wasted was all your own work. :-)

Mike, what if Pink Floyd complains about you borrowing
their album cover design from "The Dark Side of the Moon ? "
JKJK )

Bill

Howdy Mike !
That is a Great Workstation you have assembled !

Bill

Now here's nice surprise ie. GLM has provided the matrix transforms which mimic those previously provided by GLU :

... the return values of these functions which would hence be available to provide as program uniform variables and so into the shader code.

Cheers, Mike.

GLM doesn't have that. But I have a Sphere class which generates a vertex listing that yields a geodesic type frame composed of triangles.

I have considered generalising ( because I can !? ) to cylinder and disc, though a disc is really a very short cylinder. A torus/donut would be useful too.

Algorithmically they are much the same, having :

- circularity ie. the end meets the start, along at least one coordinate progression.

- need for normals to light.

- color at the vertex ( perhaps implying extension to the triangle faces )

- need for texture co-ordinates for pasting images on.

.... however they differ with respect to the particular generator of the vertex co-ordinates.

A general quadric then has/needs parameters for :

- overall dimensions eg. a sphere's radius

- granularity of modelling eg. how many slices/partitions along the relevant axes

- what totality of information is desired per vertex eg. position, normals, color, texture co-ords.

- possibly some prescription of base representation eg. float, double etc.

One important issue I have discovered : if you scale the object then DON'T scale the normals ! Keep them unitary.

The 'output' of a quadric format would be a 1D array of records, possibly with another array of indices into that one. Each record is the same structure of vertex attributes. This could be wrapped up into high level calls that invoke generation and rendering. Naturally one would have a 'Quadric' base class, virtual for that matter, plonking the shape specifics into subclasses to solidify the virtual stuff. I guess that is the idea ....

Consider it on my to-do-list ! :-)

Cheers, Mike.

( edit ) As discussed elsewhere, you have to use triangles in the modelling. Quadrilaterals are out in later OpenGL ...

( edit ) Mind you, one can 'fake it' eg. have coplanar triangles ( or possibly a sequence of lines ) but the API doesn't natively support quads. However the fixed parts of the rendering engine may catch you out by producing artifacts if you don't get it truly right though. This then gets down to low level stuff like number representation formats ie. when are two floating points equal, and when do you have the right to expect equivalent mathematical expressions ( notably commuting transforms ) to yield that ?

I'm sure you're familiar with all of that. FWIW GLSL has an 'invariant' qualifier that may be used to ( allegedly ) force equivalence of computation outcomes across programs ( on a given machine ). There's a time cost in that because it requires some degree of introspection and adjustment at runtime. Very clever feature, but IIRC it's a bit like 'inline' ie. at most a hint and might indeed be ignored by the implementation. For graphics production this is probably neither here nor there. I think it was included for regularity of compute shader outcomes, when doing 'multi-pass' techniques especially.

( edit ) One may wonder why I use a 32GB RAM machine. Firstly because I can [ :-) ], but it turns out that 'unrolling' much of the C++ standard library template classes can massively blow out the compiler's memory needs, at least for short periods on g++.