From: Georg Z. <geo...@un...> - 2012-09-06 10:27:11
|
Dear Ferdinand, I just built and launched 5592/MinGW/QtCreator/compiled-as-downloaded on Win7-64/i7/NVidia GTX580M (OpenGL4.2.0). Performance here may be even slightly better than the pre-merge trunk (running both in parallel, I have about 55fps vs. 51 fps for similar settings, but both numbers are not stable, so I would say they perform approximately equal). But at least in perspective projection, with a "spherical" landscape, the image corners in wide-angle mode are worse than before. See attached screenshots. The triangles on the corners are extremely blurred. Is there a bug in the texture mapping for clipped triangles? https://dl.dropbox.com/u/30092392/stellarium-11.4.png https://dl.dropbox.com/u/30092392/stellarium-r5592.png Also, in stereographic mode, the tesselation appears to be much coarser, so there are visible straight edges where there were none previously. Compare screenshots: https://dl.dropbox.com/u/30092392/stellarium-11.4b.png https://dl.dropbox.com/u/30092392/stellarium-r5592b.png The metal bars along the horizon are actually an artificial horizon, and should follow the horizon markers. It's a square seen from the inside, so there should be no edges at 90/180°. Here, also the illumination seems to be too bright, the gray concrete is overexposed in the lower left. So much for my first impressions. I will try to make a "release" build for my netbook soon. Do I have to set this in CMakeLists.txt or is there a setting in QtCreator for this? Also, where do I set a 64bit compile? (Is this possible with MinGW?) I guess failing to load star catalog 8 is caused by the 32bit addressing limit. TNX, G. On Do, 6.09.2012, 08:13, Ferdinand Majerech wrote: > There are still performance issues getting fixed. > > Just after 5592 there was another significant improvement > (not yet in trunk): could you test how it compares? > (https://code.launchpad.net/~kiithsacmp/stellarium/glexperiment) (Also describe the load you're getting 4-7FPS with? (just opened Stellarium?) > > Still, those results seem worse than what I'd expect from 5592. > Did you build the release build? Debug build is visibly slower. > (I have ~30FPS -when launched - on an Athlon64 3200+.) > |
From: Ferdinand M. <kii...@gm...> - 2012-09-06 16:35:03
|
I was able to reproduce the blurring. Not sure what is causing it but will try a few things and bisect if needed. Seems like a projection bug, but I didn't change the code for perspective projection. The stereographic projection bug -I didn't reproduce it yet, but it might be caused by doing projection on shader (lower precision computation than working with floats on CPU) - Stereographic is the only projection implemented in shader. This is only used with GL2 - were the screenshots made with GL2 backend? I can't reproduce the lighting problem. Unfortunately I don't have experience with QtCreator. >From terminal, you need to pass -DCMAKE_BUILD_TYPE=Release (or RelWithDebInfo) to the cmake command, but no idea how you could do that in QtCreator. I think the current MinGW version can only compile 32bit, but mingw-builds has builds for 64bit. No idea how you would set it up, though - I don't use Windows and only set up MinGW based on tutorial on the wiki. On 9/6/12, Georg Zotti <geo...@un...> wrote: > Dear Ferdinand, > > I just built and launched 5592/MinGW/QtCreator/compiled-as-downloaded on > Win7-64/i7/NVidia GTX580M (OpenGL4.2.0). > > Performance here may be even slightly better than the pre-merge trunk > (running both in parallel, I have about 55fps vs. 51 fps for similar > settings, but both numbers are not stable, so I would say they perform > approximately equal). > > But at least in perspective projection, with a "spherical" landscape, the > image corners in wide-angle mode are worse than before. See attached > screenshots. The triangles on the corners are extremely blurred. Is there > a bug in the texture mapping for clipped triangles? > > https://dl.dropbox.com/u/30092392/stellarium-11.4.png > https://dl.dropbox.com/u/30092392/stellarium-r5592.png > > Also, in stereographic mode, the tesselation appears to be much coarser, > so there are visible straight edges where there were none previously. > Compare screenshots: > > https://dl.dropbox.com/u/30092392/stellarium-11.4b.png > https://dl.dropbox.com/u/30092392/stellarium-r5592b.png > > The metal bars along the horizon are actually an artificial horizon, and > should follow the horizon markers. It's a square seen from the inside, so > there should be no edges at 90/180°. Here, also the illumination seems to > be too bright, the gray concrete is overexposed in the lower left. > > So much for my first impressions. I will try to make a "release" build for > my netbook soon. Do I have to set this in CMakeLists.txt or is there a > setting in QtCreator for this? Also, where do I set a 64bit compile? (Is > this possible with MinGW?) I guess failing to load star catalog 8 is > caused by the 32bit addressing limit. > > TNX, G. > > On Do, 6.09.2012, 08:13, Ferdinand Majerech wrote: >> There are still performance issues getting fixed. >> >> Just after 5592 there was another significant improvement >> (not yet in trunk): could you test how it compares? >> (https://code.launchpad.net/~kiithsacmp/stellarium/glexperiment) (Also > describe the load you're getting 4-7FPS with? (just opened Stellarium?) >> >> Still, those results seem worse than what I'd expect from 5592. >> Did you build the release build? Debug build is visibly slower. >> (I have ~30FPS -when launched - on an Athlon64 3200+.) >> > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > |
From: Georg Z. <geo...@un...> - 2012-09-06 16:57:45
|
On Do, 6.09.2012, 18:34, Ferdinand Majerech wrote: > I was able to reproduce the blurring. > > Not sure what is causing it but will try a few things and bisect if > needed. > Seems like a projection bug, but I didn't change the code for > perspective projection. Strange. > The stereographic projection bug -I didn't reproduce it yet, but it > might be caused by doing projection on shader (lower precision > computation than working with floats on CPU) - Stereographic is the > only projection implemented in shader. This is only used with GL2 - > were the screenshots made with GL2 backend? Yes, on my hi-end notebook. Starting both 11.4 and r5592 with --safe-mode has the same result, the older version has better curvature. (the logfile confirms it uses OpenGL [not 2] paint engine) > I can't reproduce the lighting problem. It's not really critical, just the scene is lighter in general. If you have very bright parts in the landscape, they may become overexposed when the sun is high. Currently I cannot see it either. > > Unfortunately I don't have experience with QtCreator. >>From terminal, you need to pass -DCMAKE_BUILD_TYPE=Release > (or RelWithDebInfo) to the cmake command, but no idea how you could do > that in QtCreator. > > > I think the current MinGW version can only compile 32bit, but mingw-builds > has builds for 64bit. No idea how you would set it up, though - I > don't use Windows and only set up MinGW based on tutorial on the wiki. Yes, me too. Alexander, you are building the win64 packages. Can you please describe how and where to set these building vars? I know I can set it in the project's main CMakeLists.txt, but there may be a better way. TNX, Georg. > On 9/6/12, Georg Zotti <geo...@un...> wrote: >> Dear Ferdinand, >> >> I just built and launched 5592/MinGW/QtCreator/compiled-as-downloaded on >> Win7-64/i7/NVidia GTX580M (OpenGL4.2.0). >> >> Performance here may be even slightly better than the pre-merge trunk >> (running both in parallel, I have about 55fps vs. 51 fps for similar >> settings, but both numbers are not stable, so I would say they perform >> approximately equal). >> >> But at least in perspective projection, with a "spherical" landscape, >> the >> image corners in wide-angle mode are worse than before. See attached >> screenshots. The triangles on the corners are extremely blurred. Is >> there >> a bug in the texture mapping for clipped triangles? >> >> https://dl.dropbox.com/u/30092392/stellarium-11.4.png >> https://dl.dropbox.com/u/30092392/stellarium-r5592.png >> >> Also, in stereographic mode, the tesselation appears to be much coarser, >> so there are visible straight edges where there were none previously. >> Compare screenshots: >> >> https://dl.dropbox.com/u/30092392/stellarium-11.4b.png >> https://dl.dropbox.com/u/30092392/stellarium-r5592b.png >> >> The metal bars along the horizon are actually an artificial horizon, and >> should follow the horizon markers. It's a square seen from the inside, >> so >> there should be no edges at 90/180°. Here, also the illumination seems >> to >> be too bright, the gray concrete is overexposed in the lower left. >> >> So much for my first impressions. I will try to make a "release" build >> for >> my netbook soon. Do I have to set this in CMakeLists.txt or is there a >> setting in QtCreator for this? Also, where do I set a 64bit compile? (Is >> this possible with MinGW?) I guess failing to load star catalog 8 is >> caused by the 32bit addressing limit. >> >> TNX, G. >> >> On Do, 6.09.2012, 08:13, Ferdinand Majerech wrote: >>> There are still performance issues getting fixed. >>> >>> Just after 5592 there was another significant improvement >>> (not yet in trunk): could you test how it compares? >>> (https://code.launchpad.net/~kiithsacmp/stellarium/glexperiment) (Also >> describe the load you're getting 4-7FPS with? (just opened Stellarium?) >>> >>> Still, those results seem worse than what I'd expect from 5592. >>> Did you build the release build? Debug build is visibly slower. >>> (I have ~30FPS -when launched - on an Athlon64 3200+.) >>> >> > |
From: Alexander W. <ale...@gm...> - 2012-09-06 17:04:25
|
Hi! 2012/9/6 Georg Zotti <geo...@un...>: >> I think the current MinGW version can only compile 32bit, but mingw-builds >> has builds for 64bit. No idea how you would set it up, though - I >> don't use Windows and only set up MinGW based on tutorial on the wiki. > > Yes, me too. Alexander, you are building the win64 packages. Can you > please describe how and where to set these building vars? I know I can set > it in the project's main CMakeLists.txt, but there may be a better way. Building x64 Stellarium similar x86. You can found instructions in our wiki - http://www.stellarium.org/wiki/index.php/CompileWithMinGW-w64 Binary Qt for Windows you can found only x86 :-( but you can build x64 Qt from source code (like me). -- With best regards, Alexander |
From: Ferdinand M. <kii...@gm...> - 2012-09-06 19:06:32
|
Fixed the landscape bug. It was due to swapped parameters to a function. Fix currently pushed to https://code.launchpad.net/~kiithsacmp/stellarium/glexperiment On 9/6/12, Alexander Wolf <ale...@gm...> wrote: > Hi! > > 2012/9/6 Georg Zotti <geo...@un...>: >>> I think the current MinGW version can only compile 32bit, but >>> mingw-builds >>> has builds for 64bit. No idea how you would set it up, though - I >>> don't use Windows and only set up MinGW based on tutorial on the wiki. >> >> Yes, me too. Alexander, you are building the win64 packages. Can you >> please describe how and where to set these building vars? I know I can >> set >> it in the project's main CMakeLists.txt, but there may be a better way. > > Building x64 Stellarium similar x86. You can found instructions in our > wiki - http://www.stellarium.org/wiki/index.php/CompileWithMinGW-w64 > > Binary Qt for Windows you can found only x86 :-( but you can build x64 > Qt from source code (like me). > > > -- > With best regards, Alexander > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > |
From: Ferdinand M. <kii...@gm...> - 2012-09-06 19:32:01
|
I can't reproduce the stereographic projection bug. It might have been caused by the same issue. Please test. On 9/6/12, Ferdinand Majerech <kii...@gm...> wrote: > Fixed the landscape bug. > > It was due to swapped parameters to a function. > > Fix currently pushed to > https://code.launchpad.net/~kiithsacmp/stellarium/glexperiment > > On 9/6/12, Alexander Wolf <ale...@gm...> wrote: >> Hi! >> >> 2012/9/6 Georg Zotti <geo...@un...>: >>>> I think the current MinGW version can only compile 32bit, but >>>> mingw-builds >>>> has builds for 64bit. No idea how you would set it up, though - I >>>> don't use Windows and only set up MinGW based on tutorial on the wiki. >>> >>> Yes, me too. Alexander, you are building the win64 packages. Can you >>> please describe how and where to set these building vars? I know I can >>> set >>> it in the project's main CMakeLists.txt, but there may be a better way. >> >> Building x64 Stellarium similar x86. You can found instructions in our >> wiki - http://www.stellarium.org/wiki/index.php/CompileWithMinGW-w64 >> >> Binary Qt for Windows you can found only x86 :-( but you can build x64 >> Qt from source code (like me). >> >> >> -- >> With best regards, Alexander >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Stellarium-pubdevel mailing list >> Ste...@li... >> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel >> > |
From: Barry G. <bar...@ho...> - 2012-09-06 22:20:46
|
First attempt at compiling 5594 in windows failed at linking stage on my ACER laptop intel 945 (5592 compiled OK but did not have splash screen otherwise ran OK) Will test other computers later Barry Gerdes Beaumont Hills Observatory S 33' 41' 44" E 150' 56' 32" > Date: Fri, 7 Sep 2012 00:04:16 +0700 > From: ale...@gm... > To: ste...@li... > Subject: Re: [Stellarium-pubdevel] OpenGL2: speed OK, but deteriorated quality! > > Hi! > > 2012/9/6 Georg Zotti <geo...@un...>: > >> I think the current MinGW version can only compile 32bit, but mingw-builds > >> has builds for 64bit. No idea how you would set it up, though - I > >> don't use Windows and only set up MinGW based on tutorial on the wiki. > > > > Yes, me too. Alexander, you are building the win64 packages. Can you > > please describe how and where to set these building vars? I know I can set > > it in the project's main CMakeLists.txt, but there may be a better way. > > Building x64 Stellarium similar x86. You can found instructions in our > wiki - http://www.stellarium.org/wiki/index.php/CompileWithMinGW-w64 > > Binary Qt for Windows you can found only x86 :-( but you can build x64 > Qt from source code (like me). > > > -- > With best regards, Alexander > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel |
From: Barry G. <bar...@ho...> - 2012-09-07 00:25:54
|
I have now tried to compile 5594 in windows on three other computers without success. I keep getting this warning at every step of the compile "this machine does not have delayed action branches [enabled by default]"s.cpp the problem seems to be in StelUtils.cpp around lines 1086-1089 may even be just a syntax error missing ' compile on linux works without any problem Barry Gerdes Beaumont Hills Observatory S 33' 41' 44" E 150' 56' 32" From: bar...@ho... To: ste...@li... Date: Fri, 7 Sep 2012 08:20:39 +1000 Subject: Re: [Stellarium-pubdevel] OpenGL2: speed OK, but deteriorated quality! First attempt at compiling 5594 in windows failed at linking stage on my ACER laptop intel 945 (5592 compiled OK but did not have splash screen otherwise ran OK) Will test other computers later Barry Gerdes Beaumont Hills Observatory S 33' 41' 44" E 150' 56' 32" > Date: Fri, 7 Sep 2012 00:04:16 +0700 > From: ale...@gm... > To: ste...@li... > Subject: Re: [Stellarium-pubdevel] OpenGL2: speed OK, but deteriorated quality! > > Hi! > > 2012/9/6 Georg Zotti <geo...@un...>: > >> I think the current MinGW version can only compile 32bit, but mingw-builds > >> has builds for 64bit. No idea how you would set it up, though - I > >> don't use Windows and only set up MinGW based on tutorial on the wiki. > > > > Yes, me too. Alexander, you are building the win64 packages. Can you > > please describe how and where to set these building vars? I know I can set > > it in the project's main CMakeLists.txt, but there may be a better way. > > Building x64 Stellarium similar x86. You can found instructions in our > wiki - http://www.stellarium.org/wiki/index.php/CompileWithMinGW-w64 > > Binary Qt for Windows you can found only x86 :-( but you can build x64 > Qt from source code (like me). > > > -- > With best regards, Alexander > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Stellarium-pubdevel mailing list Ste...@li... https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel |
From: Georg Z. <geo...@un...> - 2012-09-07 01:16:05
|
Hi! I confirm this warning, but the real error is this: ... [ 47%] Building CXX object src/CMakeFiles/stelMain.dir/core/StelUtils.cpp.obj cd C:\Stellarium_DEV\BZR\glexperiment\builds\qt\src && C:\Qt\MinGW\bin\g++.exe -DstelMain_EXPORTS -DPACKAGE_VERSION=\"0.12.0\" -DSTELLARIUM_SPLASH=\"Development\" -DENABLE_NLS -DENABLE_SCRIPT_CONSOLE -DDEFAULT_GRAPHICS_SYSTEM=\"native\" -DQT_DLL -DQT_OPENGL_LIB -DQT_SCRIPT_LIB -DQT_GUI_LIB -DQT_TEST_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DINSTALL_DATADIR=\".\" -DINSTALL_LOCALEDIR=\"./locale\" -DUSE_STATIC_PLUGIN_OBSERVABILITY -DUSE_STATIC_PLUGIN_ANGLEMEASURE -DUSE_STATIC_PLUGIN_COMPASSMARKS -DUSE_STATIC_PLUGIN_SATELLITES -DUSE_STATIC_PLUGIN_TELESCOPECONTROL -DUSE_STATIC_PLUGIN_OCULARS -DUSE_STATIC_PLUGIN_TEXTUSERINTERFACE -DUSE_STATIC_PLUGIN_SOLARSYSTEMEDITOR -DUSE_STATIC_PLUGIN_TIMEZONECONFIGURATION -DUSE_STATIC_PLUGIN_SUPERNOVAE -DUSE_STATIC_PLUGIN_QUASARS -DUSE_STATIC_PLUGIN_PULSARS -DUSE_STATIC_PLUGIN_EXOPLANETS -DUSE_STATIC_PLUGIN_RENDERERSTATISTICS -DQT_DEBUG -Wall -Wsign-promo -fexceptions -fident -mthreads -g -IC:\Qt\4.8.2\include -IC:\Qt\4.8.2\include\QtOpenGL -IC:\Qt\4.8.2\include\QtScript -IC:\Qt\4.8.2\include\QtGui -IC:\Qt\4.8.2\include\QtTest -IC:\Qt\4.8.2\include\QtNetwork -IC:\Qt\4.8.2\include\QtCore -IC:\Stellarium_DEV\BZR\glexperiment\builds\qt -IC:\Stellarium_DEV\BZR\glexperiment\src -IC:\Stellarium_DEV\BZR\glexperiment\src\core -IC:\Stellarium_DEV\BZR\glexperiment\src\core\renderer -IC:\Stellarium_DEV\BZR\glexperiment\src\core\modules -IC:\Stellarium_DEV\BZR\glexperiment\src\core\planetsephems -IC:\Stellarium_DEV\BZR\glexperiment\src\core\external -IC:\Stellarium_DEV\BZR\glexperiment\src\core\external\kfilter -IC:\Stellarium_DEV\BZR\glexperiment\src\core\external\glues_stel\source -IC:\Stellarium_DEV\BZR\glexperiment\src\core\external\glues_stel\source\libtess -IC:\Stellarium_DEV\BZR\glexperiment\src\gui -IC:\Stellarium_DEV\BZR\glexperiment\src\scripting -IC:\Qt\MinGW\include -IC:\Stellarium_DEV\BZR\glexperiment\builds\qt\src -o CMakeFiles\stelMain.dir\core\StelUtils.cpp.obj -c C:\Stellarium_DEV\BZR\glexperiment\src\core\StelUtils.cpp mingw32-make[2]: Leaving directory `C:/Stellarium_DEV/BZR/glexperiment/builds/qt' mingw32-make[1]: Leaving directory `C:/Stellarium_DEV/BZR/glexperiment/builds/qt' In file included from C:\Stellarium_DEV\BZR\glexperiment\src\core\StelUtils.cpp:1067:0: c:\qt\mingw\bin\../lib/gcc/mingw32/4.6.2/include/c++/ctime:62:11: error: '::clock_t' has not been declared c:\qt\mingw\bin\../lib/gcc/mingw32/4.6.2/include/c++/ctime:66:11: error: '::clock' has not been declared c:\qt\mingw\bin\../lib/gcc/mingw32/4.6.2/include/c++/ctime:67:11: error: '::difftime' has not been declared c:\qt\mingw\bin\../lib/gcc/mingw32/4.6.2/include/c++/ctime:68:11: error: '::mktime' has not been declared c:\qt\mingw\bin\../lib/gcc/mingw32/4.6.2/include/c++/ctime:69:11: error: '::time' has not been declared c:\qt\mingw\bin\../lib/gcc/mingw32/4.6.2/include/c++/ctime:70:11: error: '::asctime' has not been declared c:\qt\mingw\bin\../lib/gcc/mingw32/4.6.2/include/c++/ctime:71:11: error: '::ctime' has not been declared c:\qt\mingw\bin\../lib/gcc/mingw32/4.6.2/include/c++/ctime:72:11: error: '::gmtime' has not been declared c:\qt\mingw\bin\../lib/gcc/mingw32/4.6.2/include/c++/ctime:73:11: error: '::localtime' has not been declared c:\qt\mingw\bin\../lib/gcc/mingw32/4.6.2/include/c++/ctime:74:11: error: '::strftime' has not been declared C:\Stellarium_DEV\BZR\glexperiment\src\core\StelUtils.cpp: In function 'long double StelUtils::getTime()': C:\Stellarium_DEV\BZR\glexperiment\src\core\StelUtils.cpp:1086:2: error: 'clock_t' is not a member of 'StelUtils::std' C:\Stellarium_DEV\BZR\glexperiment\src\core\StelUtils.cpp:1086:2: note: suggested alternative: c:\qt\mingw\bin\../lib/gcc/mingw32/4.6.2/../../../../include/time.h:71:14: note: 'StelUtils::clock_t' C:\Stellarium_DEV\BZR\glexperiment\src\core\StelUtils.cpp:1086:15: error: expected ';' before 'cpuTime' C:\Stellarium_DEV\BZR\glexperiment\src\core\StelUtils.cpp:1087:34: error: 'cpuTime' was not declared in this scope C:\Stellarium_DEV\BZR\glexperiment\src\core\StelUtils.cpp:1089:1: warning: control reaches end of non-void function [-Wreturn-type] mingw32-make[2]: *** [src/CMakeFiles/stelMain.dir/core/StelUtils.cpp.obj] Error 1 mingw32-make[1]: *** [src/CMakeFiles/stelMain.dir/all] Error 2 mingw32-make: *** [all] Error 2 03:07:16: Der Prozess "C:\Qt\MinGW\bin\mingw32-make.exe" wurde mit dem Rückgabewert 2 beendet. Fehler beim Erstellen/Deployment des Projekts Stellarium(Ziel: Desktop) Bei der Ausführung von Schritt 'Make' Maybe some other include to use? HTH, G. On Fr, 7.09.2012, 02:25, Barry Gerdes wrote: > > I have now tried to compile 5594 in windows on three other computers > without success. > I keep getting this warning at every step of the compile > "this machine does not have delayed action branches [enabled by > default]"s.cpp > the problem seems to be in StelUtils.cpp around lines 1086-1089 > may even be just a syntax error missing ' > > compile on linux works without any problem > > Barry Gerdes > Beaumont Hills Observatory > S 33' 41' 44" E 150' 56' 32" > > From: bar...@ho... > To: ste...@li... > Date: Fri, 7 Sep 2012 08:20:39 +1000 > Subject: Re: [Stellarium-pubdevel] OpenGL2: speed OK, but deteriorated > quality! > |
From: Ferdinand M. <kii...@gm...> - 2012-09-07 02:07:20
|
The warning spam seems to be caused by the Windows release build workaround. The compilation error is weird; AFAIK clock_t is standard C++. Maybe it could be fixed by removing std:: and including <time.h> (C include) instead. I'll look at this tomorrow, need to sleep now. On 9/7/12, Georg Zotti <geo...@un...> wrote: > Hi! > > I confirm this warning, but the real error is this: > > ... > [ 47%] Building CXX object > src/CMakeFiles/stelMain.dir/core/StelUtils.cpp.obj > cd C:\Stellarium_DEV\BZR\glexperiment\builds\qt\src && > C:\Qt\MinGW\bin\g++.exe -DstelMain_EXPORTS -DPACKAGE_VERSION=\"0.12.0\" > -DSTELLARIUM_SPLASH=\"Development\" -DENABLE_NLS -DENABLE_SCRIPT_CONSOLE > -DDEFAULT_GRAPHICS_SYSTEM=\"native\" -DQT_DLL -DQT_OPENGL_LIB > -DQT_SCRIPT_LIB -DQT_GUI_LIB -DQT_TEST_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB > -DINSTALL_DATADIR=\".\" -DINSTALL_LOCALEDIR=\"./locale\" > -DUSE_STATIC_PLUGIN_OBSERVABILITY -DUSE_STATIC_PLUGIN_ANGLEMEASURE > -DUSE_STATIC_PLUGIN_COMPASSMARKS -DUSE_STATIC_PLUGIN_SATELLITES > -DUSE_STATIC_PLUGIN_TELESCOPECONTROL -DUSE_STATIC_PLUGIN_OCULARS > -DUSE_STATIC_PLUGIN_TEXTUSERINTERFACE > -DUSE_STATIC_PLUGIN_SOLARSYSTEMEDITOR > -DUSE_STATIC_PLUGIN_TIMEZONECONFIGURATION -DUSE_STATIC_PLUGIN_SUPERNOVAE > -DUSE_STATIC_PLUGIN_QUASARS -DUSE_STATIC_PLUGIN_PULSARS > -DUSE_STATIC_PLUGIN_EXOPLANETS -DUSE_STATIC_PLUGIN_RENDERERSTATISTICS > -DQT_DEBUG -Wall -Wsign-promo -fexceptions -fident -mthreads -g > -IC:\Qt\4.8.2\include -IC:\Qt\4.8.2\include\QtOpenGL > -IC:\Qt\4.8.2\include\QtScript -IC:\Qt\4.8.2\include\QtGui > -IC:\Qt\4.8.2\include\QtTest -IC:\Qt\4.8.2\include\QtNetwork > -IC:\Qt\4.8.2\include\QtCore > -IC:\Stellarium_DEV\BZR\glexperiment\builds\qt > -IC:\Stellarium_DEV\BZR\glexperiment\src > -IC:\Stellarium_DEV\BZR\glexperiment\src\core > -IC:\Stellarium_DEV\BZR\glexperiment\src\core\renderer > -IC:\Stellarium_DEV\BZR\glexperiment\src\core\modules > -IC:\Stellarium_DEV\BZR\glexperiment\src\core\planetsephems > -IC:\Stellarium_DEV\BZR\glexperiment\src\core\external > -IC:\Stellarium_DEV\BZR\glexperiment\src\core\external\kfilter > -IC:\Stellarium_DEV\BZR\glexperiment\src\core\external\glues_stel\source > -IC:\Stellarium_DEV\BZR\glexperiment\src\core\external\glues_stel\source\libtess > -IC:\Stellarium_DEV\BZR\glexperiment\src\gui > -IC:\Stellarium_DEV\BZR\glexperiment\src\scripting -IC:\Qt\MinGW\include > -IC:\Stellarium_DEV\BZR\glexperiment\builds\qt\src -o > CMakeFiles\stelMain.dir\core\StelUtils.cpp.obj -c > C:\Stellarium_DEV\BZR\glexperiment\src\core\StelUtils.cpp > mingw32-make[2]: Leaving directory > `C:/Stellarium_DEV/BZR/glexperiment/builds/qt' > mingw32-make[1]: Leaving directory > `C:/Stellarium_DEV/BZR/glexperiment/builds/qt' > In file included from > C:\Stellarium_DEV\BZR\glexperiment\src\core\StelUtils.cpp:1067:0: > c:\qt\mingw\bin\../lib/gcc/mingw32/4.6.2/include/c++/ctime:62:11: error: > '::clock_t' has not been declared > c:\qt\mingw\bin\../lib/gcc/mingw32/4.6.2/include/c++/ctime:66:11: error: > '::clock' has not been declared > c:\qt\mingw\bin\../lib/gcc/mingw32/4.6.2/include/c++/ctime:67:11: error: > '::difftime' has not been declared > c:\qt\mingw\bin\../lib/gcc/mingw32/4.6.2/include/c++/ctime:68:11: error: > '::mktime' has not been declared > c:\qt\mingw\bin\../lib/gcc/mingw32/4.6.2/include/c++/ctime:69:11: error: > '::time' has not been declared > c:\qt\mingw\bin\../lib/gcc/mingw32/4.6.2/include/c++/ctime:70:11: error: > '::asctime' has not been declared > c:\qt\mingw\bin\../lib/gcc/mingw32/4.6.2/include/c++/ctime:71:11: error: > '::ctime' has not been declared > c:\qt\mingw\bin\../lib/gcc/mingw32/4.6.2/include/c++/ctime:72:11: error: > '::gmtime' has not been declared > c:\qt\mingw\bin\../lib/gcc/mingw32/4.6.2/include/c++/ctime:73:11: error: > '::localtime' has not been declared > c:\qt\mingw\bin\../lib/gcc/mingw32/4.6.2/include/c++/ctime:74:11: error: > '::strftime' has not been declared > C:\Stellarium_DEV\BZR\glexperiment\src\core\StelUtils.cpp: In function > 'long double StelUtils::getTime()': > C:\Stellarium_DEV\BZR\glexperiment\src\core\StelUtils.cpp:1086:2: error: > 'clock_t' is not a member of 'StelUtils::std' > C:\Stellarium_DEV\BZR\glexperiment\src\core\StelUtils.cpp:1086:2: note: > suggested alternative: > c:\qt\mingw\bin\../lib/gcc/mingw32/4.6.2/../../../../include/time.h:71:14: > note: 'StelUtils::clock_t' > C:\Stellarium_DEV\BZR\glexperiment\src\core\StelUtils.cpp:1086:15: error: > expected ';' before 'cpuTime' > C:\Stellarium_DEV\BZR\glexperiment\src\core\StelUtils.cpp:1087:34: error: > 'cpuTime' was not declared in this scope > C:\Stellarium_DEV\BZR\glexperiment\src\core\StelUtils.cpp:1089:1: warning: > control reaches end of non-void function [-Wreturn-type] > mingw32-make[2]: *** [src/CMakeFiles/stelMain.dir/core/StelUtils.cpp.obj] > Error 1 > mingw32-make[1]: *** [src/CMakeFiles/stelMain.dir/all] Error 2 > mingw32-make: *** [all] Error 2 > 03:07:16: Der Prozess "C:\Qt\MinGW\bin\mingw32-make.exe" wurde mit dem > Rückgabewert 2 beendet. > Fehler beim Erstellen/Deployment des Projekts Stellarium(Ziel: Desktop) > Bei der Ausführung von Schritt 'Make' > > Maybe some other include to use? > > HTH, G. > > On Fr, 7.09.2012, 02:25, Barry Gerdes wrote: >> >> I have now tried to compile 5594 in windows on three other computers >> without success. >> I keep getting this warning at every step of the compile >> "this machine does not have delayed action branches [enabled by >> default]"s.cpp >> the problem seems to be in StelUtils.cpp around lines 1086-1089 >> may even be just a syntax error missing ' >> >> compile on linux works without any problem >> >> Barry Gerdes >> Beaumont Hills Observatory >> S 33' 41' 44" E 150' 56' 32" >> >> From: bar...@ho... >> To: ste...@li... >> Date: Fri, 7 Sep 2012 08:20:39 +1000 >> Subject: Re: [Stellarium-pubdevel] OpenGL2: speed OK, but deteriorated >> quality! >> > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > |
From: Georg Z. <geo...@un...> - 2012-09-07 15:08:10
|
On Fr, 7.09.2012, 04:07, Ferdinand Majerech wrote: > The warning spam seems to be caused by the Windows release build > workaround. > > The compilation error is weird; AFAIK clock_t is standard C++. > > Maybe it could be fixed by removing std:: and including <time.h> (C > include) > instead. Yes, indeed all that is needed under Windows/MinGW is in StelUtils.cpp: line 1067: #include <time.h> and line 1086: clock_t cpuTime = clock(); OK, the texturing issue in perspective mode is solved. Stereographic mode is also much cleaner now, the big zigzags are mostly gone, but still the older solution has "rounder" distortion. Also the shortest lines in the compass marks plugin appear to vanish sometimes at max fov, and its red text is less clear than in the older version (aliasing?). In order to not only test stereographic, in these images: https://dl.dropbox.com/u/30092392/stellarium-STG-cyl_11.4.png https://dl.dropbox.com/u/30092392/stellarium-STG-cyl_glexperiment5623.png you see a cylindrical view. The vertical pillars mark north and south, on the north pillar (stretching into the image at top left) there is a circular disk with a hole marking the north celestial pole. I tried to get the same view in both versions. The tesselation of the landscape is still coarser or maybe the previous mapping did more than linear interpolation, but in the glexperiment image the distortion of pillar and disk appear to be stronger, and the text from the compass marks grainier (a bit aliased). Concerning text rendition: The object info at top left seems OK, but star and constellation labels are also aliased. Kind regards, Georg |
From: Ferdinand M. <kii...@gm...> - 2012-09-07 15:35:49
|
Could you send me a link to the landscape you're using? It seems the problems are much more clearly visible there. I'll look at text drawing, it might be due to different font parameters, not sure. On 9/7/12, Georg Zotti <geo...@un...> wrote: > > On Fr, 7.09.2012, 04:07, Ferdinand Majerech wrote: >> The warning spam seems to be caused by the Windows release build >> workaround. >> >> The compilation error is weird; AFAIK clock_t is standard C++. >> >> Maybe it could be fixed by removing std:: and including <time.h> (C >> include) >> instead. > > Yes, indeed all that is needed under Windows/MinGW is in > StelUtils.cpp: > line 1067: #include <time.h> > and > line 1086: clock_t cpuTime = clock(); > > > OK, the texturing issue in perspective mode is solved. Stereographic mode > is also much cleaner now, the big zigzags are mostly gone, but still the > older solution has "rounder" distortion. Also the shortest lines in the > compass marks plugin appear to vanish sometimes at max fov, and its red > text is less clear than in the older version (aliasing?). > > In order to not only test stereographic, in these images: > https://dl.dropbox.com/u/30092392/stellarium-STG-cyl_11.4.png > https://dl.dropbox.com/u/30092392/stellarium-STG-cyl_glexperiment5623.png > > you see a cylindrical view. The vertical pillars mark north and south, on > the north pillar (stretching into the image at top left) there is a > circular disk with a hole marking the north celestial pole. I tried to get > the same view in both versions. The tesselation of the landscape is still > coarser or maybe the previous mapping did more than linear interpolation, > but in the glexperiment image the distortion of pillar and disk appear to > be stronger, and the text from the compass marks grainier (a bit aliased). > > Concerning text rendition: The object info at top left seems OK, but star > and constellation labels are also aliased. > > Kind regards, > Georg > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > |
From: Georg Z. <geo...@un...> - 2012-09-07 16:10:17
|
Hi! Sure, please download: https://dl.dropbox.com/u/30092392/Sterngarten_Mitte_Photo.zip I created this and also a pano https://dl.dropbox.com/u/30092392/Sterngarten_MitteHQ.zip from a Sketchup model (will be back on Google Earth shortly), as critical tests for the accuracy of Stellarium and to develop and test atmospheric effects. The model itself is then also included in scenery3D. If you (team) want, I can contribute this landscape. HTH, G. On Fr, 7.09.2012, 17:35, Ferdinand Majerech wrote: > Could you send me a link to the landscape you're using? > > It seems the problems are much more clearly visible there. > > I'll look at text drawing, it might be due to different font > parameters, not sure. > |
From: Ferdinand M. <kii...@gm...> - 2012-09-07 15:42:25
|
About the smallest lines vanishing: This is a rasterization issue (when they are smaller than one pixel, they aren't drawn), and it happens in pre-merge Stellarium as well. It might be possible to decrease it by using antialiasing, but it can't be completely eliminated. On 9/7/12, Ferdinand Majerech <kii...@gm...> wrote: > Could you send me a link to the landscape you're using? > > It seems the problems are much more clearly visible there. > > I'll look at text drawing, it might be due to different font > parameters, not sure. > > On 9/7/12, Georg Zotti <geo...@un...> wrote: >> >> On Fr, 7.09.2012, 04:07, Ferdinand Majerech wrote: >>> The warning spam seems to be caused by the Windows release build >>> workaround. >>> >>> The compilation error is weird; AFAIK clock_t is standard C++. >>> >>> Maybe it could be fixed by removing std:: and including <time.h> (C >>> include) >>> instead. >> >> Yes, indeed all that is needed under Windows/MinGW is in >> StelUtils.cpp: >> line 1067: #include <time.h> >> and >> line 1086: clock_t cpuTime = clock(); >> >> >> OK, the texturing issue in perspective mode is solved. Stereographic mode >> is also much cleaner now, the big zigzags are mostly gone, but still the >> older solution has "rounder" distortion. Also the shortest lines in the >> compass marks plugin appear to vanish sometimes at max fov, and its red >> text is less clear than in the older version (aliasing?). >> >> In order to not only test stereographic, in these images: >> https://dl.dropbox.com/u/30092392/stellarium-STG-cyl_11.4.png >> https://dl.dropbox.com/u/30092392/stellarium-STG-cyl_glexperiment5623.png >> >> you see a cylindrical view. The vertical pillars mark north and south, on >> the north pillar (stretching into the image at top left) there is a >> circular disk with a hole marking the north celestial pole. I tried to >> get >> the same view in both versions. The tesselation of the landscape is still >> coarser or maybe the previous mapping did more than linear interpolation, >> but in the glexperiment image the distortion of pillar and disk appear to >> be stronger, and the text from the compass marks grainier (a bit >> aliased). >> >> Concerning text rendition: The object info at top left seems OK, but star >> and constellation labels are also aliased. >> >> Kind regards, >> Georg >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Stellarium-pubdevel mailing list >> Ste...@li... >> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel >> > |
From: Georg Z. <geo...@un...> - 2012-09-07 16:17:33
|
On Fr, 7.09.2012, 17:42, Ferdinand Majerech wrote: > About the smallest lines vanishing: This is a rasterization issue > (when they are smaller than one pixel, they aren't drawn), and it > happens in pre-merge Stellarium as well. I have no problems with an early-August build: https://dl.dropbox.com/u/30092392/stellarium-11.3-cyl_AAtextAndCompassmarks.png That's a direct snapshot. In closeup, the text and lines clearly are antialiased. Apparently this is currently switched off. HTH, G. |
From: Ferdinand M. <kii...@gm...> - 2012-09-07 16:22:10
|
Text drawing has been fixed (pushed to glexperiment). On 9/7/12, Ferdinand Majerech <kii...@gm...> wrote: > About the smallest lines vanishing: This is a rasterization issue > (when they are smaller than one pixel, they aren't drawn), and it > happens in pre-merge Stellarium as well. It might be possible to > decrease it by using antialiasing, but it can't be completely > eliminated. > > On 9/7/12, Ferdinand Majerech <kii...@gm...> wrote: >> Could you send me a link to the landscape you're using? >> >> It seems the problems are much more clearly visible there. >> >> I'll look at text drawing, it might be due to different font >> parameters, not sure. >> >> On 9/7/12, Georg Zotti <geo...@un...> wrote: >>> >>> On Fr, 7.09.2012, 04:07, Ferdinand Majerech wrote: >>>> The warning spam seems to be caused by the Windows release build >>>> workaround. >>>> >>>> The compilation error is weird; AFAIK clock_t is standard C++. >>>> >>>> Maybe it could be fixed by removing std:: and including <time.h> (C >>>> include) >>>> instead. >>> >>> Yes, indeed all that is needed under Windows/MinGW is in >>> StelUtils.cpp: >>> line 1067: #include <time.h> >>> and >>> line 1086: clock_t cpuTime = clock(); >>> >>> >>> OK, the texturing issue in perspective mode is solved. Stereographic >>> mode >>> is also much cleaner now, the big zigzags are mostly gone, but still the >>> older solution has "rounder" distortion. Also the shortest lines in the >>> compass marks plugin appear to vanish sometimes at max fov, and its red >>> text is less clear than in the older version (aliasing?). >>> >>> In order to not only test stereographic, in these images: >>> https://dl.dropbox.com/u/30092392/stellarium-STG-cyl_11.4.png >>> https://dl.dropbox.com/u/30092392/stellarium-STG-cyl_glexperiment5623.png >>> >>> you see a cylindrical view. The vertical pillars mark north and south, >>> on >>> the north pillar (stretching into the image at top left) there is a >>> circular disk with a hole marking the north celestial pole. I tried to >>> get >>> the same view in both versions. The tesselation of the landscape is >>> still >>> coarser or maybe the previous mapping did more than linear >>> interpolation, >>> but in the glexperiment image the distortion of pillar and disk appear >>> to >>> be stronger, and the text from the compass marks grainier (a bit >>> aliased). >>> >>> Concerning text rendition: The object info at top left seems OK, but >>> star >>> and constellation labels are also aliased. >>> >>> Kind regards, >>> Georg >>> >>> >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. >>> Discussions >>> will include endpoint security, mobile security and the latest in >>> malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> Stellarium-pubdevel mailing list >>> Ste...@li... >>> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel >>> >> > |
From: Ferdinand M. <kii...@gm...> - 2012-09-07 19:59:35
|
The line antialiasing seems to depend on GL_LINE_SMOOTH. This feature is supported on some GPUs/drivers and not supported on others - for instance on my system (Radeon 6770) it doesn't work, so I get the same result with Stellarium 0.11.3 and current. GL_LINE_SMOOTH is currently enabled in GL1 backend, but it makes no difference on my system. From some googling, it sometimes requires particular blend mode settings and this might vary between GPUs. TLDR - antialiasing lines through GL_LINE_SMOOTH is not portable. You could do manual AA with lines-as-triangle-strips with lower alpha at edges - I use it in my game project - but it'd be too slow with the amount of lines Stellarium draws (and regenerates each frame). MSAA would probably work, but I don't think there's enough benefit for cost (FPS) - and not sure how to go about it with Qt (needs specific video mode IIRC). You can try forcing MSAA in your driver if it supports it to see if there's a difference. One quick hack I can do now is to round line coordinates passed to drawLine() to integers. I'll try that but not sure if it will mess up something. Text antialiasing has nothing to do with GL - that's done by Qt (the text bug wasn't lack of antialiasing either - it was wrong alpha/color values - aliased text looks different) On 9/7/12, Ferdinand Majerech <kii...@gm...> wrote: > Text drawing has been fixed (pushed to glexperiment). > > On 9/7/12, Ferdinand Majerech <kii...@gm...> wrote: >> About the smallest lines vanishing: This is a rasterization issue >> (when they are smaller than one pixel, they aren't drawn), and it >> happens in pre-merge Stellarium as well. It might be possible to >> decrease it by using antialiasing, but it can't be completely >> eliminated. >> >> On 9/7/12, Ferdinand Majerech <kii...@gm...> wrote: >>> Could you send me a link to the landscape you're using? >>> >>> It seems the problems are much more clearly visible there. >>> >>> I'll look at text drawing, it might be due to different font >>> parameters, not sure. >>> >>> On 9/7/12, Georg Zotti <geo...@un...> wrote: >>>> >>>> On Fr, 7.09.2012, 04:07, Ferdinand Majerech wrote: >>>>> The warning spam seems to be caused by the Windows release build >>>>> workaround. >>>>> >>>>> The compilation error is weird; AFAIK clock_t is standard C++. >>>>> >>>>> Maybe it could be fixed by removing std:: and including <time.h> (C >>>>> include) >>>>> instead. >>>> >>>> Yes, indeed all that is needed under Windows/MinGW is in >>>> StelUtils.cpp: >>>> line 1067: #include <time.h> >>>> and >>>> line 1086: clock_t cpuTime = clock(); >>>> >>>> >>>> OK, the texturing issue in perspective mode is solved. Stereographic >>>> mode >>>> is also much cleaner now, the big zigzags are mostly gone, but still >>>> the >>>> older solution has "rounder" distortion. Also the shortest lines in the >>>> compass marks plugin appear to vanish sometimes at max fov, and its red >>>> text is less clear than in the older version (aliasing?). >>>> >>>> In order to not only test stereographic, in these images: >>>> https://dl.dropbox.com/u/30092392/stellarium-STG-cyl_11.4.png >>>> https://dl.dropbox.com/u/30092392/stellarium-STG-cyl_glexperiment5623.png >>>> >>>> you see a cylindrical view. The vertical pillars mark north and south, >>>> on >>>> the north pillar (stretching into the image at top left) there is a >>>> circular disk with a hole marking the north celestial pole. I tried to >>>> get >>>> the same view in both versions. The tesselation of the landscape is >>>> still >>>> coarser or maybe the previous mapping did more than linear >>>> interpolation, >>>> but in the glexperiment image the distortion of pillar and disk appear >>>> to >>>> be stronger, and the text from the compass marks grainier (a bit >>>> aliased). >>>> >>>> Concerning text rendition: The object info at top left seems OK, but >>>> star >>>> and constellation labels are also aliased. >>>> >>>> Kind regards, >>>> Georg >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Live Security Virtual Conference >>>> Exclusive live event will cover all the ways today's security and >>>> threat landscape has changed and how IT managers can respond. >>>> Discussions >>>> will include endpoint security, mobile security and the latest in >>>> malware >>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>> _______________________________________________ >>>> Stellarium-pubdevel mailing list >>>> Ste...@li... >>>> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel >>>> >>> >> > |
From: Ferdinand M. <kii...@gm...> - 2012-09-07 20:29:30
|
I pushed the change - line coordinates are rounded to integer and if the line size is zero, it's made longer to fill a pixel. Not perfect (due to aliasing lines sometimes appear one pixel up/down), but should work everywhere. CompassMarks, which previously drew its lines as circle arcs now draws it as plain lines - I couldn't see a difference in any projection, but it would be good to test that more. On 9/7/12, Ferdinand Majerech <kii...@gm...> wrote: > The line antialiasing seems to depend on GL_LINE_SMOOTH. > > This feature is supported on some GPUs/drivers and not supported on others > - > for instance on my system (Radeon 6770) it doesn't work, so I get the > same result > with Stellarium 0.11.3 and current. > > GL_LINE_SMOOTH is currently enabled in GL1 backend, but it makes no > difference > on my system. From some googling, it sometimes requires particular > blend mode settings and this might vary between GPUs. > > TLDR - antialiasing lines through GL_LINE_SMOOTH is not portable. > You could do manual AA with lines-as-triangle-strips with lower alpha at > edges - > I use it in my game project - but it'd be too slow with the amount of > lines Stellarium > draws (and regenerates each frame). > > MSAA would probably work, but I don't think there's enough > benefit for cost (FPS) - and not sure how to go about it with Qt > (needs specific video mode IIRC). You can try forcing MSAA in your > driver if it supports it to see if there's a difference. > > One quick hack I can do now is to round line coordinates passed to > drawLine() to integers. I'll try that but not sure if it will mess up > something. > > > Text antialiasing has nothing to do with GL - that's done by Qt > (the text bug wasn't lack of antialiasing either - it was wrong > alpha/color values - aliased text looks different) > > On 9/7/12, Ferdinand Majerech <kii...@gm...> wrote: >> Text drawing has been fixed (pushed to glexperiment). >> >> On 9/7/12, Ferdinand Majerech <kii...@gm...> wrote: >>> About the smallest lines vanishing: This is a rasterization issue >>> (when they are smaller than one pixel, they aren't drawn), and it >>> happens in pre-merge Stellarium as well. It might be possible to >>> decrease it by using antialiasing, but it can't be completely >>> eliminated. >>> >>> On 9/7/12, Ferdinand Majerech <kii...@gm...> wrote: >>>> Could you send me a link to the landscape you're using? >>>> >>>> It seems the problems are much more clearly visible there. >>>> >>>> I'll look at text drawing, it might be due to different font >>>> parameters, not sure. >>>> >>>> On 9/7/12, Georg Zotti <geo...@un...> wrote: >>>>> >>>>> On Fr, 7.09.2012, 04:07, Ferdinand Majerech wrote: >>>>>> The warning spam seems to be caused by the Windows release build >>>>>> workaround. >>>>>> >>>>>> The compilation error is weird; AFAIK clock_t is standard C++. >>>>>> >>>>>> Maybe it could be fixed by removing std:: and including <time.h> (C >>>>>> include) >>>>>> instead. >>>>> >>>>> Yes, indeed all that is needed under Windows/MinGW is in >>>>> StelUtils.cpp: >>>>> line 1067: #include <time.h> >>>>> and >>>>> line 1086: clock_t cpuTime = clock(); >>>>> >>>>> >>>>> OK, the texturing issue in perspective mode is solved. Stereographic >>>>> mode >>>>> is also much cleaner now, the big zigzags are mostly gone, but still >>>>> the >>>>> older solution has "rounder" distortion. Also the shortest lines in >>>>> the >>>>> compass marks plugin appear to vanish sometimes at max fov, and its >>>>> red >>>>> text is less clear than in the older version (aliasing?). >>>>> >>>>> In order to not only test stereographic, in these images: >>>>> https://dl.dropbox.com/u/30092392/stellarium-STG-cyl_11.4.png >>>>> https://dl.dropbox.com/u/30092392/stellarium-STG-cyl_glexperiment5623.png >>>>> >>>>> you see a cylindrical view. The vertical pillars mark north and south, >>>>> on >>>>> the north pillar (stretching into the image at top left) there is a >>>>> circular disk with a hole marking the north celestial pole. I tried to >>>>> get >>>>> the same view in both versions. The tesselation of the landscape is >>>>> still >>>>> coarser or maybe the previous mapping did more than linear >>>>> interpolation, >>>>> but in the glexperiment image the distortion of pillar and disk appear >>>>> to >>>>> be stronger, and the text from the compass marks grainier (a bit >>>>> aliased). >>>>> >>>>> Concerning text rendition: The object info at top left seems OK, but >>>>> star >>>>> and constellation labels are also aliased. >>>>> >>>>> Kind regards, >>>>> Georg >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Live Security Virtual Conference >>>>> Exclusive live event will cover all the ways today's security and >>>>> threat landscape has changed and how IT managers can respond. >>>>> Discussions >>>>> will include endpoint security, mobile security and the latest in >>>>> malware >>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>>> _______________________________________________ >>>>> Stellarium-pubdevel mailing list >>>>> Ste...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel >>>>> >>>> >>> >> > |
From: Ferdinand M. <kii...@gm...> - 2012-09-07 20:46:50
|
...OK - at high FOVs the rounding actually messed up the lines quite a bit. I pushed a slightly more elaborate version (make the line longer in its direction if it's smaller than 1 pixel). On 9/7/12, Ferdinand Majerech <kii...@gm...> wrote: > I pushed the change - line coordinates are rounded to integer and if the > line > size is zero, it's made longer to fill a pixel. Not perfect (due to > aliasing lines sometimes > appear one pixel up/down), but should work everywhere. > > CompassMarks, which previously drew its lines as circle arcs now draws > it as plain lines - I couldn't see a difference in any projection, but > it would be good to test that more. > > On 9/7/12, Ferdinand Majerech <kii...@gm...> wrote: >> The line antialiasing seems to depend on GL_LINE_SMOOTH. >> >> This feature is supported on some GPUs/drivers and not supported on >> others >> - >> for instance on my system (Radeon 6770) it doesn't work, so I get the >> same result >> with Stellarium 0.11.3 and current. >> >> GL_LINE_SMOOTH is currently enabled in GL1 backend, but it makes no >> difference >> on my system. From some googling, it sometimes requires particular >> blend mode settings and this might vary between GPUs. >> >> TLDR - antialiasing lines through GL_LINE_SMOOTH is not portable. >> You could do manual AA with lines-as-triangle-strips with lower alpha at >> edges - >> I use it in my game project - but it'd be too slow with the amount of >> lines Stellarium >> draws (and regenerates each frame). >> >> MSAA would probably work, but I don't think there's enough >> benefit for cost (FPS) - and not sure how to go about it with Qt >> (needs specific video mode IIRC). You can try forcing MSAA in your >> driver if it supports it to see if there's a difference. >> >> One quick hack I can do now is to round line coordinates passed to >> drawLine() to integers. I'll try that but not sure if it will mess up >> something. >> >> >> Text antialiasing has nothing to do with GL - that's done by Qt >> (the text bug wasn't lack of antialiasing either - it was wrong >> alpha/color values - aliased text looks different) >> >> On 9/7/12, Ferdinand Majerech <kii...@gm...> wrote: >>> Text drawing has been fixed (pushed to glexperiment). >>> >>> On 9/7/12, Ferdinand Majerech <kii...@gm...> wrote: >>>> About the smallest lines vanishing: This is a rasterization issue >>>> (when they are smaller than one pixel, they aren't drawn), and it >>>> happens in pre-merge Stellarium as well. It might be possible to >>>> decrease it by using antialiasing, but it can't be completely >>>> eliminated. >>>> >>>> On 9/7/12, Ferdinand Majerech <kii...@gm...> wrote: >>>>> Could you send me a link to the landscape you're using? >>>>> >>>>> It seems the problems are much more clearly visible there. >>>>> >>>>> I'll look at text drawing, it might be due to different font >>>>> parameters, not sure. >>>>> >>>>> On 9/7/12, Georg Zotti <geo...@un...> wrote: >>>>>> >>>>>> On Fr, 7.09.2012, 04:07, Ferdinand Majerech wrote: >>>>>>> The warning spam seems to be caused by the Windows release build >>>>>>> workaround. >>>>>>> >>>>>>> The compilation error is weird; AFAIK clock_t is standard C++. >>>>>>> >>>>>>> Maybe it could be fixed by removing std:: and including <time.h> (C >>>>>>> include) >>>>>>> instead. >>>>>> >>>>>> Yes, indeed all that is needed under Windows/MinGW is in >>>>>> StelUtils.cpp: >>>>>> line 1067: #include <time.h> >>>>>> and >>>>>> line 1086: clock_t cpuTime = clock(); >>>>>> >>>>>> >>>>>> OK, the texturing issue in perspective mode is solved. Stereographic >>>>>> mode >>>>>> is also much cleaner now, the big zigzags are mostly gone, but still >>>>>> the >>>>>> older solution has "rounder" distortion. Also the shortest lines in >>>>>> the >>>>>> compass marks plugin appear to vanish sometimes at max fov, and its >>>>>> red >>>>>> text is less clear than in the older version (aliasing?). >>>>>> >>>>>> In order to not only test stereographic, in these images: >>>>>> https://dl.dropbox.com/u/30092392/stellarium-STG-cyl_11.4.png >>>>>> https://dl.dropbox.com/u/30092392/stellarium-STG-cyl_glexperiment5623.png >>>>>> >>>>>> you see a cylindrical view. The vertical pillars mark north and >>>>>> south, >>>>>> on >>>>>> the north pillar (stretching into the image at top left) there is a >>>>>> circular disk with a hole marking the north celestial pole. I tried >>>>>> to >>>>>> get >>>>>> the same view in both versions. The tesselation of the landscape is >>>>>> still >>>>>> coarser or maybe the previous mapping did more than linear >>>>>> interpolation, >>>>>> but in the glexperiment image the distortion of pillar and disk >>>>>> appear >>>>>> to >>>>>> be stronger, and the text from the compass marks grainier (a bit >>>>>> aliased). >>>>>> >>>>>> Concerning text rendition: The object info at top left seems OK, but >>>>>> star >>>>>> and constellation labels are also aliased. >>>>>> >>>>>> Kind regards, >>>>>> Georg >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Live Security Virtual Conference >>>>>> Exclusive live event will cover all the ways today's security and >>>>>> threat landscape has changed and how IT managers can respond. >>>>>> Discussions >>>>>> will include endpoint security, mobile security and the latest in >>>>>> malware >>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>>>> _______________________________________________ >>>>>> Stellarium-pubdevel mailing list >>>>>> Ste...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel >>>>>> >>>>> >>>> >>> >> > |
From: Ferdinand M. <kii...@gm...> - 2012-09-07 21:34:38
|
Simply increasing sphere resolution seems to fix the landscape, although we're now drawing about 3 times as many triangles for landscapes. (Here it turns 140FPS to 130FPS, but the slowdown should be much less on low FPS) Pushed, again to glexperiment. On 9/7/12, Ferdinand Majerech <kii...@gm...> wrote: > ...OK - at high FOVs the rounding actually messed up the lines quite a bit. > > I pushed a slightly more elaborate version (make the line longer in > its direction if > it's smaller than 1 pixel). > > On 9/7/12, Ferdinand Majerech <kii...@gm...> wrote: >> I pushed the change - line coordinates are rounded to integer and if the >> line >> size is zero, it's made longer to fill a pixel. Not perfect (due to >> aliasing lines sometimes >> appear one pixel up/down), but should work everywhere. >> >> CompassMarks, which previously drew its lines as circle arcs now draws >> it as plain lines - I couldn't see a difference in any projection, but >> it would be good to test that more. >> >> On 9/7/12, Ferdinand Majerech <kii...@gm...> wrote: >>> The line antialiasing seems to depend on GL_LINE_SMOOTH. >>> >>> This feature is supported on some GPUs/drivers and not supported on >>> others >>> - >>> for instance on my system (Radeon 6770) it doesn't work, so I get the >>> same result >>> with Stellarium 0.11.3 and current. >>> >>> GL_LINE_SMOOTH is currently enabled in GL1 backend, but it makes no >>> difference >>> on my system. From some googling, it sometimes requires particular >>> blend mode settings and this might vary between GPUs. >>> >>> TLDR - antialiasing lines through GL_LINE_SMOOTH is not portable. >>> You could do manual AA with lines-as-triangle-strips with lower alpha at >>> edges - >>> I use it in my game project - but it'd be too slow with the amount of >>> lines Stellarium >>> draws (and regenerates each frame). >>> >>> MSAA would probably work, but I don't think there's enough >>> benefit for cost (FPS) - and not sure how to go about it with Qt >>> (needs specific video mode IIRC). You can try forcing MSAA in your >>> driver if it supports it to see if there's a difference. >>> >>> One quick hack I can do now is to round line coordinates passed to >>> drawLine() to integers. I'll try that but not sure if it will mess up >>> something. >>> >>> >>> Text antialiasing has nothing to do with GL - that's done by Qt >>> (the text bug wasn't lack of antialiasing either - it was wrong >>> alpha/color values - aliased text looks different) >>> >>> On 9/7/12, Ferdinand Majerech <kii...@gm...> wrote: >>>> Text drawing has been fixed (pushed to glexperiment). >>>> >>>> On 9/7/12, Ferdinand Majerech <kii...@gm...> wrote: >>>>> About the smallest lines vanishing: This is a rasterization issue >>>>> (when they are smaller than one pixel, they aren't drawn), and it >>>>> happens in pre-merge Stellarium as well. It might be possible to >>>>> decrease it by using antialiasing, but it can't be completely >>>>> eliminated. >>>>> >>>>> On 9/7/12, Ferdinand Majerech <kii...@gm...> wrote: >>>>>> Could you send me a link to the landscape you're using? >>>>>> >>>>>> It seems the problems are much more clearly visible there. >>>>>> >>>>>> I'll look at text drawing, it might be due to different font >>>>>> parameters, not sure. >>>>>> >>>>>> On 9/7/12, Georg Zotti <geo...@un...> wrote: >>>>>>> >>>>>>> On Fr, 7.09.2012, 04:07, Ferdinand Majerech wrote: >>>>>>>> The warning spam seems to be caused by the Windows release build >>>>>>>> workaround. >>>>>>>> >>>>>>>> The compilation error is weird; AFAIK clock_t is standard C++. >>>>>>>> >>>>>>>> Maybe it could be fixed by removing std:: and including <time.h> (C >>>>>>>> include) >>>>>>>> instead. >>>>>>> >>>>>>> Yes, indeed all that is needed under Windows/MinGW is in >>>>>>> StelUtils.cpp: >>>>>>> line 1067: #include <time.h> >>>>>>> and >>>>>>> line 1086: clock_t cpuTime = clock(); >>>>>>> >>>>>>> >>>>>>> OK, the texturing issue in perspective mode is solved. Stereographic >>>>>>> mode >>>>>>> is also much cleaner now, the big zigzags are mostly gone, but still >>>>>>> the >>>>>>> older solution has "rounder" distortion. Also the shortest lines in >>>>>>> the >>>>>>> compass marks plugin appear to vanish sometimes at max fov, and its >>>>>>> red >>>>>>> text is less clear than in the older version (aliasing?). >>>>>>> >>>>>>> In order to not only test stereographic, in these images: >>>>>>> https://dl.dropbox.com/u/30092392/stellarium-STG-cyl_11.4.png >>>>>>> https://dl.dropbox.com/u/30092392/stellarium-STG-cyl_glexperiment5623.png >>>>>>> >>>>>>> you see a cylindrical view. The vertical pillars mark north and >>>>>>> south, >>>>>>> on >>>>>>> the north pillar (stretching into the image at top left) there is a >>>>>>> circular disk with a hole marking the north celestial pole. I tried >>>>>>> to >>>>>>> get >>>>>>> the same view in both versions. The tesselation of the landscape is >>>>>>> still >>>>>>> coarser or maybe the previous mapping did more than linear >>>>>>> interpolation, >>>>>>> but in the glexperiment image the distortion of pillar and disk >>>>>>> appear >>>>>>> to >>>>>>> be stronger, and the text from the compass marks grainier (a bit >>>>>>> aliased). >>>>>>> >>>>>>> Concerning text rendition: The object info at top left seems OK, but >>>>>>> star >>>>>>> and constellation labels are also aliased. >>>>>>> >>>>>>> Kind regards, >>>>>>> Georg >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> Live Security Virtual Conference >>>>>>> Exclusive live event will cover all the ways today's security and >>>>>>> threat landscape has changed and how IT managers can respond. >>>>>>> Discussions >>>>>>> will include endpoint security, mobile security and the latest in >>>>>>> malware >>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>>>>> _______________________________________________ >>>>>>> Stellarium-pubdevel mailing list >>>>>>> Ste...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel >>>>>>> >>>>>> >>>>> >>>> >>> >> > |