We could even move sidewards, out of the vertical inheritance scheme, and put some eugenic stuff into classes [...]
Eugenic? WTF? Safari's auto-correcttion... That should read generic of course...
Quote:
[ I've even been adventurous and mixed those together. In my HUD hierarchy I have a container class which subclasses to specifics, but a container can also contain another container within! This gives two hierarchies (a) OOP inheritance and (b) composition. Which is why it took so long to write - separating "is a" and "has a" in my mind on a per instance basis :-) :-) ]
Great, many developers don't appreciate their respective (dis)advantages and don't properly use them both, together.
Quote:
Yup, do-able. The 50% opacity is simply a quad of screen dimensions with an alpha of 0.5 placed upon the near frustum face. The copyright display could simply be another HUD instance. Rendering order per frame is then :
- generic 3D scene ( 'solarsystem' in my case )
- specific 3D scene ( FermiLAT or radiotelescopes or IFOs in my schema )
- generic HUD
- specific HUD ( depending on WU, power spectrums, whatever )
- opacity layer
- generic copyright HUD
- specific copyright HUD
Exactly.
Quote:
Now in my HUD scheme you could alter text in two ways (a) remove/insert entire 'HUDTextLine' objects from their containers or, even more simply (b) edit the HUDTextLine's content 'in place' via HUDTextLine::setText() and/or HUDTextLine::getText(). The second option uses std::string objects and hence is subject to whatever you want there : so for example, read the current text value, edit it, and re-insert. I've got these things to 'automagically' resize themselves upon alterations AND signal their enclosing container ( if any ) to reassess it's own sizing - onwards and upwards in a containment hierarchy. So - but depending upon constraints from other contained items - a small text change could cause an entire HUD to re-adjust itself. Where/when you do these text manipulations in some other code structure is a separate issue, provided you have a way to disclose the correct pointers! :-)
Let's start with a simple approach, keeping in mind potential future extensions (as always).
Quote:
Note for others : make your z-order absolute range as small as reasonable to work because the z-buffer has a fixed underlying representation. Meaning that you only get a certain 'granularity', and the deeper your clipping range then the 'z quanta' are larger - so that potentially more distinct objects will be judged as equidistant for z-order purposes. That issue is disclosed with flickering/occultation of adjacent elements with slight changes in viewing position, as the OpenGL machine tries to decide which to place in front of the other.
Is this still the case nowadays, having 32 bit (quantized?) z-buffers?
Eugenic? WTF? Safari's auto-correcttion... That should read generic of course...
Well I thought you meant eugenic in the meaning of "having good inheritable characteristics" so that might fit. LOL. :=}
Quote:
Great, many developers don't appreciate their respective (dis)advantages and don't properly use them both, together.
Well, let's see if I can pull it off! :-0
Quote:
Let's start with a simple approach, keeping in mind potential future extensions (as always).
Yup, the KISS approach ( Keep It Simple, Stupid ! ) :-0
Quote:
Is this still the case nowadays, having 32 bit (quantized?) z-buffers?
Right, perhaps not common now. But, you never quite know what the target implementation will provide. So it's a guideline I've read about, and probably depends upon how backwards friendly you want to be. I researched that aspect a bit, after assuming the wide spectrum of performance in ( E@H crunching ) platforms worldwide that the software might end up running on. I could, of course, be solving a non-problem .... :-) :-)
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
So it's a guideline I've read about, and probably depends upon how backwards friendly you want to be. I researched that aspect a bit, after assuming the wide spectrum of performance in ( E@H crunching ) platforms worldwide that the software might end up running on.
Shame on me that didn't find the time to look at your latest code.
You have bigger fish to fry. Catch as catch can. :-)
Ooops! I haven't updated the repo for a while, I've been waiting for my implementation to settle out. I'll do that ASAP.
Having in mind the prospective integration of your code into the main codebase, have you also followed the existing (implicit) inline documentation convention (doxygen) so far?
Having in mind the prospective integration of your code into the main codebase, have you also followed the existing (implicit) inline documentation convention (doxygen) so far?
Yes indeed. My comments will likely need bit of a clean up for clarity to others, as I've only been making notes to myself so far, but I've followed the existing pattern of usage - brief/param/return/addtogroup/see/author etc tagging, the triple forward-slash comment, @{ and @} bracketing et al. I've also fairly cleanly relegated interface/usage comments to the header files, and implementation comments to the cpp's .... :-)
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
Here's a significant 'trap' I discovered several weeks ago, but didn't get around to reporting here. A potential side effect of OGLFT use.
- several of the OGFLT functions use the OpenGL glDrawPixels() command in their implementation. Which is fine. It does a quick transfer from a client side pixel map straight into the display buffer, bypassing all manner of OpenGL machinations including transforms. All you really need to use it is either raster or window position information and a pixel source.
- glDrawPixels() is a type of OpenGL command that 'pulls the trigger' but has state machine setup commands that define it's behaviour when executed. For this function those commands are :
- however if you do, as I did, make use of glDrawPixels() for rendering images then one can accept the default behaviours inherent in glDrawPixels() and it's four setup routines. This is also fine.
- but if you, per frame, write an OGLFT string AND perform a pixel map transfer using glDrawPixels() then one could ( as I did ) lose the default settings for said transfer. This showed up in my case of image rendering alone or OGLFT text rendering alone performing fine, but weird stuff happening ( specifically odd pixel patterns and failure to resize properly ) when both were active.
Solutions? I suggest either :
(a) Continue to use glDrawPixels() but explicitly (re)set it's behaviour with those setup commands PER FRAME RENDER, or
(b) Use some other pixel map rendering method.
I chose (b) by adapting good working code I already have for rendering images textured onto OpenGL primitive shapes. Use GL_QUADS say for a rectangular pixel map.
Now the OGLFT documents do mention their use of glDrawPixels(), but one may not be aware of the setup aspect ie. those other 4 routines.
More general lessons :
- OpenGL is a state machine which means that it remembers settings b/w calls to it. It won't 'know' who is telling it what and only responds to the totality of all state instructions extant at a given point in program execution.
- there are many other OpenGL instruction groups which have a similiar 'setup, then fire' aspect. So learn the group, not just the final rendering act.
Cheers, Mike.
( edit ) More explicitly : I deduce that OGLFT does not restore state ( via glPixelStore(), glPixelTransfer(), glPixelMap(), glPixelZoom() ) after any font render. My examination of OGLFT.cpp confirms this. The framework code touches this once only in the AbstractGraphicsEngine's initialize() routine : [pre]// more font setup and optimizations
glPixelStorei( GL_UNPACK_ALIGNMENT, 1 );[/pre]
and I highly recommend leaving it at that ( KISS ).
Also note that glPixelStore() will generate an error if used within a display list.
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, herewith the keybindings that ought cover PC/Linux/Mac :
... for the soon to be released test version. The 'craft rotation' key commands have been duplicated to account for the presence/absence of a numeric keypad. There are keybindings/functionality in the code that I've inactivated because I haven't fully tested same, to my satisfaction.
The idea is that the view on the screen is from within a craft flying around as you please in space. Initially you sit with the Earth beneath you ( ie. out of view ) and you're looking towards the First Point of Aries, being the zero of celestial longitude or right ascension. The simulation is Earth-centric meaning that it sits in the centre of space, the Sun moves around it. The celestial sphere is an 'imaginary' construct, but for our purposes think of it like a sphere a long way away from Earth with the stars etc stuck on it. With this program you can actually go up and inspect the sphere, and even go outside it a bit. The real universe is not like this of course, but we use the sphere idea to assign the directions of objects from Earth's point of view. The grid markings are much like longitude and latitude on Earth, so the north and south celestial poles are given latitude or declination values of plus 90 degrees and minus 90 degrees respectively, while the celestial equator is a circle around the middle. Since there is 24 hours in a day, then for mainly historical reasons the longitude on the celestial sphere is marked in 'hours of right ascension'. Basically one hour of right ascension is 15 degrees, so 24 of those = 360 degrees or a full circle. The Earth rotates with respect to the celestial sphere - I have set it to do so, but not in 'real time' as this is just a demo.
You'll be prevented from going inside the Earth or Sun, or wandering off to infinity as well. The simulation will punt you appropriately. The main thing to remember is that in space you will keep going until you're stopped, so the set of keys for 'thrust', say, add to your existing velocity in space. The 'rotation' commands add to your existing rotation. There are keys for stopping rotation ( '5' or 'L' ), movement ( 'D' ) or both ( 'SPACEBAR' ). If you want to return to the initial position nearby Earth hit 'G'.
Thrust commands like 'left thrust', 'upwards thrust' etc refer to the directions from your viewpoint at the moment you issue the command. So 'upwards' is toward the top of the screen, 'left' is towards the left edge, 'forwards' is directly where you're looking etc.
Commands like 'pitch', 'roll' and 'yaw' invoke rotations regardless of your movement through space.
My strong suggestion is to trial these commands each by themselves, after you have stopped all movement/rotation ( 'SPACEBAR' ). If things get out of control, and they probably will to begin with, just go home ( 'G' ). In no time at all you'll learn what Galileo et al meant by 'inertia' ..... :-) :-)
Now the function keys 'cycle' viewing choices for various visual elements. For pulsars and supernovae this is just 'on' and 'off', but for the celestial sphere grid and the constellations you proceed through combinations of features. Hence if you keep pressing F5 you will keep going around the options for constellation information [ ALL_OFF, STARS, STARS_N_LINKS, STARS_N_NAMES, ALL_ON ]. Give it a go and you'll soon see.
The HUD is a demo of some basic functionality, and should behave itself upon window resize ( crosses fingers .... ), though I have found some driver dependent issues. The HUD will not display if the window is shrunk too small.
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
Confession : I haven't been able to achieve a win32 build using the existing framework. I've been chewing on this bone for months, but now as I want an actual win32 executable of SolarSystem, then the rubber needs to meet the road. :-) :-)
- I've tracked this down to the segment of the script x86-mingw32-build.sh that creates the win32api library/headers for MinGW. This errors out with complaints of re-definition of the select function, plus the timeval and fd_set structures. Apparently this is an issue with the order of includes b/w winsock2.h and other headers ( eg. select.h, time.h, types.h ) brought into the preprocessor phase of a compile session by having windows.h mentioned first. There are a gazillion threads in support forums out there relating much the same story with MinGW builds or usage, in all manner of scenarios .....
[ winsock2.h includes windows.h, winsock2.h prevents inclusion of winsock.h, windows.h includes EITHER winsock2.h OR winsock.h depending upon other build switch combinations .... ]
- My research also indicates there is a more basic problem of incompatibility b/w winsock.h and winsock2.h. Hence a variety of include guard mechanisms in place due to that. The upshot is that if winsock2.h is included b/4 windows.h then the problem ought resolve.
[ what would be even better is if MS would resolve that dependency ... but this is a Linux issue, right? ]
- However I don't have control over that, as I didn't write the downloaded scripts nor want to stuff about with them too much.
- I have tried ( on occasions by altering the patch which is applied to x86-mingw32-build.sh.conf in $ROOT/3rdparty/mingw/xscripts ... ), and failed by :
(a) Adding -D__USE_W32_SOCKETS to the gcc command line
(b) Adding -include winsock2.h to the gcc command line ( allegedly this forces inclusion to "the first line of the primary source file", but not it seems as the first header that gcc encounters )
(c) Fiddling and fudging with the aforementioned headers ( don't ask ... )
(d) Tearing own hair out
(e) All of the above at once
Now I could have this compile time problem go away with, say, -D_WINSOCK2API_ and/or -D_WINSOCKAPI_ ( preventing header inclusion ). However would we not then lose networking support within any library later used for an application cross-build? I'd assume that at least BOINC code would have an interest in that. Is WIN32_LEAN_AND_MEAN relevant, and do we want that anyway?
Suggestions ? ;-}
Cheers, Mike.
( edit ) One extraordinary solution occurs to me, during delusional phases of febrile spasms, is to edit all of the headers used in the MingGW win32api build - ie. within the relevant downloaded *tar.gz in $ROOT/3rdparty/mingw/packages - to include another yet-to-be-written header ( that resolves the ordering dilemma ) on their first processed lines. Not elegant/portable/persistent by a longshot but hey, a tarpit is a tarpit .... all I want is idempotence !! :-)
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
(b) Adding -include winsock2.h to the gcc command line ( allegedly this forces inclusion to "the first line of the primary source file", but not it seems as the first header that gcc encounters )
Suggestions ? ;-}
Cheers, Mike.
I've used the Cygwin version of gcc enough to know that the order of items you place in the command line matters, and also that there is a long list of options for telling it to do only some of the compilation steps.
Could it be forcing the inclusion of more than one header file to the first line of the primary source file, and not in the order you want?
RE: RE: We could even
)
Eugenic? WTF? Safari's auto-correcttion... That should read generic of course...
Great, many developers don't appreciate their respective (dis)advantages and don't properly use them both, together.
Exactly.
Let's start with a simple approach, keeping in mind potential future extensions (as always).
Is this still the case nowadays, having 32 bit (quantized?) z-buffers?
Nice!
Oliver
Einstein@Home Project
RE: Eugenic? WTF? Safari's
)
Well I thought you meant eugenic in the meaning of "having good inheritable characteristics" so that might fit. LOL. :=}
Well, let's see if I can pull it off! :-0
Yup, the KISS approach ( Keep It Simple, Stupid ! ) :-0
Right, perhaps not common now. But, you never quite know what the target implementation will provide. So it's a guideline I've read about, and probably depends upon how backwards friendly you want to be. I researched that aspect a bit, after assuming the wide spectrum of performance in ( E@H crunching ) platforms worldwide that the software might end up running on. I could, of course, be solving a non-problem .... :-) :-)
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: So it's a guideline
)
Agreed, a standing goal of ours.
Oliver
Einstein@Home Project
RE: RE: Shame on me that
)
Having in mind the prospective integration of your code into the main codebase, have you also followed the existing (implicit) inline documentation convention (doxygen) so far?
Thanks,
Oliver
Einstein@Home Project
RE: Having in mind the
)
Yes indeed. My comments will likely need bit of a clean up for clarity to others, as I've only been making notes to myself so far, but I've followed the existing pattern of usage - brief/param/return/addtogroup/see/author etc tagging, the triple forward-slash comment, @{ and @} bracketing et al. I've also fairly cleanly relegated interface/usage comments to the header files, and implementation comments to the cpp's .... :-)
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
Great! Highly
)
Great! Highly appreciated!
Thanks,
Oliver
Einstein@Home Project
Here's a significant 'trap' I
)
Here's a significant 'trap' I discovered several weeks ago, but didn't get around to reporting here. A potential side effect of OGLFT use.
- several of the OGFLT functions use the OpenGL glDrawPixels() command in their implementation. Which is fine. It does a quick transfer from a client side pixel map straight into the display buffer, bypassing all manner of OpenGL machinations including transforms. All you really need to use it is either raster or window position information and a pixel source.
- glDrawPixels() is a type of OpenGL command that 'pulls the trigger' but has state machine setup commands that define it's behaviour when executed. For this function those commands are :
glPixelStore()
glPixelTransfer()
glPixelMap()
glPixelZoom()
... which is also fine.
- however if you do, as I did, make use of glDrawPixels() for rendering images then one can accept the default behaviours inherent in glDrawPixels() and it's four setup routines. This is also fine.
- but if you, per frame, write an OGLFT string AND perform a pixel map transfer using glDrawPixels() then one could ( as I did ) lose the default settings for said transfer. This showed up in my case of image rendering alone or OGLFT text rendering alone performing fine, but weird stuff happening ( specifically odd pixel patterns and failure to resize properly ) when both were active.
Solutions? I suggest either :
(a) Continue to use glDrawPixels() but explicitly (re)set it's behaviour with those setup commands PER FRAME RENDER, or
(b) Use some other pixel map rendering method.
I chose (b) by adapting good working code I already have for rendering images textured onto OpenGL primitive shapes. Use GL_QUADS say for a rectangular pixel map.
Now the OGLFT documents do mention their use of glDrawPixels(), but one may not be aware of the setup aspect ie. those other 4 routines.
More general lessons :
- OpenGL is a state machine which means that it remembers settings b/w calls to it. It won't 'know' who is telling it what and only responds to the totality of all state instructions extant at a given point in program execution.
- there are many other OpenGL instruction groups which have a similiar 'setup, then fire' aspect. So learn the group, not just the final rendering act.
Cheers, Mike.
( edit ) More explicitly : I deduce that OGLFT does not restore state ( via glPixelStore(), glPixelTransfer(), glPixelMap(), glPixelZoom() ) after any font render. My examination of OGLFT.cpp confirms this. The framework code touches this once only in the AbstractGraphicsEngine's initialize() routine :
[pre]// more font setup and optimizations
glPixelStorei( GL_UNPACK_ALIGNMENT, 1 );[/pre]
and I highly recommend leaving it at that ( KISS ).
Also note that glPixelStore() will generate an error if used within a display list.
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, herewith the keybindings
)
OK, herewith the keybindings that ought cover PC/Linux/Mac :
... for the soon to be released test version. The 'craft rotation' key commands have been duplicated to account for the presence/absence of a numeric keypad. There are keybindings/functionality in the code that I've inactivated because I haven't fully tested same, to my satisfaction.
The idea is that the view on the screen is from within a craft flying around as you please in space. Initially you sit with the Earth beneath you ( ie. out of view ) and you're looking towards the First Point of Aries, being the zero of celestial longitude or right ascension. The simulation is Earth-centric meaning that it sits in the centre of space, the Sun moves around it. The celestial sphere is an 'imaginary' construct, but for our purposes think of it like a sphere a long way away from Earth with the stars etc stuck on it. With this program you can actually go up and inspect the sphere, and even go outside it a bit. The real universe is not like this of course, but we use the sphere idea to assign the directions of objects from Earth's point of view. The grid markings are much like longitude and latitude on Earth, so the north and south celestial poles are given latitude or declination values of plus 90 degrees and minus 90 degrees respectively, while the celestial equator is a circle around the middle. Since there is 24 hours in a day, then for mainly historical reasons the longitude on the celestial sphere is marked in 'hours of right ascension'. Basically one hour of right ascension is 15 degrees, so 24 of those = 360 degrees or a full circle. The Earth rotates with respect to the celestial sphere - I have set it to do so, but not in 'real time' as this is just a demo.
You'll be prevented from going inside the Earth or Sun, or wandering off to infinity as well. The simulation will punt you appropriately. The main thing to remember is that in space you will keep going until you're stopped, so the set of keys for 'thrust', say, add to your existing velocity in space. The 'rotation' commands add to your existing rotation. There are keys for stopping rotation ( '5' or 'L' ), movement ( 'D' ) or both ( 'SPACEBAR' ). If you want to return to the initial position nearby Earth hit 'G'.
Thrust commands like 'left thrust', 'upwards thrust' etc refer to the directions from your viewpoint at the moment you issue the command. So 'upwards' is toward the top of the screen, 'left' is towards the left edge, 'forwards' is directly where you're looking etc.
Commands like 'pitch', 'roll' and 'yaw' invoke rotations regardless of your movement through space.
My strong suggestion is to trial these commands each by themselves, after you have stopped all movement/rotation ( 'SPACEBAR' ). If things get out of control, and they probably will to begin with, just go home ( 'G' ). In no time at all you'll learn what Galileo et al meant by 'inertia' ..... :-) :-)
Now the function keys 'cycle' viewing choices for various visual elements. For pulsars and supernovae this is just 'on' and 'off', but for the celestial sphere grid and the constellations you proceed through combinations of features. Hence if you keep pressing F5 you will keep going around the options for constellation information [ ALL_OFF, STARS, STARS_N_LINKS, STARS_N_NAMES, ALL_ON ]. Give it a go and you'll soon see.
The HUD is a demo of some basic functionality, and should behave itself upon window resize ( crosses fingers .... ), though I have found some driver dependent issues. The HUD will not display if the window is shrunk too small.
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
Confession : I haven't been
)
Confession : I haven't been able to achieve a win32 build using the existing framework. I've been chewing on this bone for months, but now as I want an actual win32 executable of SolarSystem, then the rubber needs to meet the road. :-) :-)
- I've tracked this down to the segment of the script x86-mingw32-build.sh that creates the win32api library/headers for MinGW. This errors out with complaints of re-definition of the select function, plus the timeval and fd_set structures. Apparently this is an issue with the order of includes b/w winsock2.h and other headers ( eg. select.h, time.h, types.h ) brought into the preprocessor phase of a compile session by having windows.h mentioned first. There are a gazillion threads in support forums out there relating much the same story with MinGW builds or usage, in all manner of scenarios .....
[ winsock2.h includes windows.h, winsock2.h prevents inclusion of winsock.h, windows.h includes EITHER winsock2.h OR winsock.h depending upon other build switch combinations .... ]
- My research also indicates there is a more basic problem of incompatibility b/w winsock.h and winsock2.h. Hence a variety of include guard mechanisms in place due to that. The upshot is that if winsock2.h is included b/4 windows.h then the problem ought resolve.
[ what would be even better is if MS would resolve that dependency ... but this is a Linux issue, right? ]
- However I don't have control over that, as I didn't write the downloaded scripts nor want to stuff about with them too much.
- I have tried ( on occasions by altering the patch which is applied to x86-mingw32-build.sh.conf in $ROOT/3rdparty/mingw/xscripts ... ), and failed by :
(a) Adding -D__USE_W32_SOCKETS to the gcc command line
(b) Adding -include winsock2.h to the gcc command line ( allegedly this forces inclusion to "the first line of the primary source file", but not it seems as the first header that gcc encounters )
(c) Fiddling and fudging with the aforementioned headers ( don't ask ... )
(d) Tearing own hair out
(e) All of the above at once
Now I could have this compile time problem go away with, say, -D_WINSOCK2API_ and/or -D_WINSOCKAPI_ ( preventing header inclusion ). However would we not then lose networking support within any library later used for an application cross-build? I'd assume that at least BOINC code would have an interest in that. Is WIN32_LEAN_AND_MEAN relevant, and do we want that anyway?
Suggestions ? ;-}
Cheers, Mike.
( edit ) One extraordinary solution occurs to me, during delusional phases of febrile spasms, is to edit all of the headers used in the MingGW win32api build - ie. within the relevant downloaded *tar.gz in $ROOT/3rdparty/mingw/packages - to include another yet-to-be-written header ( that resolves the ordering dilemma ) on their first processed lines. Not elegant/portable/persistent by a longshot but hey, a tarpit is a tarpit .... all I want is idempotence !! :-)
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: (b) Adding -include
)
I've used the Cygwin version of gcc enough to know that the order of items you place in the command line matters, and also that there is a long list of options for telling it to do only some of the compilation steps.
Could it be forcing the inclusion of more than one header file to the first line of the primary source file, and not in the order you want?