Re: [Flightgear-devel] Low visibility issues
Emilian wrote On Saturday, February 23, 2013 07:08:41 Renk Thorsten wrote: A lot of stuff, mostly deflecting the discussion to other irelevant points * Thorsten While I should know better than to answer to this, as it will again get deflected to other areas, let's imagine ourselves a simple scenario: Let's say I'm an average user with a 32bit system, I can barely find my way through the maze of menus and dialogs flightgear presents to me, and I want to use this more advanced weather simulation engine. After I accidentaly find out how to enable it (it's hidden under a rather confusing radio-button selection Model overall weather conditions based on metar), great, select Fair weather scneario, Apply, OK, let's go flying. I muck around, wonder at the nice sky/clouds, notice that my visibility improved somewhat, then bam after 15 minutes flightgear crashes, uhm.. oohh, why did that happen? That didn't happen before? All I did was change the way the weather is interpreted... What's wrong here??? Well, now let's see what actually happens in a default flightgear instalation (all settings are from preferences.xml, and Environment/local-weather- defaults.xml) -trees are enabled by default -default visibility with Fair weather is ~16km local weather comes in -and sets a default value for max visibility of 120km (o.O), ok, that's a bit far, but in practice I see that's actually hovering in the 40km range (+-10km based on altitude). (roughly 3x more than the default) So in the default scheme we load 9 tiles at startup, then we keep loading tiles in the direction we're traveling, and those initial tiles remain resident in the tile cache for a while (in case you decide to double back). But let's stay with the startup condition. when you ramp up the visibility to 40km you demand 3 extra rings of tiles to be loaded. That would give you at least 69 tiles loaded (81 if the rings are square). So that's an instant increase of 7-9x the memory requirements of the terrain + objects + trees (tres being the largest contributor here), just because you click an option that says it just _interprets_ the METAR string differently. Do you think that's an expected result? I don't. Well, our average user might have read the manual, might have mucked about with the visibility setting before, and he remeber that all things being the same, visibility is what impacts performance/memory the most, so he decides to try again, this time trying to use z/Z to limit how far the visibility goes, maybe he gets lucky and it won't crash again, but he's in for a surprise... z/Z doesn't work... You might argue that he should know better, go into the advanced settings dialog, figure out what all those sliders and selection boxes do, etc, etc... But remeber, our user is an average one, he wants things to just work (with time, he might find a use for the more advanced configuration stuff, but for now he's not interested, he just want to click something, and be done with it), The z/Z case above might be a lucky one where he might have read the manual. The problem is not with Advanced weather in itself, the problem is in the details of a part of it, themost important part from the user POV. Your approach might work, given unlimited resources, but as it is Flightgear has to run on a variety of puny little desktop/laptop machines. You have already implemented half of the control, is it so hard to implement the rest and provide a system that's consistent with the rest? Yes it breaks the real world scheme, but this is a simulation, we lie, carefully crafted lies, that give a global impression of truth, of copying the real world behaviour, but in the end they are lies. Fog/view-distance is one of those lies, they need just be plausible, not a faithful representation of the real world (and a faithful representation of the real-world is practically impossible given the current state of the technology). You are comfortable with abdicating from that when it suits you, but where it really matters you defend the minute detail faithfull representation of the real world scheme vigorously... Don't you think thre's something amiss here? As someone said in another thread, there are various techniques that are not constrained by the real-time requirement, that do a pretty good job of giving you real results, but their place is not here. Here we have to do our best to trick the mind, while doing that as fast as possible, with a reasonable usage of resources. Just because you can set visibility to 1000km doesn't mean you should, just because you can shove a lot of data into a shading scheme and get back photoreal results doesn't mean you should, if said results reduce performance, increase the probability of running out of memory, etc. You'll argue again with the IAR as an example. Well, take a look at those numbers again, and you'll see that for the amount of detail it
Re: [Flightgear-devel] download_and_compile w, x and v options
Here are two patches and a combined patch for both. These patches include changes to the help. patch-1.9-8-xv.patch adds the x and v options for debugging. patch-1.9-8-w.patch adds the w option, w standing for Where to Build patch-1.9-8-wxv.patch combines both changes. I'm in the process of working out how to do a variety of builds for testing the download and compile script. The x and v options help in that regard. The w option allows me to test different download_and_compile builds with different options in different directories from a single copy of download_and_compile.sh Like so: download_and_compile.sh -w master ALL download_and_compile.sh -w master_e -e ALL # new event model download_and_compile.sh -w master_r -r ALL # openrti download_and_compile.sh -w master_er -er ALL # both However just using a different directory is a bit inefficient. It results in multiple copies of git that are separate clones of the gitorious repository. Anders made a suggestion on IRC I'm going to follow up on. You can have local git clones that share the same .git/* files via file links I think that means we could have several local clones of a single local git repository. The various local clones would support building multiple branches and versions, without having to sync each clone independently with gitorious. The script would still work just as well for someone who just wanted to compile a single version -Pat Note for those reading on the devel list, the patches are based on download_and_compile.sh version 1.9-8, as of today, that's available from http://assistenza.larasrl.net/brisa/fgfs/download_and_compile.sh --- download_and_compile-1.9-8.sh 2013-02-24 10:23:20.288494978 -0500 +++ download_and_compile-w.sh 2013-02-24 11:45:41.688504514 -0500 @@ -39,6 +39,7 @@ WHATTOBUILD= WHATTOBUILDALL=( PLIB OSG OPENRTI SIMGEAR FGFS DATA FGRUN ) +COMPILE_BASE_DIR=. UPDATE= STABLE= @@ -56,7 +57,7 @@ WITH_EVENT_INPUT= WITH_OPENRTI= -while getopts suhc:p:a:d:r:j:O:gei OPTION +while getopts suhc:p:a:d:r:j:O:geiw: OPTION do case $OPTION in s) @@ -98,6 +99,9 @@ i) WITH_OPENRTI=-D ENABLE_RTI=ON ;; + w) + COMPILE_BASE_DIR=./$OPTARG + ;; ?) @@ -191,6 +195,7 @@ echo * -O XAdd -OX to the make compilation default=None echo * -r y|n y=reconfigure programs before compiling them n=do not reconfigure default=y echo * -s compile only last stable known versions default=y + echo * -w run the build in a subdirectory default=current directory exit fi @@ -342,18 +347,7 @@ echo OK $LOGFILE fi - - - - - - - - -COMPILE_BASE_DIR=. - - - +mkdir -p $COMPILE_BASE_DIR || echo Unable to create directory $COMPILE_BASE_DIR #cd into compile base directory cd $COMPILE_BASE_DIR --- download_and_compile-1.9-8.sh 2013-02-24 10:23:20.288494978 -0500 +++ download_and_compile-wxv.sh 2013-02-24 11:42:48.096504179 -0500 @@ -18,8 +18,8 @@ # along with this program. If not, see http://www.gnu.org/licenses/. -VERSION=1.9-8 - +VERSION=1.9-8-wxv +echo download_and_compile.sh version: $VERSION #COMPILE GIT FGFS ### @@ -39,6 +39,7 @@ WHATTOBUILD= WHATTOBUILDALL=( PLIB OSG OPENRTI SIMGEAR FGFS DATA FGRUN ) +COMPILE_BASE_DIR=. UPDATE= STABLE= @@ -56,7 +57,7 @@ WITH_EVENT_INPUT= WITH_OPENRTI= -while getopts suhc:p:a:d:r:j:O:gei OPTION +while getopts suhc:p:a:d:r:j:O:geiw:xv OPTION do case $OPTION in s) @@ -98,6 +99,15 @@ i) WITH_OPENRTI=-D ENABLE_RTI=ON ;; + w) + COMPILE_BASE_DIR=./$OPTARG + ;; + x) + set -x + ;; + v) + set -v + ;; ?) @@ -187,11 +197,13 @@ echo * -p y|n y=download packages n=skip download packages default=y echo * -c y|n y=compile programs n=do not compile programs default=y echo * -d y|n y=fetch programs from internet (cvs, svn, etc...) n=do not fetch default=y - echo * -j XAdd -jX to the make compilation default=None - echo * -O XAdd -OX to the make compilation default=None + echo * -j XAdd -jX to the make compilation default=None + echo * -O XAdd -OX to the make compilation default=None echo * -r y|n y=reconfigure programs before compiling them n=do not reconfigure default=y echo * -s compile only last stable known versions default=y - + echo * -w run the build in a subdirectory default=current directory + echo * -x set the -x option for script debugging not set by default + echo * -v set the -x option for script debuggingnot set by default exit fi @@ -342,18 +354,7 @@ echo OK $LOGFILE fi - - - - - - - - -COMPILE_BASE_DIR=. - - - +mkdir -p $COMPILE_BASE_DIR || echo Unable to create directory
Re: [Flightgear-devel] Low visibility issues
On Sunday 24 February 2013 18:46:08 Vivian Meazza wrote: I'm probably a day late and a dollar short here - but try as I will so far I've failed to find a visibility slider under environment-weather. It's probably staring me in the face - but could someone point it out to me? In the Weather dialog: Model overall weather conditions based on METAR Advanced Settings Thermic Visibility and Settings Max visibility Stefan -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Air-to-air refuelling enhancement
Hi All, I've just committed some small changes to the AI air-to-air refueling function: 1) Added support for multiple tankers of each type, selectable through the AI-Tankers GUI. Tankers are now defined in AI/tankers.xml. 2) Added an A-4F buddy tanker. 3) Enhanced the UI to allow the user to set the speed of the tanker, and the radius at which contact is made. Note that this is based on the origin of tanker and user. As a future enhancement I want to add offsets to indicate the position of the refuelling probe/receiver on the user aircraft, and the location of the boom/drogue on the tanker. 4) Added a user-toggled function to display messages when contact i made or lost. Some aircraft don't seem to have any obvious cockpit indicator that refuelling is in progress, and we don't currently animate the probe being in the drogue :) 5) Added maximum fuel flow definitions to both the tanker and receiver. While the KC-135 supports flow of 6000 lbs/min, smaller tankers (such as the A4-F buddy tanker) only provided ~1300 lbs/min. the actual fuel flow is taken as the minimum of the two. Note that the maximum fuel flow affects both AI and MP tankers. I've been unable to test with the latter, but have set a default to ensure backwards compatibility. Feedback welcome as always. -Stuart -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] download_and_compile w, x and v options
On Sun, 24 Feb 2013 13:44:54 -0500, Pat wrote in message 20130224134454.6bd9636c@spinnaker: Here are two patches and a combined patch for both. These patches include changes to the help. patch-1.9-8-xv.patch adds the x and v options for debugging. patch-1.9-8-w.patch adds the w option, w standing for Where to Build patch-1.9-8-wxv.patch combines both changes. ..alongside those, I like to see _what_ I build|t _when_, so I auto-rename my logs, and I believe -s should build 2.10 now: arnt@celsius:~/FG-git$ ll download_and_compile-1.9-8a.patch \ md5sum download_and_compile-1.9-8a.patch -rw-r--r-- 1 arnt arnt 1441 Feb 24 23:24 download_and_compile-1.9-8a.patch a342d108f121322f076ef7de063ab1e4 download_and_compile-1.9-8a.patch arnt@celsius:~/FG-git$ I'm in the process of working out how to do a variety of builds for testing the download and compile script. The x and v options help in that regard. The w option allows me to test different download_and_compile builds with different options in different directories from a single copy of download_and_compile.sh Like so: download_and_compile.sh -w master ALL download_and_compile.sh -w master_e -e ALL # new event model download_and_compile.sh -w master_r -r ALL # openrti download_and_compile.sh -w master_er -er ALL # both However just using a different directory is a bit inefficient. It results in multiple copies of git that are separate clones of the gitorious repository. Anders made a suggestion on IRC I'm going to follow up on. You can have local git clones that share the same .git/* files via file links ..you feed 4 build trees from 1 git clone, how? A du -sch $git-n-build-trees on them all? I think that means we could have several local clones of a single local git repository. The various local clones would support building multiple branches and versions, without having to sync each clone independently with gitorious. ..you only do an e.g. git branch 2.10 ;git checkout, and no git pull??? The script would still work just as well for someone who just wanted to compile a single version -Pat Note for those reading on the devel list, the patches are based on download_and_compile.sh version 1.9-8, as of today, that's available from http://assistenza.larasrl.net/brisa/fgfs/download_and_compile.sh -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. --- download_and_compile-1.9-8.sh 2013-02-18 22:57:33.0 +0100 +++ download_and_compile-1.9-8a.sh 2013-02-22 20:56:26.878177657 +0100 @@ -18,7 +18,7 @@ # along with this program. If not, see http://www.gnu.org/licenses/. -VERSION=1.9-8 +VERSION=1.9-8a #COMPILE GIT FGFS @@ -35,6 +35,9 @@ LOGFILE=compilation_log.txt +# LOGFILE=compiled_$*_ +STTL=$(date +%F+%T-%Z ) +# WTL=$($* |tr [:blank:] + ) LOGSEP=*** WHATTOBUILD= @@ -140,7 +143,7 @@ OSG_STABLE_REVISION=http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-3.0.1; # common stable branch for flightgear, simgear and fgdata -FGSG_STABLE_GIT_BRANCH=release/2.8.0 +FGSG_STABLE_GIT_BRANCH=release/2.10.0 FGRUN_STABLE_GIT_BRANCH=master OPENRTI_STABLE_GIT_BRANCH=release-0.3 @@ -151,9 +154,9 @@ OPENRTI_UNSTABLE_GIT_BRANCH=master # stable GIT revision: release tag -SIMGEAR_STABLE_REVISION=version/2.8.0-final -FGFS_STABLE_REVISION=version/2.8.0-final -FGFS_DATA_STABLE_REVISION=version/2.8.0-final +SIMGEAR_STABLE_REVISION=version/2.10.0-final +FGFS_STABLE_REVISION=version/2.10.0-final +FGFS_DATA_STABLE_REVISION=version/2.10.0-final OPENRTI_STABLE_REVISION=OpenRTI-0.3.0 # FGCOM @@ -1506,7 +1509,7 @@ fi fi - +mv -vf $LOGFILE compiled_$WTL_$*_$STTL echo To start fgfs, run the run_fgfs.sh file echo To start terrasync, run the run_terrasync.sh file -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Low visibility issues
Stefan Seifert wrote On Sunday 24 February 2013 18:46:08 Vivian Meazza wrote: I'm probably a day late and a dollar short here - but try as I will so far I've failed to find a visibility slider under environment-weather. It's probably staring me in the face - but could someone point it out to me? In the Weather dialog: Model overall weather conditions based on METAR Advanced Settings Thermic Visibility and Settings Max visibility Got it - thanks - as I said staring me right in the face. So, am I right in thinking that we have 3 different ways of setting the vis: 1. z/Z - works with Basic Weather - sets the vis directly. Does not work with Advanced Weather, but is still available when that option is selected and looks as if it should work. 2. Slider in Advanced Weather - Advanced Settings - sets a max value . The displayed vis in the min value of this and the value derived by Advanced Weather. (Is this true? I'm only inferring this). 3. Checkbox named realistic visibility in Advanced Weather - Advanced Settings. What does this do? I can't see any effect here. I used the old terms Basic/Advanced Weather, but I note that these have disappeared from the GUI. How would the user know why or when he would chose ether option? Scope for some rationalisation here I would think. I'm extremely disappointed to see that while I was off on a short holiday that this discussion has deteriorated to the point that one of a valued developers feels that he can no longer contribute to FG. Vivian -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 2.10 Build error
Hi, Started a new build for FG-2.10; last build was 2.6 Problem right out of the gate with simgear Following error output [castle@rampart simgear]# cmake ../simgear -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done CMake Error at bucket/CMakeLists.txt:2 (include): include could not find load file: SimGearComponent CMake Error at bucket/CMakeLists.txt:7 (simgear_component): Unknown CMake command simgear_component. CMake Warning (dev) in CMakeLists.txt: No cmake_minimum_required command is present. A line of code such as cmake_minimum_required(VERSION 2.8) should be added at the top of the file. The version specified may be lower if you wish to support older CMake versions for this project. For more information run cmake --help-policy CMP. Running with cmake 2.8.2. where do I find SimGearComponent? Did I miss a step before cmake? Or something from 2.8? Regards John -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] interface flightgaer with vb
It's all in C++. Either try that or do some easy beginner stuff in VB alike a clock etc. :-) --- On Mon, 2/25/13, akram mohammed akramka...@hotmail.com wrote: From: akram mohammed akramka...@hotmail.com Subject: [Flightgear-devel] interface flightgaer with vb To: flightgear-devel@lists.sourceforge.net Date: Monday, February 25, 2013, 7:01 AM i need help how to interface flightgear with visual basic gui project , like starting engine and landing gear from vb,in detail because i am beginner. -Inline Attachment Follows- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb -Inline Attachment Follows- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Low visibility issues
2. Slider in Advanced Weather - Advanced Settings - sets a max value . The displayed vis in the min value of this and the value derived by Advanced Weather. (Is this true? I'm only inferring this). True. 3. Checkbox named realistic visibility in Advanced Weather - Advanced Settings. What does this do? I can't see any effect here. It changes the internal model used to derive visibility as a function of altitude. In reality, once you clear the lowest convective layer which is normally pretty hazy, the visibility often goes to hundreds of kilometers. The checkbox largely controls where Advanced Weather would set it - if you don't check it, visibility increases more slowly with altitude, if you check it, you will in many weather situations open the visibility to 120 km (or whatever max. value you specified) a few hundred meters above the lowest convective layer. Basically, checking the box means 'model my visibility as real as you can do within the FG framework' and unchecking it 'model it halfway realistically, but keep an eye on performance and memory issues'. I used the old terms Basic/Advanced Weather, but I note that these have disappeared from the GUI. How would the user know why or when he would chose ether option? Scope for some rationalisation here I would think. The design idea behind the current GUI was that the user should no longer be presented with two different weather options to choose from, but just see a single GUI which controls weather. If that is still the idea, it works remarkably well. If you have an idea for a more descriptive text, please let us know. This should be easily fixable by having the atmospheric scattering checkbox set the value of: /sim/rendering/minimum-sky-visibility to 0, and returning it to the default value when unchecked. Is there an xml way to do that? I know how to do it with a listener from Nasal, but that seems like an overkill... Or am I thinking too complicated? In other matters, I was able to make some progress. I've replaced the hard cutoff by a smoothed, sliding cutoff, so the circle is gone. Fogging clouds properly turns out a no-go because the fog color is way too expensive to obtain, but it occurred to me that one can cheat here - rather than fading to fog color, one can fade clouds to transparent for distances larger than 2-3 times visibility. That gives the desired disappearance of the cloud layer in poor visibility from below (I have to check if it has any undesirable side effects in situations with high visibility). It's also neat because the fragment shader will drop transparent pixels - so performance of fading to transparent is better than fading to fog color. Since there are still unspecified but serious concerns about loading 20 km of terrain, I've hacked my way around it... so please drop the idea. This is what CAT IIIb now results in: http://users.jyu.fi/~trenk/pics/catIIIb.jpg There are some remaining issues. Specular light is way too strong in the picture, I have to tune that down (that's also the case in default rendering). As you can see, the lights are way too visible for CATIIIb - it took me 5 minutes to figure out that they are actually 100% fogged, but since they are fogged in the default scheme for some reason, the fog color is much brighter, and so it seems as if they were unfogged. Does anyone know where the various runway and other lights enter the rendering pipeline and what should be done to get a shader to process them? Can they be assigned to model-default, or do they need extra treatment? A similar issue is the sun (which is never fogged). It used to be hidden by the clouds, but if we fade the clouds to transparent rather than to fog color, that no longer works. In the default scheme, I think the sun becomes hidden when the skydome unloads - but that doesn't work either, the scheme needs the skydome. So we'd need some control over what we show of the sun - that's also relevant if the sun is below the horizon, but the horizon terrain is rendered by the skydome - in this case the sun can be seen through the 'terrain'. Does anyone have an idea how we could control the appearance of the sun? * Thorsten -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
