Awesome job of coding this baby.I have a question how do I install it??
Just unzip the download ( and if Linux then modify properties to allow execution ) and run it. Any suitable directory will do for the moment but ultimately it will be placed/distributed, by BOINC mechanisms, where the project's executables are, as we will be including a file at that location containing the EAH assisted pulsar discoveries ( upon which a 'tour' will be based ).
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
The only significant change from the last version is that you get a tour of ( most of ) the E@H assisted pulsar discoveries, when you press F12. The pulsars are a deep orange and a larger dot. There are two other files included with the executable, a soft-link file that contains the url/name of the 'discovery data' file, and that data file itself. Next up :
- more housekeeping.
- a HUD 'target reticle' to be enabled when looking at a specific pulsar, so you know which dot we're referring to.
- a HUD image to appear with each pulsar showing the 'pulse profile' as per the data sheets.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Sorry, a tad delayed, but I should have something this w/end! :-)
Did you know that you ought ABSOLUTEY NOT make a virtual function call in a base class destructor ( the setting is delete-ing heap allocation using base class pointers ) as : by the time said destructor is called the derived class sub-object has already been destroyed ( by the derived class destructor ) and hence as the jump vtable contains an entry to the actual implemented function ( labelled as virtual in the hierarchy ) BUT this now points to freshly deleted air ??
No, you probably don't know. I do now.
[ I really think the paragraph above could be a hot pick up line for the 'A Nerd Needs A Bride' reality TV show. :- :-) ]
Ditto for virtual function calls in base class constructors - as the derived class sub-object doesn't yet exist.
SIGH .... that took two weeks to nail ..... you only find out at runtime .....
Cheers, Mike.
( edit ) BTW - 'undefined behaviour' as regards some language feature/scenario/instance basically means anything might happen and still be considered not incorrect with respect to language standards. So one may inadvertently invoke undefined behaviour ( and not know that ) and get away with it ( and not know that either ). So you can get different behaviours on different implementions for identical code without it being 'the fault' of either implementation. You could be lucky one way but not another .... I was fortunate that the language runtime system caught the incorrect virtual call and halted execution, with a suitable message, as opposed to proceeding with the jump and then who knows what?
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Did you know that you ought ABSOLUTEY NOT make a virtual function call in a base class destructor ( the setting is delete-ing heap allocation using base class pointers ) as : by the time said destructor is called the derived class sub-object has already been destroyed ( by the derived class destructor ) and hence as the jump vtable contains an entry to the actual implemented function ( labelled as virtual in the hierarchy ) BUT this now points to freshly deleted air ??
Makes quite a lot of sense to me :-)
Quote:
Ditto for virtual function calls in base class constructors - as the derived class sub-object doesn't yet exist.
Now the question arises why you would want to use such constructs (calls) in the first place...?
Now the question arises why you would want to use such constructs (calls) in the first place...?
Ah, the cleaning up ( particularly ) of OpenGL resources allocated during object construction in addition to ordinary heap usage. I do this for temporary images for animations and the like, part of a general strategy to minimise both main memory and graphics card memory load dynamically.
But I've sorted that out now : requiring a given derived class ( whoever actually new-ed some heap allocation and/or acquired OpenGL assets ) to clean up it's own outlays within it's own destructor. The reason why hierarchy comes in at all is that I store ( base class ) pointers to heap based objects, in an std::vector say, as stuff gets allocated/used/de-allocated ( polymorphically resolving to derived class virtual function definitions that 'prepare', 'render' and 'release' ). Each derived class based on the 'Renderable' type has to do it's own specialised thing .... draw some text in 3D, place an image on the HUD, put down scrolling text, map out & then give a title to a constellation, plot and label some co-ordinate grid, construct then texture a mesh approximating a sphere, etc ... so a higher level of control just says to each derived object of Renderable base type : 'acquire your assets', 'draw thyself', 'now go away' ... :-)
When I'm finished with a series of images I can just run through the list of pointers, delete-ing each and thus provoking specific destructors before the memory previously allocated to said objects is returned to heap pool. The list doesn't even have to contain pointers to the same derived type, as long as they're all within the Renderable hierarchy!
I simply put certain 'responsibilities' in at the wrong level in the hierarchy. A silly mistake, bad design, but I learn.
Hi Bernd! :-)
Now that you point her out, that Venetian Princess expresses exactly what I had in mind! DownUnda we have Beauty and The Geek ... :-)
Cheers,Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Another spot of good news guys. With research I've discovered a couple or seven things ( to be placed on the backburner for now ) :
- one can do code for OpenGL v3.2+ ( 'forward compatible context' ) as well as pre v3.1 ( 'backwards compatible context' ) within the same executable.
- this opens up a solution to writing for later machines and video cards that don't provide a 'backwards compatible context'.
- decide/switch at runtime using a 'Renderable' type of abstraction ( or somesuch ) as only 'prepare', 'render' and 'release' are actually in significant contact with the OpenGL API.
- write 'pass-thru shaders' that don't alter vertices and/or fragments at all. Shaders are the v2.0+ mechanism that v3.2+ continues with to allow per-vertex and per-fragment user defined processing in lieu of relying upon custom and/or vendor supplied extensions. A shader is a text string - think of it like a source file rolled up into one - written in 'shader language' that is 'compiled' ( interpreted really ) at runtime. A vertex shader is a sort of user-defined intercept of vertex data on it's way into the rendering pipeline. A fragment shader is likewise but coming out of the pipeline. But you don't have to do anything beyond just supplying said shaders, they can transmit data through themselves unaltered.
The downside :
- as usual, drivers that are untruthful about their provision of API features ( a small but annoying minority ).
- display lists don't exist in v3.2+, so Starsphere as it stands is still stuck at v3.1 and less, plus OGLFT uses them under the hood.
But :
- it wouldn't be hard ( at least I think so for me! ) to re-write Starsphere with the same graphics output and behaviour, without display lists. I already use server side 'vertex arrays in buffer objects' ( VABO's ) that is the blessed/preferred v3.2+ method to specify/handle vertex and color data.
- after a really long hard look I have decided that I could actually rewrite OGLFT ( call it OGLFTX say ) to operate without display lists ( use VABO's instead ) in these new v3.2 contexts. I've identified the base library components that operate the display lists, I wouldn't have to change the 'higher' layers. No-one else has done that and more than a few others could use that capability too ... but next year maybe. :-)
Cheers, Mike.
( edit ) Since the contents of VABO's are fully malleable by the application ( as opposed to display lists which cannot be altered once created ) then this also gets around a few existing OGLFT annoyances & limitations : decisions about 'compilation' and glyph caching, foreground and background color changes not allowed once a string is textured to a quad, etc ....
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
... which I'm not totally happy with as there is :
- a difference in reporting of the 'window size' b/w Linux and Windows. Linux gives you the client area ie. the bit I can draw upon, whereas Windows gives you that plus the OS determined window border width ( so they typically differ by a few pixels ). This means the pulsar 'on view' during the tour will not be in the same position with respect to it's animated reticle b/w the two systems.
- a difference in re-acquiring video card ( ie. OpenGL 'server' ) assets after a window resize. Again this is managed differently b/w Linux and Windows. Until I sort that out more simply, the current behaviour is : if you resize the window on either platform while the tour is running ( invoke with F12, turn off with F12 ) you will lose the per pulsar informative text ( who discovered what, pulsar parameters etc ) on the upper screen and the pretty graphic ( best pulse profile ) on the left of screen. Thus to demonstrate the tour it's best to resize and/or move the window to whatever suits, and then invoke it.
In any case you can see the general idea coming out. The screensaver invoked under BOINC ( if enabled ) will be able to demonstrate a list of GW discoveries for GW WU's, pulsar discoveries for radio WU's, and gamma source discoveries for gamma WU's. In lieu you get a tour of the constellations. I've left the right hand 'pane' on the HUD free, for WU specific information to be plucked from the BOINC API on the fly according to a yet to be determined format ( ie. that's one of my next jobs ). I think the 'power spectrum graph' is a very much liked feature on the pulsar jobs ( upper right hand corner on Starsphere ) so I may go down that line.
Cheers, Mike.
( edit ) and I'll be throwing in logos of the science teams/collaborations on a per WU type basis eg. LIGO/GEO/Virgo for GW's, PALFA/ATNF for radio WU's, FermiLAT for gammas .... and sneak in an E@H logo somewhere for all types. I think I'll keep the scrolling marquee with our web address, after all we want people casually strolling past said target machine to think 'That's interesting, where do I go to get that for my machine?' :-) :-)
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
This is built from commit baa4411f5bfda1d9940ac620cf33484a0a25340e and tagged as 'V0.70'. The re-acquire problem is sorted, and I'll live with a pixel or two out on the client area size.
I discovered that I really didn't need fancy lighting so much as rendered shadows, so one can now see the Earth 'lit' by the Sun with a day and night side ! :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Note : be careful of updates on a build system. My Ubuntu 12.10 had an update which involved a change in the X11 system - toward a thing called XCB - and this broke the build ( can't find libraries etc ) for GLFW.
After much fruitless mucking about I decided simply to re-install 12.04 LTS. All good now. Plus I'll pay more attention to upgrade suggestions in future .... :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: Awesome job of coding
)
Just unzip the download ( and if Linux then modify properties to allow execution ) and run it. Any suitable directory will do for the moment but ultimately it will be placed/distributed, by BOINC mechanisms, where the project's executables are, as we will be including a file at that location containing the EAH assisted pulsar discoveries ( upon which a 'tour' will be based ).
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Ok, here is the latest
)
Ok, here is the latest offering, by the name of version 0.50 ( download, unzip & run the executable )
Linux Version
Windows Version
This is built from commit 5cace7cae313a9934a1bee8e10ca468f63fb71bd and tagged as 'V0.50'.
The only significant change from the last version is that you get a tour of ( most of ) the E@H assisted pulsar discoveries, when you press F12. The pulsars are a deep orange and a larger dot. There are two other files included with the executable, a soft-link file that contains the url/name of the 'discovery data' file, and that data file itself. Next up :
- more housekeeping.
- a HUD 'target reticle' to be enabled when looking at a specific pulsar, so you know which dot we're referring to.
- a HUD image to appear with each pulsar showing the 'pulse profile' as per the data sheets.
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Sorry, a tad delayed, but I
)
Sorry, a tad delayed, but I should have something this w/end! :-)
Did you know that you ought ABSOLUTEY NOT make a virtual function call in a base class destructor ( the setting is delete-ing heap allocation using base class pointers ) as : by the time said destructor is called the derived class sub-object has already been destroyed ( by the derived class destructor ) and hence as the jump vtable contains an entry to the actual implemented function ( labelled as virtual in the hierarchy ) BUT this now points to freshly deleted air ??
No, you probably don't know. I do now.
[ I really think the paragraph above could be a hot pick up line for the 'A Nerd Needs A Bride' reality TV show. :- :-) ]
Ditto for virtual function calls in base class constructors - as the derived class sub-object doesn't yet exist.
SIGH .... that took two weeks to nail ..... you only find out at runtime .....
Cheers, Mike.
( edit ) BTW - 'undefined behaviour' as regards some language feature/scenario/instance basically means anything might happen and still be considered not incorrect with respect to language standards. So one may inadvertently invoke undefined behaviour ( and not know that ) and get away with it ( and not know that either ). So you can get different behaviours on different implementions for identical code without it being 'the fault' of either implementation. You could be lucky one way but not another .... I was fortunate that the language runtime system caught the incorrect virtual call and halted execution, with a suitable message, as opposed to proceeding with the jump and then who knows what?
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
RE: Did you know that you
)
Makes quite a lot of sense to me :-)
Now the question arises why you would want to use such constructs (calls) in the first place...?
Cheers,
Oliver
Einstein@Home Project
RE: [ I really think the
)
You should suggest this to The Big Bang Theory.
And discuss this with Venetianprincess.
BM
BM
Hi Oliver!
)
Hi Oliver! :-)
Ah, the cleaning up ( particularly ) of OpenGL resources allocated during object construction in addition to ordinary heap usage. I do this for temporary images for animations and the like, part of a general strategy to minimise both main memory and graphics card memory load dynamically.
But I've sorted that out now : requiring a given derived class ( whoever actually new-ed some heap allocation and/or acquired OpenGL assets ) to clean up it's own outlays within it's own destructor. The reason why hierarchy comes in at all is that I store ( base class ) pointers to heap based objects, in an std::vector say, as stuff gets allocated/used/de-allocated ( polymorphically resolving to derived class virtual function definitions that 'prepare', 'render' and 'release' ). Each derived class based on the 'Renderable' type has to do it's own specialised thing .... draw some text in 3D, place an image on the HUD, put down scrolling text, map out & then give a title to a constellation, plot and label some co-ordinate grid, construct then texture a mesh approximating a sphere, etc ... so a higher level of control just says to each derived object of Renderable base type : 'acquire your assets', 'draw thyself', 'now go away' ... :-)
When I'm finished with a series of images I can just run through the list of pointers, delete-ing each and thus provoking specific destructors before the memory previously allocated to said objects is returned to heap pool. The list doesn't even have to contain pointers to the same derived type, as long as they're all within the Renderable hierarchy!
I simply put certain 'responsibilities' in at the wrong level in the hierarchy. A silly mistake, bad design, but I learn.
Hi Bernd! :-)
Now that you point her out, that Venetian Princess expresses exactly what I had in mind! DownUnda we have Beauty and The Geek ... :-)
Cheers,Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Another spot of good news
)
Another spot of good news guys. With research I've discovered a couple or seven things ( to be placed on the backburner for now ) :
- one can do code for OpenGL v3.2+ ( 'forward compatible context' ) as well as pre v3.1 ( 'backwards compatible context' ) within the same executable.
- this opens up a solution to writing for later machines and video cards that don't provide a 'backwards compatible context'.
- decide/switch at runtime using a 'Renderable' type of abstraction ( or somesuch ) as only 'prepare', 'render' and 'release' are actually in significant contact with the OpenGL API.
- write 'pass-thru shaders' that don't alter vertices and/or fragments at all. Shaders are the v2.0+ mechanism that v3.2+ continues with to allow per-vertex and per-fragment user defined processing in lieu of relying upon custom and/or vendor supplied extensions. A shader is a text string - think of it like a source file rolled up into one - written in 'shader language' that is 'compiled' ( interpreted really ) at runtime. A vertex shader is a sort of user-defined intercept of vertex data on it's way into the rendering pipeline. A fragment shader is likewise but coming out of the pipeline. But you don't have to do anything beyond just supplying said shaders, they can transmit data through themselves unaltered.
The downside :
- as usual, drivers that are untruthful about their provision of API features ( a small but annoying minority ).
- display lists don't exist in v3.2+, so Starsphere as it stands is still stuck at v3.1 and less, plus OGLFT uses them under the hood.
But :
- it wouldn't be hard ( at least I think so for me! ) to re-write Starsphere with the same graphics output and behaviour, without display lists. I already use server side 'vertex arrays in buffer objects' ( VABO's ) that is the blessed/preferred v3.2+ method to specify/handle vertex and color data.
- after a really long hard look I have decided that I could actually rewrite OGLFT ( call it OGLFTX say ) to operate without display lists ( use VABO's instead ) in these new v3.2 contexts. I've identified the base library components that operate the display lists, I wouldn't have to change the 'higher' layers. No-one else has done that and more than a few others could use that capability too ... but next year maybe. :-)
Cheers, Mike.
( edit ) Since the contents of VABO's are fully malleable by the application ( as opposed to display lists which cannot be altered once created ) then this also gets around a few existing OGLFT annoyances & limitations : decisions about 'compilation' and glyph caching, foreground and background color changes not allowed once a string is textured to a quad, etc ....
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
At last! Progress I can
)
At last! Progress I can demonstrate :
Linux Version
Windows Version
This is built from commit f0451c51ad325179631cf4f7b55c7763b981c19f and tagged as 'V0.61'.
... which I'm not totally happy with as there is :
- a difference in reporting of the 'window size' b/w Linux and Windows. Linux gives you the client area ie. the bit I can draw upon, whereas Windows gives you that plus the OS determined window border width ( so they typically differ by a few pixels ). This means the pulsar 'on view' during the tour will not be in the same position with respect to it's animated reticle b/w the two systems.
- a difference in re-acquiring video card ( ie. OpenGL 'server' ) assets after a window resize. Again this is managed differently b/w Linux and Windows. Until I sort that out more simply, the current behaviour is : if you resize the window on either platform while the tour is running ( invoke with F12, turn off with F12 ) you will lose the per pulsar informative text ( who discovered what, pulsar parameters etc ) on the upper screen and the pretty graphic ( best pulse profile ) on the left of screen. Thus to demonstrate the tour it's best to resize and/or move the window to whatever suits, and then invoke it.
In any case you can see the general idea coming out. The screensaver invoked under BOINC ( if enabled ) will be able to demonstrate a list of GW discoveries for GW WU's, pulsar discoveries for radio WU's, and gamma source discoveries for gamma WU's. In lieu you get a tour of the constellations. I've left the right hand 'pane' on the HUD free, for WU specific information to be plucked from the BOINC API on the fly according to a yet to be determined format ( ie. that's one of my next jobs ). I think the 'power spectrum graph' is a very much liked feature on the pulsar jobs ( upper right hand corner on Starsphere ) so I may go down that line.
Cheers, Mike.
( edit ) and I'll be throwing in logos of the science teams/collaborations on a per WU type basis eg. LIGO/GEO/Virgo for GW's, PALFA/ATNF for radio WU's, FermiLAT for gammas .... and sneak in an E@H logo somewhere for all types. I think I'll keep the scrolling marquee with our web address, after all we want people casually strolling past said target machine to think 'That's interesting, where do I go to get that for my machine?' :-) :-)
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
More progress : Linux
)
More progress :
Linux Version
Windows Version
This is built from commit baa4411f5bfda1d9940ac620cf33484a0a25340e and tagged as 'V0.70'. The re-acquire problem is sorted, and I'll live with a pixel or two out on the client area size.
I discovered that I really didn't need fancy lighting so much as rendered shadows, so one can now see the Earth 'lit' by the Sun with a day and night side ! :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal
Note : be careful of updates
)
Note : be careful of updates on a build system. My Ubuntu 12.10 had an update which involved a change in the X11 system - toward a thing called XCB - and this broke the build ( can't find libraries etc ) for GLFW.
After much fruitless mucking about I decided simply to re-install 12.04 LTS. All good now. Plus I'll pay more attention to upgrade suggestions in future .... :-)
Cheers, Mike.
I have made this letter longer than usual because I lack the time to make it shorter ...
... and my other CPU is a Ryzen 5950X :-) Blaise Pascal