- smooth sphere rotation ( when enabled ), random is out.
- user able to vary viewpoint in elevation (north/south) via mouse drag and
- may as well have some mouse drag to rotate the viewpoint around the Earth in longitude.
- fix jaggy terminator.
As for the stack, well, the compiler puts local variables on the stack. Local variables here include arrays, those being some ~500,000 elements of byte for the bump array; and ~42,000 elements of float x 5 for the vertex array; ~ 42,000 elements of int x 6 for the index array; all in some ~2.3 MB of stack for a single routine before it blows up on a Windows 64-bit machine running a win32 instance. Linux can handle ~8,000,000 elements of byte; ~665,000 elements of float x 5; ~665,000 elements of int x 6; with total of ~29.2 MB and still not complain on a 64-bit machine running a 64-bit instance. Options are :
(A) limit all array instances to the win32 capable level.
(B) use #ifdef _WIN32 ( or similar ) at compilation to limit only win32 builds
(C) Put the arrays on the heap via new/delete.
..... one needs to keep in mind that this is meant to be a low footprint screensaver, so I'll go with A.
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
We now have Windows 32, Windows 64 and Linux builds for TEST011. To rotate the globe 'manually' hold the left mouse button down and drag in the left/right direction. To raise/lower your viewpoint with respect to the equator hold the left mouse button down and drag in the up/down direction.
The left/right drag behaves as expected. The slight misbehaviour is that the up/down drag sometimes works in the opposite sense ( this is due to a subtlety in rotations in 3D - they don't commute - and will annoy you ). I am working on a better way, so in the meantime hit the 'N' key to reset your view to 'neutral' if things get disorienting. I'm sure you can find Sweden ... :-)
Auto-rotation still toggles with the 'H' key and can be on or off as you please when you are left mouse button dragging.
The terminator is now smooth and the night side is darker. Hopefully you may perceive that the bright side is brightest in the centre of the lit hemisphere. This is intentional but subtle.
{ Also may I recommend the linux utility Swiss File Knife to all you coders out there. An all round whizz of a program. I use it's 'detab' facility to get rid of annoying tabs mixed in with spaces in the formatting which makes the column alignment of indents go awry sometimes. Of course, for makefiles you want/have to keep the tabs. }
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
Linux TEST11 works as advertised, that is, like a charm. The movements are waaaaay cool. Mike, I'm worried that you are having too much fun with this. :)
User tip: I find that toggling on the x/y/z rendering axes helps me maintain orientation when moving the sphere around.
Suggestion: Add a key (or button?) to toggle a help menu of the key toggle options and mouse control features. (Because there are so many!)
Ideas are not fixed, nor should they be; we live in model-dependent reality.
Ok code testers. We now have Windows 32, Windows 64 and Linux builds for TEST012. This has the requested help menu. I have placed it on the lower HUD, it is on by default and just keeps changing help advice ( every 250 rendered frames ) in an endless loop . Q, for query, will toggle it. It does mention some non-implemented features though.
We also have a bonus new logo for BOINC that I found. It's 3D and looks a beauty. I couldn't pass that up. :-)
Next I reckon I will next put a Sun on the celestial sphere in amongst the constellations. Plus of course implement any other suggestions you may have. But what I really need is live user and work unit data. That's the shared memory aspect.
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
I did notice though that Windows task manager reports that the program uses a full CPU core when running. Although I'm sure it's already on your to do list I thought I'd mention that it needs a bit of optimization once the feature development slows down a bit ;)
In Linux Test12, the BOINC logo looks great! Help tips (and inspirational messages) do the job well, though some overlap logo. Perhaps shrink down logo sizes, and sharpen font rendering? Yes, also on Linux the screen saver occupies 100% of a core/thread. These are niggling points, though. Agreed, it would be most helpful to get live user data displayed.
Astrophysics-y question: why are gamma emitters so spatially restricted?
Ideas are not fixed, nor should they be; we live in model-dependent reality.
Well I've solved the shared memory issue. It was a matter of which set of instructions do I use, recent or distant ? :-)
Go to your boinc client directory.
On Linux, my computer, it is /var/lib/boinc-client, and you will probably need to be either logged in as root or use sudo alot merely to list directory contents or change directories. On Windows it is C:Program Data/BOINC, where on my Windows 7 machine that is a hidden directory. So you have to change Explorer's habits via Control Panel->Folder Options->View->Show hidden files, folders and drives.
That boinc client directory has a subdirectory called slots. Go into that and you will see numbered sub-directories of it called '0, '1', .... etc. Pick one and go into it. Then copy the graphics executable to that and run it. Voila ! You will see your info on the upper right of the screensaver.
My confusion was down to a BOINC page which tells of a more 'modern' way to do inter process communication, which E@H doesn't implement for it's graphics apps. All we need is to have the graphics app and the science app in the same slot directory. There may be other ways but this will do for now.
Now I don't know why the gammas are so clustered. These were the difficult ones to find - that EAH discovered in the FermiLAT data - so all the easy to find ones were found by then.
On my Windows machine it seems there are about nine threads in the one graphics app process. My code is only one of those. I have no firm proof of what the others are doing. Presumably they are running all the back-end/invisible stuff behind the library code that is statically linked to my graphics code. But nonetheless it does use about a CPU worth of asset for sure. Mostly my code will be busy looping, either waiting for events, input or issuing rendering commands. Plus it does use the GPU of course and that would compete with E@H work units potentially. I'm not sure how to optimise that usefully. But it's a good question to ponder. To compare : a typical CPU E@H work unit has three threads, whereas an openCL/GPU work unit has eleven.
On the topic of Windows process overview I found two great tools : Process Explorer and Process Monitor. They look like they could answer more questions than I could ever ask ....
Otherwise I'll make the help HUD smaller to crowd the screen less. Now that I have a handle on the shared memory, I'll also get some work-unit related data onto the screen.
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
Okay, yes!, that works when I launch the screen saver from within the /var/lib/boinc-client/slots/0 directory, but not when I launch it from a symbolic link on my Desktop. From the link, the program launches, but it doesn't show my boinc info, just the default stub text. I don't know enough Linux to figure that out. I don't know whether it matters that my Desktop and the boinc-client folders are on different drives.
EDIT: I've also run into another problem - the screen saver file in the slots/0 folder gets deleted rather quickly, presumably by boinc-client overwriting the directory contents.
Ideas are not fixed, nor should they be; we live in model-dependent reality.
In Windows I created a shortcut to the screen saver executable, then I edited the properties of the shortcut so that the working directory (Start in) was the slot I targeted, this worked quite nicely and the user info and stats showed up as expected, thus no need to put the executable in the slot directory.
Could this also be done in Linux?
I'm sure it can but sadly I don't know how.
OK, next up :- darker
)
OK, next up :
- darker night time portion of Earth.
- smooth sphere rotation ( when enabled ), random is out.
- user able to vary viewpoint in elevation (north/south) via mouse drag and
- may as well have some mouse drag to rotate the viewpoint around the Earth in longitude.
- fix jaggy terminator.
As for the stack, well, the compiler puts local variables on the stack. Local variables here include arrays, those being some ~500,000 elements of byte for the bump array; and ~42,000 elements of float x 5 for the vertex array; ~ 42,000 elements of int x 6 for the index array; all in some ~2.3 MB of stack for a single routine before it blows up on a Windows 64-bit machine running a win32 instance. Linux can handle ~8,000,000 elements of byte; ~665,000 elements of float x 5; ~665,000 elements of int x 6; with total of ~29.2 MB and still not complain on a 64-bit machine running a 64-bit instance. Options are :
(A) limit all array instances to the win32 capable level.
(B) use #ifdef _WIN32 ( or similar ) at compilation to limit only win32 builds
(C) Put the arrays on the heap via new/delete.
..... one needs to keep in mind that this is meant to be a low footprint screensaver, so I'll go with A.
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
We now have Windows 32,
)
We now have Windows 32, Windows 64 and Linux builds for TEST011. To rotate the globe 'manually' hold the left mouse button down and drag in the left/right direction. To raise/lower your viewpoint with respect to the equator hold the left mouse button down and drag in the up/down direction.
The left/right drag behaves as expected. The slight misbehaviour is that the up/down drag sometimes works in the opposite sense ( this is due to a subtlety in rotations in 3D - they don't commute - and will annoy you ). I am working on a better way, so in the meantime hit the 'N' key to reset your view to 'neutral' if things get disorienting. I'm sure you can find Sweden ... :-)
Auto-rotation still toggles with the 'H' key and can be on or off as you please when you are left mouse button dragging.
The terminator is now smooth and the night side is darker. Hopefully you may perceive that the bright side is brightest in the centre of the lit hemisphere. This is intentional but subtle.
{ Also may I recommend the linux utility Swiss File Knife to all you coders out there. An all round whizz of a program. I use it's 'detab' facility to get rid of annoying tabs mixed in with spaces in the formatting which makes the column alignment of indents go awry sometimes. Of course, for makefiles you want/have to keep the tabs. }
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
Linux TEST11 works as
)
Linux TEST11 works as advertised, that is, like a charm. The movements are waaaaay cool. Mike, I'm worried that you are having too much fun with this. :)
User tip: I find that toggling on the x/y/z rendering axes helps me maintain orientation when moving the sphere around.
Suggestion: Add a key (or button?) to toggle a help menu of the key toggle options and mouse control features. (Because there are so many!)
Ideas are not fixed, nor should they be; we live in model-dependent reality.
I've now tested the Windows
)
I've now tested the Windows versions and they work great!
Thanks for adding the ability to vary the viewpoint!
A help menu would be nice, at least if running in stand alone mode.
Keep up the great work!
Ok code testers. We now
)
Ok code testers. We now have Windows 32, Windows 64 and Linux builds for TEST012. This has the requested help menu. I have placed it on the lower HUD, it is on by default and just keeps changing help advice ( every 250 rendered frames ) in an endless loop . Q, for query, will toggle it. It does mention some non-implemented features though.
We also have a bonus new logo for BOINC that I found. It's 3D and looks a beauty. I couldn't pass that up. :-)
Next I reckon I will next put a Sun on the celestial sphere in amongst the constellations. Plus of course implement any other suggestions you may have. But what I really need is live user and work unit data. That's the shared memory aspect.
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
Looking better and
)
Looking better and better!
I did notice though that Windows task manager reports that the program uses a full CPU core when running. Although I'm sure it's already on your to do list I thought I'd mention that it needs a bit of optimization once the feature development slows down a bit ;)
In Linux Test12, the BOINC
)
In Linux Test12, the BOINC logo looks great! Help tips (and inspirational messages) do the job well, though some overlap logo. Perhaps shrink down logo sizes, and sharpen font rendering? Yes, also on Linux the screen saver occupies 100% of a core/thread. These are niggling points, though. Agreed, it would be most helpful to get live user data displayed.
Astrophysics-y question: why are gamma emitters so spatially restricted?
Ideas are not fixed, nor should they be; we live in model-dependent reality.
Well I've solved the shared
)
Well I've solved the shared memory issue. It was a matter of which set of instructions do I use, recent or distant ? :-)
Go to your boinc client directory.
On Linux, my computer, it is /var/lib/boinc-client, and you will probably need to be either logged in as root or use sudo alot merely to list directory contents or change directories. On Windows it is C:Program Data/BOINC, where on my Windows 7 machine that is a hidden directory. So you have to change Explorer's habits via Control Panel->Folder Options->View->Show hidden files, folders and drives.
That boinc client directory has a subdirectory called slots. Go into that and you will see numbered sub-directories of it called '0, '1', .... etc. Pick one and go into it. Then copy the graphics executable to that and run it. Voila ! You will see your info on the upper right of the screensaver.
My confusion was down to a BOINC page which tells of a more 'modern' way to do inter process communication, which E@H doesn't implement for it's graphics apps. All we need is to have the graphics app and the science app in the same slot directory. There may be other ways but this will do for now.
Now I don't know why the gammas are so clustered. These were the difficult ones to find - that EAH discovered in the FermiLAT data - so all the easy to find ones were found by then.
On my Windows machine it seems there are about nine threads in the one graphics app process. My code is only one of those. I have no firm proof of what the others are doing. Presumably they are running all the back-end/invisible stuff behind the library code that is statically linked to my graphics code. But nonetheless it does use about a CPU worth of asset for sure. Mostly my code will be busy looping, either waiting for events, input or issuing rendering commands. Plus it does use the GPU of course and that would compete with E@H work units potentially. I'm not sure how to optimise that usefully. But it's a good question to ponder. To compare : a typical CPU E@H work unit has three threads, whereas an openCL/GPU work unit has eleven.
On the topic of Windows process overview I found two great tools : Process Explorer and Process Monitor. They look like they could answer more questions than I could ever ask ....
Otherwise I'll make the help HUD smaller to crowd the screen less. Now that I have a handle on the shared memory, I'll also get some work-unit related data onto the screen.
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
Okay, yes!, that works when I
)
Okay, yes!, that works when I launch the screen saver from within the /var/lib/boinc-client/slots/0 directory, but not when I launch it from a symbolic link on my Desktop. From the link, the program launches, but it doesn't show my boinc info, just the default stub text. I don't know enough Linux to figure that out. I don't know whether it matters that my Desktop and the boinc-client folders are on different drives.
EDIT: I've also run into another problem - the screen saver file in the slots/0 folder gets deleted rather quickly, presumably by boinc-client overwriting the directory contents.
Ideas are not fixed, nor should they be; we live in model-dependent reality.
In Windows I created a
)
In Windows I created a shortcut to the screen saver executable, then I edited the properties of the shortcut so that the working directory (Start in) was the slot I targeted, this worked quite nicely and the user info and stats showed up as expected, thus no need to put the executable in the slot directory.
Could this also be done in Linux?
I'm sure it can but sadly I don't know how.