Write your own Einstein@home screensaver

Oliver Behnke
Oliver Behnke
Moderator
Administrator
Joined: 4 Sep 07
Posts: 889
Credit: 25,165,240
RAC: 0

RE: RE: Hm, a Donnie

Message 78068 in response to message 78067

Quote:

Quote:
Hm, a Donnie Darko lover or just a Blender fan?

As I had to look both of those up, let's put that down to Morphic Resonance .... :-)

I was just wondering about "Frankie-Bunny" :-)

Oliver

 

Einstein@Home Project

Mike Hewson
Mike Hewson
Moderator
Joined: 1 Dec 05
Posts: 6,205
Credit: 134,979,904
RAC: 25,174

RE: I was just wondering

Message 78069 in response to message 78068

Quote:
I was just wondering about "Frankie-Bunny" :-)


It's Frankenstein because the box is made up with a bunch of left-overs from quite a few other systems that died, with Ubuntu plonked on it. [ Get Igor to raise the lightning rod .... ] Wow! I see. What a hoot! :-) :-)

Clearly I'm gonna have to go and watch the movie now, so I may yet wind up being a fan .... :-)

Cheers, Mike.

I have made this letter longer than usual because I lack the time to make it shorter. Blaise Pascal

Mike Hewson
Mike Hewson
Moderator
Joined: 1 Dec 05
Posts: 6,205
Credit: 134,979,904
RAC: 25,174

More thoughts for the record

More thoughts for the record .... :-)

After some deeper research I don't think I need to worry alot about most OpenGL version 2.x facilities not being enacted in hardware. It seems that it's been quite a while ( rather older Windows systems, mesa3D ) that such stuff has had software emulation rather than hardware acceleration. So pretty much any video card made/bought in the last five years ( probably ten ) has good solid capability, suitably driver'ed up. So, say, it's unlikely to have depth buffering, blending, double buffering, texturing or shading not done in hardware. I gather the chips have a huge garden full of circuits for the 4 by 4 projective/affine geometry transforms too. But I'll still cater for the lower end anyway, and have quality/features etc default to that. Call it the LOW quality option on the LOW/MEDIUM/HIGH axis ( the user and/or BOINC will be responded to for selection of that ). My 'first official' version will be a LOW quality only effort just to get some runs on the board ..... a demonstrator for the purposes of consideration/discussion/proof-of-principle/critique/lambast/character-assassination/legal-action ..... so that will definitely be a 'stick figure & crayons' version as opposed to Toy Story 3 standard. :-) :-)

[ The OpenGL 3.x standard is a different beast with an amusing tale (?) as regards 'deprecation' ( so to speak - tongue in cheek ) that needn't worry us for oh .... another five or ten years maybe! ;-) ]

For the present I'll consider enacting something like a 'video_options.xml' file that could be loaded up, if present, to advise the executable as to the last settings used and indicate previously selected 'good settings'. Thus if a user changes settings via the keyboard ( when in windowed mode, not full-screen screen-saver ), these will be remembered for later on. As the OpenGL API per se can't inform too much in a platform independent way that the appearance/performance can be deduced, then a user could twiddle to suit and my app will remember that. However I haven't as yet seen any write capacity for xml in the currently exposed interface as per Libxml2Adapter/XMLProcessorInterface so it looks like I'll need to roll my own. :-)

Would a look at 'libxml/parser.h' help at all? It looks like a deep rabbit hole, and at a glance SAX doesn't appear all that self-evident and might well be way more than I need. Maybe it'll be simpler to make ( in effect ) an in-memory image of the xml file of interest, twiddle the entries and (re-) write to disk. After all, it'll be my own tags/format so just treat it as a text file, while of course remaining 'well-formed' for xml purposes and thus later reading through the provided interfaces. If it looks like too much work for too little benefit I'll just write some custom format flat file, and ignore xml altogether.

For performance there are several handles to pull :

- scene complexity ie. how many objects or object classes get to be shown at all?

- object complexity ie. to what degree do you model ( parts of ) the planet Earth say?

- global rendering method ie. what OpenGL API features do I use like display lists, vertex arrays etc

- global rendering complexity ie. light model, shading, texture granularity, blending and so on ....

I'm currently writing code ( a 'Settings' class with limited write access but global read visibility for all ) to formalise these choices. So some generic 'render_blob_x' function will refer to it, in order to internally select a code path that reflects the desired mode of presentation. On the fly in fact with lazy evaluation. Have to remember to clean up the OpenGL state ( release resources when no longer needed ) if I change some aspects so as to not to be wasteful during actual execution - being polite to other concurrent graphics apps, including our very own E@H WU's potentially! :-)

Now as regards other keyboard keys, this is no problem as I've discovered the full SDL enumerant set, so the world is my oyster there .... :-)

Now I've 'mislaid' my hardcopy of the SuperBible. It's too big for my dogs to have eaten, even with their chewing tendencies. But as I have a Safari Bookshelf subscription that's sorted too.

Rendering the Sun ought be manageable by a sun-spot riddled texture, some shading techniques I'm researching, careful use of specular reflections ( like a shiny billiard ball ), and choice of emissive material properties in addition to ambient light. My original worry was how to get depth cues on the Sun's face without using a light source that 'casts a shadow' so to speak. There's no 'dark side of the Sun' you see .... :-)

Would anyone care to glance at my repo with a view to feedback on coding standards of the files published so far, so that ( white-space-wars aside ) I may know whether my code is readable in a self-documenting sense? Please, pretty please :-) :-)

Anyway I'm having a ball .... but, gosh it's alot to encompass.

Cheers, Mike.

( edit ) On the build system side ( for my own home use ) I'm going for a master-client-side version of the source code ( this most immediately correlates to the gitHub repo ), which will be replicated to several different framework near-clones/directory-trees each of which then deals with a single platform type ( Windoze, Linux and the two Mac's ). This enables me to more clearly separate makefile and dependency issues ( in my own mind anyway ), but more importantly saves a total rebuild/recompile of the base components ( SDL/libxml2/OGLFT/BOINC/FreeType2 ) that presently occurs when I swap targets.

I'm occasionally thinking about designs of a superior system ( taking note of prior comments about auto-hell and what not ) but this approach will do for now. I think you mentioned earlier Oliver, some newer/saner alternative to autohell?

I have made this letter longer than usual because I lack the time to make it shorter. Blaise Pascal

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4,023
Credit: 214,151,666
RAC: 42,451

RE: I think you mentioned

Message 78071 in response to message 78070

Quote:
I think you mentioned earlier Oliver, some newer/saner alternative to autohell?

The most widely accepted alternative to autohell is cmake; I think that's what Oliver was mentioning, too.

BM

BM

Mike Hewson
Mike Hewson
Moderator
Joined: 1 Dec 05
Posts: 6,205
Credit: 134,979,904
RAC: 25,174

RE: RE: I think you

Message 78072 in response to message 78071

Quote:
Quote:
I think you mentioned earlier Oliver, some newer/saner alternative to autohell?

The most widely accepted alternative to autohell is cmake; I think that's what Oliver was mentioning, too.


Thanks Bernd, I think that is indeed the one I was trying to remember, I'll study up on that. I think he might have mentioned Qt as well - but in the sense of being over-kill for present purposes.

Cheers, Mike.

I have made this letter longer than usual because I lack the time to make it shorter. Blaise Pascal

Bernd Machenschalk
Bernd Machenschalk
Moderator
Administrator
Joined: 15 Oct 04
Posts: 4,023
Credit: 214,151,666
RAC: 42,451

RE: Would anyone care to

Message 78073 in response to message 78070

Quote:
Would anyone care to glance at my repo with a view to feedback on coding standards of the files published so far, so that ( white-space-wars aside ) I may know whether my code is readable in a self-documenting sense? Please, pretty please

I'd love to, but I've got my plate more than full this month...

BM

BM

Mike Hewson
Mike Hewson
Moderator
Joined: 1 Dec 05
Posts: 6,205
Credit: 134,979,904
RAC: 25,174

RE: RE: Would anyone care

Message 78074 in response to message 78073

Quote:
Quote:
Would anyone care to glance at my repo with a view to feedback on coding standards of the files published so far, so that ( white-space-wars aside ) I may know whether my code is readable in a self-documenting sense? Please, pretty please

I'd love to, but I've got my plate more than full this month...


Absolutely, your plate runneth over in fact! :-()

Might invest in a code formatter. I've always wanted one of those anyway. With templates 'n stuff.

Cheers, Mike.

I have made this letter longer than usual because I lack the time to make it shorter. Blaise Pascal

Oliver Behnke
Oliver Behnke
Moderator
Administrator
Joined: 4 Sep 07
Posts: 889
Credit: 25,165,240
RAC: 0

RE: Might invest in a code

Message 78075 in response to message 78074

Quote:

Might invest in a code formatter. I've always wanted one of those anyway. With templates 'n stuff.

Invest? Just try Eclipse for the time being. It comes with a number of templates and allows you to modify them as you please - or simply create your own from scratch... Eventually we might even agree on a single one to use :-)

JM2C,
Oliver

PS: I'll have a look at your previous (long) post, say, next week'ish...

 

Einstein@Home Project

Mike Hewson
Mike Hewson
Moderator
Joined: 1 Dec 05
Posts: 6,205
Credit: 134,979,904
RAC: 25,174

RE: Invest? Just try

Message 78076 in response to message 78075

Quote:
Invest? Just try Eclipse for the time being. It comes with a number of templates and allows you to modify them as you please - or simply create your own from scratch... Eventually we might even agree on a single one to use :-)


Doh! I've used Eclipse plenty of times, and even have Galileo as we speak. I'd never really noted that. LOL. I love the bleedin' obvious, talk about RTFM!! Thanks! :-)

Quote:
PS: I'll have a look at your previous (long) post, say, next week'ish...


Please don't feel burdened by any need to reply, I know you guys are really, really busy. I'm largely sort of blogging here, for the record so to speak, on the assumption someone else may want to do this too. And I have this habit of just writing what I think .... in detail and length alas .... which is the joke within my signature. :-) :-)

Cheers, Mike.

I have made this letter longer than usual because I lack the time to make it shorter. Blaise Pascal

Mike Hewson
Mike Hewson
Moderator
Joined: 1 Dec 05
Posts: 6,205
Credit: 134,979,904
RAC: 25,174

More musings : After

More musings :

After rather more research on the OpenGL version issue ( what will the executable find on the target machine? ), I've made the following two-tier design choice regarding specifying vertex data ( a key part ie. where do the dots - that we will join to make polygons - go? ) :

- bare bones not using/assuming any hardware acceleration. This specifically means not using any server side arrays whatever. The current Starsphere code would fit this description, as only display lists with the glBegin()/glEnd() paradigm are used. The only reason this would fail is if the target machine didn't have any OpenGL on it at all ....

- better/quicker utilising OpenGL v1.5 + features ( since mid-2003 ie. Radeon X800, Radeon 9600, Radeon 9700, Radeon 9800, GeForce FX, and all later cards ). Hence I can use vertex buffer objects which have considerable advantages.

- put both methodologies in the same executable and simple code switching based on a query of the target machine's declared version. That doesn't quite ensure it's enacted wholly in hardware, as it could be software emulated, but hey ..... see your graphics card vendor for that :-) :-)

This refers to the rendering methods, and not 'scene quality' choices.

Cheers, Mike.

I have made this letter longer than usual because I lack the time to make it shorter. Blaise Pascal

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.