- alas I haven't yet encapsulated the images into the executables.
- the Windows version ought work on any that offers at least OpenGL version 1.5 from it's driver, it will fail with detailed complaint otherwise.
- I've added a latitude/longitude overlay upon the Earth, cycle through the options for that ( nothing, grid, grid & labels ) using F9
- see the file 'keybindings.txt' for which keys do what
- I splashed some text and logos around the HUD, which you won't see at all if the window is too small ( if you do alot of window resizing, expect delays ).
- and yes, the Earth and the Sun aren't rotating in the correct relative timing.
- I still haven't fixed the missing texture slices for north and south poles of the Sun and Earth.
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
Tested the windows version and it seems to work. It took a while to load but once running it ran nicely. Looks great!
The only thing that I could find that did not work as expected was that pressing keys F1, F2 and F3 gave an "unassigned" message in the log, and F4 register a key press but does not register what key was pressed.
Once again thank you and great work on this program!
Hi Oliver! Well done to all the devs with the OpenCL effort! I'll put an OpenCL logo into the screensaver now .... :-)
Simply getting a Mac build at all would be nice bonus. I can't get the 10.4u SDK onto my Ubuntu and I haven't a Mac. I've altered the makefile.macos to reflect the new classes I've written. I don't know of any OpenGL issues other than already mentioned :
Quote:
- Mac OS 10.7+ currently only offers forward compatible 3.2+ OpenGL contexts, but will probably ( this isn't clear to me ) allow Carbon/Cocoa ( whoever they are ).
which puts in doubt my code as I need a backward compatible context ie. the context behaves as honoring v1.5+
@Holmis : the Windows slow load is due to all the rigamarole to get a working context. Alas Windows will always be less efficient as the post v1.1 OpenGL calls have a necessary indirection mechanism ( function pointers ) which slows things, plus a simple window resize requires video card buffers to be re-loaded with all the data and textures etc. In fact alot of quick resizes in a row will provoke Windows to report that the app is not responding - though all is indeed well - as the app hasn't come back around soon enough to empty it's message queue. I'll clean up the keypress reporting, alot of it is there for debug and is no longer needed.
Next up ( apart from some housekeeping ) : an autopilot-like mechanism to engage in a 'sightseeing tour', with an eye to showing off the E@H assisted pulsar discoveries. See the pulsars on the celestial sphere and read the details on the HUD ... :-)
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
Just a note to indicate that the project has NOT fallen out of the tree. I've been doing alot of backend work on the framework code as well as my screensaver variant. That is : the 'some housekeeping' has rather expanded! :-)
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
Same keyboard interface as before but if you press F12 then you'll get a tour of the constellations ( all 88 of them ) and in alphabetical order. On my ( hotshot ) machines it takes about an hour from Andromeda to Vulpecula, quite a lazy rate. It will engage the tour wherever your craft is, but expect some high slew rate if you're at some odd attitude. The display will pause as it reaches each constellation and a short descriptive note appears at the bottom of the screen. It'll cycle that way endlessly until you hit F12 again, in which case you have 'flying' control again. Flick in and out of the tour as often as you please, but you'll always restart at Andromeda.
Notes :
- I've done an extensive code review, mainly for documentation and clarity, but have made some minor changes to flow control.
- No tab characters at all and 4 spaces per indent. ;-}
- I have discovered that GLFW doesn't really report windowed vs fullscreen capability very well, but fortunately it doesn't seem to matter as one still gets the desired modes when you ask. There is a similiar issue with obtaining a list of supported screen sizes and resolutions, but again you get what you ask for ( or nearest ) when it matters. So I'm re-thinking that part of the code .... but I believe that aspect of the GLFW library code is being redone anyway.
- I've decided to make all animation features evolve on a per frame basis not on a real-time/wall-clock time basis. By that I don't mean frame rate, but ( within limits ) all machines ought produce a similiar sequence of frames. Faster machines will run through an 'identical' frame sequence quicker than slower ones. This avoids either too fast evolution ( I've capped the frame rate to ~100 fps ) which can look silly, and avoids jarring jumps/gaps in the viewpoint for slower machines.
- virtually every 'artistic' aspect is malleable ( colors, fonts, font sizes, point and line thicknesses/style etc ) so please speak up if you find a problem on your monitor, or have any style suggestions. I've removed all HUD images for an uncluttered view.
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
Nice to see some progress again, I've been waiting and hoping! =)
Since the last release I've made some upgrades to my computer and now have both an Geforce 9600GT and an Intel HD Graphics 4000 IGP (i7 3770k).
All this is running under Win 7 x64. Link to host info.
The screen saver is still running fine on the 9600GT although it's a slow starter as discussed earlier, patience is a virtue!
I have to say that this version looks amazing! Clean and simple yet detailed and interesting, really great work!
I like the new tour-function.
Might it be possible to let the user choose how fast one moves between constellations? It felt a bit slow but that could be my card not being all that powerful...
Now over to my test run on the HD Graphics 4000 - a window flashes by and the app exits, the eahss_stderr.txt says this:
INFO : WindowManager::initialize() : Using GLfW version 2.7.5
INFO : WindowManager::getVideoModes() : Number of video modes found = 48
INFO : WindowManager::getVideoModes() : 320 x 200 @ 16
I cut out some of the INFO lines to keep the post shorter, it's just a listing of available screen resolutions...
INFO : WindowManager::getVideoModes() : 1920 x 1080 @ 24
INFO : WindowManager::initialize() : Fullscreen video mode is supported
INFO : WindowManager::initialize() : Rendering surface acquired 1920 x 1080 @ 24 colors with a 24 bit depth buffer
INFO : WindowManager::initialize() : Using GLEW version 1.7.0
INFO : WindowManager::setOGLContext() : OpenGL v3.3
INFO : WindowManager::setOGLContext() : OpenGL v3.2+ version
INFO : WindowManager::setOGLContext() : GL_ARB_compatibility supported
WARN : WindowManager::setOGLContext() : WGL_ARB_create_context_profile NOT supported
INFO : WindowManager::initialize() : could not acquire correct OpenGL backward compatible version
FATAL EXIT: SolarSystem::main() : Window manager could not be initialized!
Seems something is missing in Intels OpenGL implementation or driver...
Nice to see some progress again, I've been waiting and hoping! =)
Well, I wanted to not leave either my code or the framework in a mess. Plus if I comment the code properly, I have to understand it better too.
Quote:
Since the last release I've made some upgrades to my computer and now have both an Geforce 9600GT and an Intel HD Graphics 4000 IGP (i7 3770k).
All this is running under Win 7 x64. Link to host info.
It's always nice to have an upgrade. :-)
Quote:
The screen saver is still running fine on the 9600GT although it's a slow starter as discussed earlier, patience is a virtue!
I have to say that this version looks amazing! Clean and simple yet detailed and interesting, really great work!
Yup, the idea is to be fairly self evident but still interesting. The visual features are eminently upgradeable ( that's the trick with object oriented code ). So if I find a better font, or a better way to present a line, or a snappier way to render a star than a simple point etc .... I can just alter a fairly small section of the code and rebuild. Ultimately such choices will be enacted as part of the quality choice via BOINC preferences. Cognitively I'm going for the lowest common denominator by assuming that the user knows nothing about astronomy or the project. Essentially I hope to encourage people's minds to 'get off the planet' for a while ...
Quote:
I like the new tour-function.
Thank you. That took a bit of work, but now I have reasonably smooth way of touring pretty well any list of objects in the simulation.
Quote:
Might it be possible to let the user choose how fast one moves between constellations? It felt a bit slow but that could be my card not being all that powerful...
Fair enough point, of which I have thought alot about. I think there ought be three design options/handles to manage this generally :
- use a lower modeling complexity, or texture quality. The frames will then render faster. For instance the vertex mesh for the spherical shapes can have fewer points, or a lower resolution image can be used to texture with. Fonts are rather like textures ( indeed some are enacted as textures ), so some font choices are rather quicker. Especially with smoothing, anti-aliasing, transparency etc.
- inactivate visual components eg. coordinate grids, or some whole set of objects like supernovae.
- increase the virtual distance between frames ie. move the camera along within simulation space more between renders. The risk here is some 'staggering' or 'jerkiness' in the manner of a Charlie Chaplin flick.
It's not a linear issue alas as hardware will vary in specific strengths with regard to the varying techniques used. Eventually this will become subsumed as a 'blocks of choices' get rolled into the BOINC quality grades of low/medium/high. One of my next steps is to have a framerate indicator. Basically you want to keep the rate above about 30 frames per second for a good visual flow, but not so high as to unnecessarily consume cycles and memory without sensible gain. After all it is supposed to potentially operate as a screensaver that will run alongside CPU's and GPU's that are occupied by E@H work units. So it would be dumb to produce a screensaver that detracted from the project's work !!
Quote:
Now over to my test run on the HD Graphics 4000 .....
.... FATAL EXIT: SolarSystem::main() : Window manager could not be initialized!
I gather this was a central concern in the fuss from OpenGL 3.0 to 3.1 to 3.2 and beyond. If a feature was optional, and for v3.2+ providing a backwards compatible context is optional, then it wouldn't be written for. Compliance could ( correctly ) be claimed without it. A page about your hardware linked from the page Robert has found - thank you Robert - contains this :
Quote:
The latest Intel® graphics drivers provide support for the OpenGL version 3.3.
Which is precisely correct. But if you didn't know of the backwards compatibility matter you could well be disappointed. Case in point.
Thank you both kindly for your feedback.
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.22 ( download, unzip & run the executable )
Linux Version
Windows Version
- alas I haven't yet encapsulated the images into the executables.
- the Windows version ought work on any that offers at least OpenGL version 1.5 from it's driver, it will fail with detailed complaint otherwise.
- I've added a latitude/longitude overlay upon the Earth, cycle through the options for that ( nothing, grid, grid & labels ) using F9
- see the file 'keybindings.txt' for which keys do what
- I splashed some text and logos around the HUD, which you won't see at all if the window is too small ( if you do alot of window resizing, expect delays ).
- and yes, the Earth and the Sun aren't rotating in the correct relative timing.
- I still haven't fixed the missing texture slices for north and south poles of the Sun and Earth.
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
Nice work! Tested the
)
Nice work!
Tested the windows version and it seems to work. It took a while to load but once running it ran nicely. Looks great!
The only thing that I could find that did not work as expected was that pressing keys F1, F2 and F3 gave an "unassigned" message in the log, and F4 register a key press but does not register what key was pressed.
Once again thank you and great work on this program!
/Johan
RE: Ok, here is the latest
)
Great work Mike! I guess I have to devote some time to the Mac build in order to test (see!) it myself ;-)
Now that our OpenCL/ATI GPU apps finally went live, is there anything in particular I can/should do if time allows?
Cheers,
Oliver
Einstein@Home Project
Hi Oliver! Well done to all
)
Hi Oliver! Well done to all the devs with the OpenCL effort! I'll put an OpenCL logo into the screensaver now .... :-)
Simply getting a Mac build at all would be nice bonus. I can't get the 10.4u SDK onto my Ubuntu and I haven't a Mac. I've altered the makefile.macos to reflect the new classes I've written. I don't know of any OpenGL issues other than already mentioned :
which puts in doubt my code as I need a backward compatible context ie. the context behaves as honoring v1.5+
@Holmis : the Windows slow load is due to all the rigamarole to get a working context. Alas Windows will always be less efficient as the post v1.1 OpenGL calls have a necessary indirection mechanism ( function pointers ) which slows things, plus a simple window resize requires video card buffers to be re-loaded with all the data and textures etc. In fact alot of quick resizes in a row will provoke Windows to report that the app is not responding - though all is indeed well - as the app hasn't come back around soon enough to empty it's message queue. I'll clean up the keypress reporting, alot of it is there for debug and is no longer needed.
Next up ( apart from some housekeeping ) : an autopilot-like mechanism to engage in a 'sightseeing tour', with an eye to showing off the E@H assisted pulsar discoveries. See the pulsars on the celestial sphere and read the details on the HUD ... :-)
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
Just a note to indicate that
)
Just a note to indicate that the project has NOT fallen out of the tree. I've been doing alot of backend work on the framework code as well as my screensaver variant. That is : the 'some housekeeping' has rather expanded! :-)
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.40 ( download, unzip & run the executable )
Linux Version
Windows Version
This is built from commit 568c92fc497d884f419419add79ad57e0a509e62 and tagged as 'V0.40'.
Same keyboard interface as before but if you press F12 then you'll get a tour of the constellations ( all 88 of them ) and in alphabetical order. On my ( hotshot ) machines it takes about an hour from Andromeda to Vulpecula, quite a lazy rate. It will engage the tour wherever your craft is, but expect some high slew rate if you're at some odd attitude. The display will pause as it reaches each constellation and a short descriptive note appears at the bottom of the screen. It'll cycle that way endlessly until you hit F12 again, in which case you have 'flying' control again. Flick in and out of the tour as often as you please, but you'll always restart at Andromeda.
Notes :
- I've done an extensive code review, mainly for documentation and clarity, but have made some minor changes to flow control.
- No tab characters at all and 4 spaces per indent. ;-}
- I have discovered that GLFW doesn't really report windowed vs fullscreen capability very well, but fortunately it doesn't seem to matter as one still gets the desired modes when you ask. There is a similiar issue with obtaining a list of supported screen sizes and resolutions, but again you get what you ask for ( or nearest ) when it matters. So I'm re-thinking that part of the code .... but I believe that aspect of the GLFW library code is being redone anyway.
- I've decided to make all animation features evolve on a per frame basis not on a real-time/wall-clock time basis. By that I don't mean frame rate, but ( within limits ) all machines ought produce a similiar sequence of frames. Faster machines will run through an 'identical' frame sequence quicker than slower ones. This avoids either too fast evolution ( I've capped the frame rate to ~100 fps ) which can look silly, and avoids jarring jumps/gaps in the viewpoint for slower machines.
- virtually every 'artistic' aspect is malleable ( colors, fonts, font sizes, point and line thicknesses/style etc ) so please speak up if you find a problem on your monitor, or have any style suggestions. I've removed all HUD images for an uncluttered view.
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
Nice to see some progress
)
Nice to see some progress again, I've been waiting and hoping! =)
Since the last release I've made some upgrades to my computer and now have both an Geforce 9600GT and an Intel HD Graphics 4000 IGP (i7 3770k).
All this is running under Win 7 x64. Link to host info.
The screen saver is still running fine on the 9600GT although it's a slow starter as discussed earlier, patience is a virtue!
I have to say that this version looks amazing! Clean and simple yet detailed and interesting, really great work!
I like the new tour-function.
Might it be possible to let the user choose how fast one moves between constellations? It felt a bit slow but that could be my card not being all that powerful...
Now over to my test run on the HD Graphics 4000 - a window flashes by and the app exits, the eahss_stderr.txt says this:
I cut out some of the INFO lines to keep the post shorter, it's just a listing of available screen resolutions...
INFO : WindowManager::getVideoModes() : 1920 x 1080 @ 24
INFO : WindowManager::initialize() : Fullscreen video mode is supported
INFO : WindowManager::initialize() : Rendering surface acquired 1920 x 1080 @ 24 colors with a 24 bit depth buffer
INFO : WindowManager::initialize() : Using GLEW version 1.7.0
INFO : WindowManager::setOGLContext() : OpenGL v3.3
INFO : WindowManager::setOGLContext() : OpenGL v3.2+ version
INFO : WindowManager::setOGLContext() : GL_ARB_compatibility supported
WARN : WindowManager::setOGLContext() : WGL_ARB_create_context_profile NOT supported
INFO : WindowManager::initialize() : could not acquire correct OpenGL backward compatible version
FATAL EXIT: SolarSystem::main() : Window manager could not be initialized!
Seems something is missing in Intels OpenGL implementation or driver...
/Johan
A web page where you can
)
A web page where you can suggest the Intel start supporting WGL_ARB_create_context_profile :
http://www.intel.com/support/graphics/sb/cs-010479.htm
RE: Nice to see some
)
Well, I wanted to not leave either my code or the framework in a mess. Plus if I comment the code properly, I have to understand it better too.
It's always nice to have an upgrade. :-)
Yup, the idea is to be fairly self evident but still interesting. The visual features are eminently upgradeable ( that's the trick with object oriented code ). So if I find a better font, or a better way to present a line, or a snappier way to render a star than a simple point etc .... I can just alter a fairly small section of the code and rebuild. Ultimately such choices will be enacted as part of the quality choice via BOINC preferences. Cognitively I'm going for the lowest common denominator by assuming that the user knows nothing about astronomy or the project. Essentially I hope to encourage people's minds to 'get off the planet' for a while ...
Thank you. That took a bit of work, but now I have reasonably smooth way of touring pretty well any list of objects in the simulation.
Fair enough point, of which I have thought alot about. I think there ought be three design options/handles to manage this generally :
- use a lower modeling complexity, or texture quality. The frames will then render faster. For instance the vertex mesh for the spherical shapes can have fewer points, or a lower resolution image can be used to texture with. Fonts are rather like textures ( indeed some are enacted as textures ), so some font choices are rather quicker. Especially with smoothing, anti-aliasing, transparency etc.
- inactivate visual components eg. coordinate grids, or some whole set of objects like supernovae.
- increase the virtual distance between frames ie. move the camera along within simulation space more between renders. The risk here is some 'staggering' or 'jerkiness' in the manner of a Charlie Chaplin flick.
It's not a linear issue alas as hardware will vary in specific strengths with regard to the varying techniques used. Eventually this will become subsumed as a 'blocks of choices' get rolled into the BOINC quality grades of low/medium/high. One of my next steps is to have a framerate indicator. Basically you want to keep the rate above about 30 frames per second for a good visual flow, but not so high as to unnecessarily consume cycles and memory without sensible gain. After all it is supposed to potentially operate as a screensaver that will run alongside CPU's and GPU's that are occupied by E@H work units. So it would be dumb to produce a screensaver that detracted from the project's work !!
I gather this was a central concern in the fuss from OpenGL 3.0 to 3.1 to 3.2 and beyond. If a feature was optional, and for v3.2+ providing a backwards compatible context is optional, then it wouldn't be written for. Compliance could ( correctly ) be claimed without it. A page about your hardware linked from the page Robert has found - thank you Robert - contains this :
Which is precisely correct. But if you didn't know of the backwards compatibility matter you could well be disappointed. Case in point.
Thank you both kindly for your feedback.
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
Awesome job of coding this
)
Awesome job of coding this baby.I have a question how do I install it??