( edit ) The especial reason for fiddling with winding senses and faces is to instruct OpenGL to apply the texture to only one side - we don't need an expensive pasting of a pattern to the inside of the Earth, do we ?? :-)
Just a hint, on a related note: backface culling
Oliver
Absolutely right! I needed to make sure I got the correct faces as back and front - particularly since I'm winding a fan of triangles around each of the poles. The weird thing is one can look straight through a polygon from one side - quite transparent & literally invisible - but have a completely opaque texture in view when looking at the other side of the same polygon! I won't be doing it, but apparently that's a trick to use when doing 'cutaway' diagrams etc ..... :-)
The other thing I've learnt is that to paste a texture right around the globe properly one has to duplicate some vertices - with regard to their position coordinates - along the curve where opposite sides of the texture meet. Thus a vertex along say, the Greenwich meridian, is listed once at the beginning of a traverse around a latitudinal band and then again at the end. The first is given a texture coordinate of 0.0 and the second 1.0, hence in this instance geometrically identifying the one 3D point with the left and right edges of the texture pixel map. Otherwise the section between the penultimate vertex on the latitudinal band and the first on that band won't render well. Essentially OpenGL doesn't actually 'know' what you want, so the trickiest part of the programming - even with good texts at hand - is to learn the true semantics of the API calls by experiment.
What fun ! :-)
Cheers, Mike.
( edit ) So to be quite exact about definitions : a 'vertex' has several qualities : position co-ordinates, texture co-ordinates, and a normal vector ( at least ). So by distinguishing the texture coordinates at the one 3D position I strictly have two distinct vertices .... I have written a 'Vertex' class for precisely this reason.
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
Also of interest is the number of dimensions of vertex attributes. Usually we'd expect that for vectors - but textures can have dimensions too. A 1D texture is a 'stipple' along a curve, whereas a 3D texture paints a volume. A 3D texture application is in essence a mapping/function from a 'color space' to a 'position space'.
Also I've found a better visual result by only using triangles to approximate a spherical shape ( staggering the vertex positions in longitude from one latitude to the next ) rather than using quadrilaterals. An especial point is that OpenGL only guarantees proper rendering of 2D textures on precisely planar polygons. With a set of four vertices one may lie off the plane formed using the other three, but with a triangle's three vertices always defining the plane none will ever lie off it. This can reduce the chances ( other aspects are involved ) of evident seams and gaps and similiar unintended artifacts.
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
FWIW I have ( and properly implemented this time after some research into the topic of repositories ) a new git repo, with updated content reflecting the current status of my coding. There will be errors and incomplete aspects - work in progress obviously - but it's there warts and all if you go to :
..... which I will regularly update, though many commits will probably be 'fluffy' issues like commenting and presentation for 3rd party comprehension. Many of the base classes I've constructed are as firm as they'll ever be in the 'logic of the programming' sense. It's basically an image of the 'src' directory and sub-directories thereof that you would begin with if one downloaded the official build system and thence enacted changes that fire off in the direction I'm going.
I've included the 'build.sh' script ( which isn't meant to be placed in the 'src' sub-tree but in the project's root directory ) that I use on my Ubuntu machine. Note that each directory below 'src' has it's own makefile(s) which require some degree of alteration from original, though especially the one within 'src/solarsystem'. Later I'll put in the image file(s) that the texture map(s) is/are derived from, these are meant to be placed in whatever directory the final executable is placed - for it's use when running - currently that is 'INSERT_YOUR_PROJECT_ROOT_DIRECTORY_HERE/dist' .....
I tried to abstract the build system into 'CMake' format which was generally OK, but alas the semantics didn't always translate correctly ( and/or I stuffed it up ) so I've reverted to the existing script driven route. Never mind ...
I've never done a project of this size before, thus I have found that implementing ( in a state machine paradigm like OpenGL ) often involves revelations both good and bad that lead to code improvement. Most of my errors are not of C++ syntax and language rules but that of not getting what one intended ( the usual misplaced colons etc of course ). One learns, but I'm getting closure. Iterate and iterate again .... :-) :-)
Cheers, Mike.
( edit ) So I guess the repo can stand as the mechanism by which I can satisfy the GNU General Public License Version 2 requirement of publishing the code with the executable(s).
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
FWIW I have ( and properly implemented this time after some research into the topic of repositories ) a new git repo, with updated content reflecting the current status of my coding. There will be errors and incomplete aspects - work in progress obviously - but it's there warts and all if you go to :
Your repo appears to be completely decoupled from the official one. Is this intentional? Since you're using git it would be great if your repo would be a fork of the official one with your changes added on top of it (in master or a dedicated branch). This way it would be much easier to collaborate on this (if that's ok with you) since the repo would still be coupled and we can exchange updates/commits very easily. Eventually your work could become part of an official E@H release :-)
Your repo appears to be completely decoupled from the official one. Is this intentional?
Yes, I thought that was the way to do it ? :-)
Quote:
Since you're using git it would be great if your repo would be a fork of the official one with your changes added on top of it (in master or a dedicated branch).
OK, I'll work that out ( fork a branch seems best ) and reset matters.
Quote:
This way it would be much easier to collaborate on this (if that's ok with you)
No probs, that's always been the intention ..... volunteers out there? Mind you since I haven't really released much to look at and play with, no one else knows what I'm aiming at. My 'design document' is in my head. I ought write at least a high level spec. Perhaps I should just throw out my 'play' version for comment.
Quote:
since the repo would still be coupled and we can exchange updates/commits very easily. Eventually your work could become part of an official E@H release :-)
Cool !! :-)
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
- keyboard bindings 'key_bindings.txt' ( NB press ESC to exit program )
- a linux version 'solarsystem_linux_001' in the 'releases' directory to play with.
- download the 'worldmap.bmp' along with executable to the same directory.
- I'm fixing the problem with the south pole! :-)
- suggest you print out the keyboard bindings file as a cheat sheet. The key positions are close together on the left side of a QWERTY and if you play 1st person shooters the bindings are similiar for viewpoint control.
- it'll take a while to get used to manouevring the craft. Well it did for me and I wrote it ! It has alot of similarity will 'real' spacecraft behaviour. There's no air resistance in space so generally what is happening keeps happening. Translations occur until you stop them, but rotations occur in increments. To keep handling 'simple' I don't require the user to counter-control rotations to stop them. Probably need to fine tune some settings ie. the magnitude of the translational thrusts and degrees of rotation. Please advise ...... :-)
- if it falls over for any reasons, please let me know ( here in this thread ). There's a 'solarsystem_stderr.txt' file written into whatever directory you're running within. If the failure is not too catastrophic the file will be readable ( I'm working on a more bullet proof method of file opening and closure to retain readability in worst case ). In theory that may contain information leading up to the problem : this is my debug outlet from within the code, and has referencing to specific lines of code.
Cheers, Mike.
( edit ) Oh, and 'solarsystem_stderr.txt' will be appended to from invocation to invocation. It only deletes if you do that. I will change this later so it starts empty afresh each time you run the program .....
( edit ) Whoops, don't download the executable and bitmap yet .... I'll give alternate links shortly .... :-)
( edit ) Sorry 'bout that. GitHub will upload fine, but problematic to simply download. So try from these :
Nope. Git is meant for distributed SCM, hence you usually clone (fork) a publicly available repository you want to use as a basis for your developments. You can then either publish that forked repo yourself or you send your patches to upstream. This way all repo incarnations will stay coherent and merges (integrate stuff upstream) and updates (incorporate changes from upstream) are a piece of cake.
Quote:
OK, I'll work that out ( fork a branch seems best ) and reset matters.
Let me know if you need help with this!
The usual steps are:
1) clone our repo from git://git.aei.uni-hannover.de/shared/einsteinathome/graphicsframework.git
2) create a new branch based on master: git checkout -b mikesbest
3) move over your changes and commit them (try to do small atomic commits)
4) Push your repo to github (all branches)
Nope. Git is meant for distributed SCM, hence you usually clone (fork) a publicly available repository you want to use as a basis for your developments. You can then either publish that forked repo yourself or you send your patches to upstream. This way all repo incarnations will stay coherent and merges (integrate stuff upstream) and updates (incorporate changes from upstream) are a piece of cake.
Quote:
OK, I'll work that out ( fork a branch seems best ) and reset matters.
Let me know if you need help with this!
The usual steps are:
1) clone our repo from git://git.aei.uni-hannover.de/shared/einsteinathome/graphicsframework.git
2) create a new branch based on master: git checkout -b mikesbest
3) move over your changes and commit them (try to do small atomic commits)
4) Push your repo to github (all branches)
Cheers,
Oliver
Ah, more to learn! :-)
Thanks very much Oliver for your thoughts. I will absorb this and think some more upon it.
[ and yes, it is BOINC emitting that file .... ]
Cheers, Mike.
( edit ) ..... and to be clearer I should have the root of the repo one directory level above where I am now ..... where 'build.sh' resides that is. That script won't work right unless it is there.
( edit ) Aha! SCM = Software Configuration Management
I was just getting to cope with VCS, CVS, RCS, SCCS, SVN, TCL/TK .... where 'git' naturally stands out beautifully! :-)
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
[aside]
SHA1 is interesting. As an 'effectively unique' hash code one can compare object content by comparing the hashes instead. If you like : two files are identical if their SHA1's are numerically equal. So while two objects with the same content will produce the same SHA1 number, there is a vanishingly small chance that two objects with the same SHA1 number will not have the same content. The reason is that our files are of finite size and the hash code/key length is also finite. What goes around will eventually come around.
But for say around 128 bits ( the SHA1 standard is 160 bits, but in practice may be truncated ) 'vanishingly small' is the reciprocal of some 'astronomical' number - like the number of atoms in the galaxy or somesuch. Meaning that the likelihood of git failing to correctly distinguish two actually different files because it depended upon SHA1 uniqueness is going to take a million or three years to get to 50:50 odds of a single mistake over that timescale.
As they in Babe - "that'll do pig" :-)
[/aside]
Cheers, Mike.
( edit ) Or Woody Allen : "Infinity is a very long time, especially towards the end."
( edit ) I bring this up as I was wondering how/why git can quickly compare file versions across the internet without apparently doing a direct upload/download to byte-level compare .... just deal with hashes instead. At the merest of bandwidth use. It also explains all those long funny looking hexadecimal numbers hanging around the repo .... they are SHA1 hash codes! :-) :-)
( edit ) BTW : the slightest possible change that could be made to some given object's content WILL produce a different SHA1 value. Identical SHA1 codes can only be produced from either precisely identical OR radically different object content with very very many atomic steps separating. This adds value to the management process as object content is typically related/derived/inherited, so the chances are even lower again that git will mistake an 'ancestor' for a 'descendant'. Chaos aficionados will herewith recognise Mitchell Feigenbaum and/or Poincare and the liquorice folding problem ....
( edit ) so especially git tracks content, not the file name, not the file's location etc but what it contains. Most other RCS's don't do that. File and directory names are secondary associations. For git usage the hash becomes the file's effective 'name'.
( edit ) I'm reading 'Version Control With Git' - Jon Loeliger, O'Reilly Press. Best so far :
Quote:
The typical user view of a file — that it has revisions and appears to progress from one revision to another revision — is simply an artifact. Git computes this history as a set of changes between different blobs with varying hashes, rather than storing a filename and set of differences directly.
A blob is a 'binary large object' which, apart from the computed hash, is an opaque object for git purposes.
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: RE: ( edit ) The
)
Absolutely right! I needed to make sure I got the correct faces as back and front - particularly since I'm winding a fan of triangles around each of the poles. The weird thing is one can look straight through a polygon from one side - quite transparent & literally invisible - but have a completely opaque texture in view when looking at the other side of the same polygon! I won't be doing it, but apparently that's a trick to use when doing 'cutaway' diagrams etc ..... :-)
The other thing I've learnt is that to paste a texture right around the globe properly one has to duplicate some vertices - with regard to their position coordinates - along the curve where opposite sides of the texture meet. Thus a vertex along say, the Greenwich meridian, is listed once at the beginning of a traverse around a latitudinal band and then again at the end. The first is given a texture coordinate of 0.0 and the second 1.0, hence in this instance geometrically identifying the one 3D point with the left and right edges of the texture pixel map. Otherwise the section between the penultimate vertex on the latitudinal band and the first on that band won't render well. Essentially OpenGL doesn't actually 'know' what you want, so the trickiest part of the programming - even with good texts at hand - is to learn the true semantics of the API calls by experiment.
What fun ! :-)
Cheers, Mike.
( edit ) So to be quite exact about definitions : a 'vertex' has several qualities : position co-ordinates, texture co-ordinates, and a normal vector ( at least ). So by distinguishing the texture coordinates at the one 3D position I strictly have two distinct vertices .... I have written a 'Vertex' class for precisely this reason.
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
Also of interest is the
)
Also of interest is the number of dimensions of vertex attributes. Usually we'd expect that for vectors - but textures can have dimensions too. A 1D texture is a 'stipple' along a curve, whereas a 3D texture paints a volume. A 3D texture application is in essence a mapping/function from a 'color space' to a 'position space'.
Also I've found a better visual result by only using triangles to approximate a spherical shape ( staggering the vertex positions in longitude from one latitude to the next ) rather than using quadrilaterals. An especial point is that OpenGL only guarantees proper rendering of 2D textures on precisely planar polygons. With a set of four vertices one may lie off the plane formed using the other three, but with a triangle's three vertices always defining the plane none will ever lie off it. This can reduce the chances ( other aspects are involved ) of evident seams and gaps and similiar unintended artifacts.
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
FWIW I have ( and properly
)
FWIW I have ( and properly implemented this time after some research into the topic of repositories ) a new git repo, with updated content reflecting the current status of my coding. There will be errors and incomplete aspects - work in progress obviously - but it's there warts and all if you go to :
https://github.com/hewsmike/Einstein-At-Home-Screensaver
..... which I will regularly update, though many commits will probably be 'fluffy' issues like commenting and presentation for 3rd party comprehension. Many of the base classes I've constructed are as firm as they'll ever be in the 'logic of the programming' sense. It's basically an image of the 'src' directory and sub-directories thereof that you would begin with if one downloaded the official build system and thence enacted changes that fire off in the direction I'm going.
I've included the 'build.sh' script ( which isn't meant to be placed in the 'src' sub-tree but in the project's root directory ) that I use on my Ubuntu machine. Note that each directory below 'src' has it's own makefile(s) which require some degree of alteration from original, though especially the one within 'src/solarsystem'. Later I'll put in the image file(s) that the texture map(s) is/are derived from, these are meant to be placed in whatever directory the final executable is placed - for it's use when running - currently that is 'INSERT_YOUR_PROJECT_ROOT_DIRECTORY_HERE/dist' .....
I tried to abstract the build system into 'CMake' format which was generally OK, but alas the semantics didn't always translate correctly ( and/or I stuffed it up ) so I've reverted to the existing script driven route. Never mind ...
I've never done a project of this size before, thus I have found that implementing ( in a state machine paradigm like OpenGL ) often involves revelations both good and bad that lead to code improvement. Most of my errors are not of C++ syntax and language rules but that of not getting what one intended ( the usual misplaced colons etc of course ). One learns, but I'm getting closure. Iterate and iterate again .... :-) :-)
Cheers, Mike.
( edit ) So I guess the repo can stand as the mechanism by which I can satisfy the GNU General Public License Version 2 requirement of publishing the code with the executable(s).
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: FWIW I have ( and
)
Nice one, I'm already watching it on GitHub!
Your repo appears to be completely decoupled from the official one. Is this intentional? Since you're using git it would be great if your repo would be a fork of the official one with your changes added on top of it (in master or a dedicated branch). This way it would be much easier to collaborate on this (if that's ok with you) since the repo would still be coupled and we can exchange updates/commits very easily. Eventually your work could become part of an official E@H release :-)
Cheers,
Oliver
Einstein@Home Project
RE: Your repo appears to be
)
Yes, I thought that was the way to do it ? :-)
OK, I'll work that out ( fork a branch seems best ) and reset matters.
No probs, that's always been the intention ..... volunteers out there? Mind you since I haven't really released much to look at and play with, no one else knows what I'm aiming at. My 'design document' is in my head. I ought write at least a high level spec. Perhaps I should just throw out my 'play' version for comment.
Cool !! :-)
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
Have committed to GitHub :
)
Have committed to GitHub :
- a rough design statement 'design_ideas.txt'
- keyboard bindings 'key_bindings.txt' ( NB press ESC to exit program )
- a linux version 'solarsystem_linux_001' in the 'releases' directory to play with.
- download the 'worldmap.bmp' along with executable to the same directory.
- I'm fixing the problem with the south pole! :-)
- suggest you print out the keyboard bindings file as a cheat sheet. The key positions are close together on the left side of a QWERTY and if you play 1st person shooters the bindings are similiar for viewpoint control.
- it'll take a while to get used to manouevring the craft. Well it did for me and I wrote it ! It has alot of similarity will 'real' spacecraft behaviour. There's no air resistance in space so generally what is happening keeps happening. Translations occur until you stop them, but rotations occur in increments. To keep handling 'simple' I don't require the user to counter-control rotations to stop them. Probably need to fine tune some settings ie. the magnitude of the translational thrusts and degrees of rotation. Please advise ...... :-)
- if it falls over for any reasons, please let me know ( here in this thread ). There's a 'solarsystem_stderr.txt' file written into whatever directory you're running within. If the failure is not too catastrophic the file will be readable ( I'm working on a more bullet proof method of file opening and closure to retain readability in worst case ). In theory that may contain information leading up to the problem : this is my debug outlet from within the code, and has referencing to specific lines of code.
Cheers, Mike.
( edit ) Oh, and 'solarsystem_stderr.txt' will be appended to from invocation to invocation. It only deletes if you do that. I will change this later so it starts empty afresh each time you run the program .....
( edit ) Whoops, don't download the executable and bitmap yet .... I'll give alternate links shortly .... :-)
( edit ) Sorry 'bout that. GitHub will upload fine, but problematic to simply download. So try from these :
solarsystem_linux_001
worldmap.bmp
( edit ) There's also a file called 'stderrgfx.txt' also produced, but as a result of framework code not written by me ....
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: ( edit ) There's also a
)
Blame BOINC, not the framework ;-)
Oliver
Einstein@Home Project
RE: Yes, I thought that
)
Nope. Git is meant for distributed SCM, hence you usually clone (fork) a publicly available repository you want to use as a basis for your developments. You can then either publish that forked repo yourself or you send your patches to upstream. This way all repo incarnations will stay coherent and merges (integrate stuff upstream) and updates (incorporate changes from upstream) are a piece of cake.
Let me know if you need help with this!
The usual steps are:
1) clone our repo from git://git.aei.uni-hannover.de/shared/einsteinathome/graphicsframework.git
2) create a new branch based on master: git checkout -b mikesbest
3) move over your changes and commit them (try to do small atomic commits)
4) Push your repo to github (all branches)
Cheers,
Oliver
Einstein@Home Project
RE: RE: Yes, I thought
)
Ah, more to learn! :-)
Thanks very much Oliver for your thoughts. I will absorb this and think some more upon it.
[ and yes, it is BOINC emitting that file .... ]
Cheers, Mike.
( edit ) ..... and to be clearer I should have the root of the repo one directory level above where I am now ..... where 'build.sh' resides that is. That script won't work right unless it is there.
( edit ) Aha! SCM = Software Configuration Management
I was just getting to cope with VCS, CVS, RCS, SCCS, SVN, TCL/TK .... where 'git' naturally stands out beautifully! :-)
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
[aside] SHA1 is interesting.
)
[aside]
SHA1 is interesting. As an 'effectively unique' hash code one can compare object content by comparing the hashes instead. If you like : two files are identical if their SHA1's are numerically equal. So while two objects with the same content will produce the same SHA1 number, there is a vanishingly small chance that two objects with the same SHA1 number will not have the same content. The reason is that our files are of finite size and the hash code/key length is also finite. What goes around will eventually come around.
But for say around 128 bits ( the SHA1 standard is 160 bits, but in practice may be truncated ) 'vanishingly small' is the reciprocal of some 'astronomical' number - like the number of atoms in the galaxy or somesuch. Meaning that the likelihood of git failing to correctly distinguish two actually different files because it depended upon SHA1 uniqueness is going to take a million or three years to get to 50:50 odds of a single mistake over that timescale.
As they in Babe - "that'll do pig" :-)
[/aside]
Cheers, Mike.
( edit ) Or Woody Allen : "Infinity is a very long time, especially towards the end."
( edit ) I bring this up as I was wondering how/why git can quickly compare file versions across the internet without apparently doing a direct upload/download to byte-level compare .... just deal with hashes instead. At the merest of bandwidth use. It also explains all those long funny looking hexadecimal numbers hanging around the repo .... they are SHA1 hash codes! :-) :-)
( edit ) BTW : the slightest possible change that could be made to some given object's content WILL produce a different SHA1 value. Identical SHA1 codes can only be produced from either precisely identical OR radically different object content with very very many atomic steps separating. This adds value to the management process as object content is typically related/derived/inherited, so the chances are even lower again that git will mistake an 'ancestor' for a 'descendant'. Chaos aficionados will herewith recognise Mitchell Feigenbaum and/or Poincare and the liquorice folding problem ....
( edit ) so especially git tracks content, not the file name, not the file's location etc but what it contains. Most other RCS's don't do that. File and directory names are secondary associations. For git usage the hash becomes the file's effective 'name'.
( edit ) I'm reading 'Version Control With Git' - Jon Loeliger, O'Reilly Press. Best so far :
A blob is a 'binary large object' which, apart from the computed hash, is an opaque object for git purposes.
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