[Flightgear-devel] Low visibility issues
Vivian wrote a while ago: I've only tested Atmospheric Light Scattering for about 10 mins - and so far I've discovered that the Cat III scenario looks decidedly odd with a clear circle around my aircraft on the ground and black skies. I've taken a few hours to look into low visibility scenarios, and it's... complicated. It's not complicated to make a low visibility scenario, but it's complicated to make one which blends smoothly into the rest. So I would like to put this up for discussion as a list of options and get some feedback, with hopefully a decent picture of what we should do for 3.0. Status: Atmospheric Light Scattering is in my tests good to a visibility of ~1000 m - below one starts running into a number of increasingly severe isses - Vivian has encountered a few of them, but there are more. One option is - we can leave things as they are, with no additional complication and framerate cost. That's not unprecedented, the default rendering scheme doesn't deliver good results at high altitude, so if you fly Concorde, SR-71 Blackbird, X-15 or Vostok-1 you don't get to see correct earth curvature or the atmosphere below. We accept that the scheme simply can't handle this and trust that users which want to see plausible visuals at high altitude switch rendering scheme. Similarly, we could accept that anyone who wants to deal with visibility much below 1000 m would have to switch rendering scheme (and even make the Cat II and Cat III shown only optional dependent on what rendering scheme is selected for instance). Failing that, here's a list of issues which need to be addressed, options to fix them and projected costs: 1) Black skies: This may either be skydome unloading which I can't reproduce (but we should have a property preventing that, I don't know if it's set only by Advanced Weather, if not then this is a Basic Weather problem, not a shader issue) or actually the correct behaviour - if you have 50 m visibility in a 300 m thick fog layer, you're 6 attenuation length down, so the amount of light reaching the ground is just exp(-6) ~ 2 permille of that reaches the top of the layer. Which gives you a pretty dark sky. If dense fog is to appear white, it can't be a very thick layer. Options: a) If the skydome really unloads in Basic Weather, set the property correctly to prevent that. - no bad side effects 2) Clear circle around the plane: A while ago, I presented the problem that fog computations are done for the cockpit as well since they run over the same model shader as anything else, so we waste a lot of GPU time on something that is physically wrong (the cabin interior is not fogged) and results in a close-to-zero result in most cases. The advice I got was to use a distance cut to prevent these computations, so I used 40 m which is supposed to prevent the cabin interior in passenger planes from being affected. Of course, once the visibility gets just low enough, you see this distance cut as the circle Vivian describes. Options: a) We change this against a sliding distance cut not fogging for the closest 5% of the distance with some smoothing. This doesn't fix the issue but makes it a bit more subtle. - there may appear fogging computations on the cockpit, costing extra framerate, the cabin interior can still be fogged b) We fix it properly by using a different effect for all aircraft interior surfaces which never does fog computations (easy to do shader-side by passing a flag) - every aircraft needs to be modified and declare surfaces as interior or exterior for this to work 3) Terrain unloads: Currently the terrain manager unloads all terrain not in the visible range. This means that for 100 m visibility, hardly any terrain is loaded. This is bad in a number of ways: * terrain radar code (which'd be especially useful in low visibility conditions) breaks as it can't probe terrain elevations ahead * Advanced Weather can't get terrain elevation info and is unable to assemble a reasonable picture of the surrounding terrain * the light scattering shader does not longer know what color the fog should be when looking down, as the skydome representing the terrain does not have an altitude - so there appear mismatches between skydome standing for terrain and residual actual terrain (yes, terrain altitude and slope matters even if you can't see it - a completely fogged mountain can still block light!) * when passing a low visibility region (say a cloud with 100 m, as defined to make the cloudbase of thermals more realistic), there is no terrain left when coming out, and you see it re-loading which looks a bit silly Options: a) From a performance point of view, it makes no sense to massively unload terrain when the visibility drops over a short time - re-loading is far too expensive than just keeping it. So one could simply change the terrain manager to never unload terrain if it's closer than 20 km - this would basically
Re: [Flightgear-devel] Low visibility issues
On 20 Feb 2013, at 08:44, Renk Thorsten thorsten.i.r...@jyu.fi wrote: 2) Clear circle around the plane: A while ago, I presented the problem that fog computations are done for the cockpit as well since they run over the same model shader as anything else, so we waste a lot of GPU time on something that is physically wrong (the cabin interior is not fogged) and results in a close-to-zero result in most cases. The advice I got was to use a distance cut to prevent these computations, so I used 40 m which is supposed to prevent the cabin interior in passenger planes from being affected. Of course, once the visibility gets just low enough, you see this distance cut as the circle Vivian describes. Options: a) We change this against a sliding distance cut not fogging for the closest 5% of the distance with some smoothing. This doesn't fix the issue but makes it a bit more subtle. - there may appear fogging computations on the cockpit, costing extra framerate, the cabin interior can still be fogged b) We fix it properly by using a different effect for all aircraft interior surfaces which never does fog computations (easy to do shader-side by passing a flag) - every aircraft needs to be modified and declare surfaces as interior or exterior for this to work I would push for b) because it would also enable some other good things in the future; much easier to auto-hide internal features in exterior views, more potential to do a an early pass with internal geometry to fill Z, etc. 3) Terrain unloads: Currently the terrain manager unloads all terrain not in the visible range. This means that for 100 m visibility, hardly any terrain is loaded. This is bad in a number of ways: * terrain radar code (which'd be especially useful in low visibility conditions) breaks as it can't probe terrain elevations ahead * Advanced Weather can't get terrain elevation info and is unable to assemble a reasonable picture of the surrounding terrain * the light scattering shader does not longer know what color the fog should be when looking down, as the skydome representing the terrain does not have an altitude - so there appear mismatches between skydome standing for terrain and residual actual terrain (yes, terrain altitude and slope matters even if you can't see it - a completely fogged mountain can still block light!) * when passing a low visibility region (say a cloud with 100 m, as defined to make the cloudbase of thermals more realistic), there is no terrain left when coming out, and you see it re-loading which looks a bit silly Options: a) From a performance point of view, it makes no sense to massively unload terrain when the visibility drops over a short time - re-loading is far too expensive than just keeping it. So one could simply change the terrain manager to never unload terrain if it's closer than 20 km - this would basically fix all problems - someone needs to do it b) It would barely seem possible to adapt the terrain sampling routines to the visibility and to spend some extra performance to try to fix the color mismatches between skydome and real terrain - I don't know if it could be done, it's difficult to guess what altitude the terrain should have where it isn't - not a proper solution, just a bad fix a) is a trivial fix in the tile-manager, I think, and seems reasonable to me. The only issue will be setting a sensible minimum size, since I assume some people are brining the visibility down to reduce number of tiles loaded, and hence RAM use / frame-rate. James -- 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
On 20 Feb 2013, at 09:14, James Turner zakal...@mac.com wrote: I would push for b) because it would also enable some other good things in the future; much easier to auto-hide internal features in exterior views, more potential to do a an early pass with internal geometry to fill Z, etc. (Possibly including in-cockpit precipitation….) -- 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] Website update request
Hi Curt, Thanks for updating the website. I checked some pages more precisely for Japanese translation, and found many other *minor* issues. When you have a time, please check below. 1. http://www.flightgear.org/ Under the Find us on Facebook window, unintentional character string of [gpluspb id=111978238381658236898 size=badge] is displayed. 2. http://www.flightgear.org/download/aircraft-2-10-filterable/ W3C link checker says: Lines: 62, 209 http://www.flightgear.org/download/aircraft-2-10-filterable/ajax-loader.gif Status: 404 Not Found , whose lines are: 62 link rel=image_src href=ajax-loader.gif / 209 div id=loadingbr/Aircraft are being loaded#8230; img src=ajax-loader.gif style=box-shadow: none;//div 3. http://www.flightgear.org/about/features/ 3-1. JSBSim links to http://www.jsbsim.org/ which jumps to http://jsbsim.sourceforge.net/ So, http://jsbsim.sourceforge.net/ would be a better link for now. 3-2. LaRCsim links to http://techreports.larc.nasa.gov/ltrs/PDF/NASA-95-tm110164.pdf which has been disappeared. I guess this link should be deleted. 3-3. Multiple Displays section only shows its section name, and doesn't include any contents. 4. http://www.flightgear.org/download/ In Download Older Versions of FlightGear section, Mac OS version would be better to write something like: - v2.8 and later for Mac OS X: [Mirror1] [Mirror2] [Mirror3] - v2.6 and before for Mac OS: http://macflightgear.sf.net 5. http://www.flightgear.org/download/scenery/ Via BitTorrent links to http://terasaur.org/item/show/flightgear-v2-8-0/6584 Correct link would be http://terasaur.org/item/show/flightgear-v2-10/6663 6. http://www.flightgear.org/download/mirror/ Some mirrors seem to be a little bit old. 6-1. http://flight.webersiedlung.at/ may need to be deleted from the list. 6-2. http://ftp.icm.edu.pl/packages/flightgear/ may need to be added to the list. 7. http://www.flightgear.org/download/main-program/ 7-1. Does FlightGear supports Windows 8? If so, a section of Windows (XP, Vista, 7) would be better to write as Windows (XP, Vista, 7, 8). 7-2. In The Attic section, many broken links are found: [Mirror1] [Mirror2] [Mirror3] for Fedora. http://pardus.org.tr/eng/index.html http://paketler.pardus.org.tr/pardus-2007/flightgear-0.9.10-3-4.pisi http://paketler.pardus.org.tr/pardus-2007/flightgear-data-base-0.9.10-2-2.pisi http://www.mechanics.citg.tudelft.nl/~everdij/nekoware/current/neko_flightgear-0.9.9.tardist Cheers, Toshi -- 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] FlightGear 2.10.0 release on Ubuntu
its works now.. thanks ;- pete -- 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
Thorsten wrote -Original Message- From: Renk Thorsten [mailto:thorsten.i.r...@jyu.fi] Sent: 20 February 2013 08:44 To: FlightGear developers discussions Subject: [Flightgear-devel] Low visibility issues Vivian wrote a while ago: I've only tested Atmospheric Light Scattering for about 10 mins - and so far I've discovered that the Cat III scenario looks decidedly odd with a clear circle around my aircraft on the ground and black skies. I've taken a few hours to look into low visibility scenarios, and it's... complicated. It's not complicated to make a low visibility scenario, but it's complicated to make one which blends smoothly into the rest. So I would like to put this up for discussion as a list of options and get some feedback, with hopefully a decent picture of what we should do for 3.0. Status: Atmospheric Light Scattering is in my tests good to a visibility of ~1000 m - below one starts running into a number of increasingly severe isses - Vivian has encountered a few of them, but there are more. One option is - we can leave things as they are, with no additional complication and framerate cost. That's not unprecedented, the default rendering scheme doesn't deliver good results at high altitude, so if you fly Concorde, SR-71 Blackbird, X-15 or Vostok-1 you don't get to see correct earth curvature or the atmosphere below. We accept that the scheme simply can't handle this and trust that users which want to see plausible visuals at high altitude switch rendering scheme. Similarly, we could accept that anyone who wants to deal with visibility much below 1000 m would have to switch rendering scheme (and even make the Cat II and Cat III shown only optional dependent on what rendering scheme is selected for instance). At the minimum we need to avoid FG just looking broken, so making the Cat II III dependent on rendering scheme would work. Better to fix it properly though Failing that, here's a list of issues which need to be addressed, options to fix them and projected costs: 1) Black skies: This may either be skydome unloading which I can't reproduce (but we should have a property preventing that, I don't know if it's set only by Advanced Weather, if not then this is a Basic Weather problem, not a shader issue) or actually the correct behaviour - if you have 50 m visibility in a 300 m thick fog layer, you're 6 attenuation length down, so the amount of light reaching the ground is just exp(-6) ~ 2 permille of that reaches the top of the layer. Which gives you a pretty dark sky. If dense fog is to appear white, it can't be a very thick layer. Options: a) If the skydome really unloads in Basic Weather, set the property correctly to prevent that. - no bad side effects 2) Clear circle around the plane: A while ago, I presented the problem that fog computations are done for the cockpit as well since they run over the same model shader as anything else, so we waste a lot of GPU time on something that is physically wrong (the cabin interior is not fogged) and results in a close-to-zero result in most cases. The advice I got was to use a distance cut to prevent these computations, so I used 40 m which is supposed to prevent the cabin interior in passenger planes from being affected. Of course, once the visibility gets just low enough, you see this distance cut as the circle Vivian describes. Options: a) We change this against a sliding distance cut not fogging for the closest 5% of the distance with some smoothing. This doesn't fix the issue but makes it a bit more subtle. - there may appear fogging computations on the cockpit, costing extra - framerate, the cabin interior can still be fogged This would be acceptable - I think it's the hard demarcation which catches the eye and looks unrealistic. b) We fix it properly by using a different effect for all aircraft interior surfaces which never does fog computations (easy to do shader-side by passing a flag) - every aircraft needs to be modified and declare surfaces as interior - or exterior for this to work This would be nice - I went go to great lengths to hide exterior surfaces in interior views to improve frame rates when these were a big issue. I think they might be culled anyway nowadays. However, there might be other advantages in doing this. I'd be happy to modify my handful of ac to accommodate this, others with a shed load might not be so happy. 3) Terrain unloads: Currently the terrain manager unloads all terrain not in the visible range. This means that for 100 m visibility, hardly any terrain is loaded. This is bad in a number of ways: * terrain radar code (which'd be especially useful in low visibility conditions) breaks as it can't probe terrain elevations ahead * Advanced Weather can't get terrain elevation info and is unable to assemble a reasonable picture of the surrounding terrain * the light scattering shader does not longer know what
[Flightgear-devel] Issues with windows build crashing on startup.
Hey everybody, Thanks for all of your great work! I'm new to this project, but very impressed so far! My issue is on my Windows 7 box... I downloaded all the git sources over the weekend and got it building and running just fine on my Ubuntu machine (12.10) but I'm having issues running my build in Windows. I got everything to compile (finally) but when it came to run time I realized I did not have any of the dlls that should live next to the executable, so I tried grabbing them all from my flightgear 2.8.0.5 binary install. Of course, it turned out those were all outdated, so I grabbed all new ones out of the OSG and libsvn projects. That covered almost all of the dlls in use, with the exceptions of iconv.dll, gettextlib.dll, gettextsrc.dll, the msvcr msvcp dlls, and the PocoFoundation and PocoNet dlls. (I think that's all of them anyway.) The really weird thing is I built it in debug, and when it crashed it was in msvcr90.dll... I have two versions of msvcr in my game directory actually, but they are msvcr71 and msvcr100. I searched around and found several copies of msvcr90 in my windows system folders, but they seemed to be mostly in archive folders, while in my system32 and system64 folders I have only msvcr100 and 110 versions. Does anyone know why or where windows would be finding msvcr90.dll instead of the one sitting right next to the program or in the system32 64 folders? Also, would there happen to be any kind of official stockpile of dlls to grab from when the base project updates one of its dependencies? Any advice would be much appreciated. Chris Calef BrokeAss Games, LLC -- 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
Vivian: There seem to be significant issues with the loading of terrain. If we load too much, the frame rate drops, if we load too little it looks poor, and AG radar doesn't work. Actually. We don't load enough for AG radar to work realistically in any case. We probably need something between 50 and 100 k for this , and we're unlikely to accommodate the memory requirements of this, at least for 32 bit systems. James: a) is a trivial fix in the tile-manager, I think, and seems reasonable to me. The only issue will be setting a sensible minimum size, since I assume some people are brining the visibility down to reduce number of tiles loaded, and hence RAM use / frame-rate. Okay, here are some experimental facts on my old 32bit system. I had a GeForce 8600M and 4 GB of memory with a 32bit Linux installation. With this setup, without using random vegetation and random buildings, I could render terrain with 250 km visibility range (I patched the binary for that purpose, otherwise it gets clipped at 120 km) without any problems in default scenery. I could easily do 120 km in custom scenery, and even with vegetation and buildings on 55 km were quite safe in custom scenery. So it's not true that fixing a minimum visibility of 20 km we'd run into 32bi memory issues. As for framerate, I'd guess that GPUs which are so old that they have real issues processing the vertex count of 20 km scenery fast enough are hit also hard by the fragment shader - but fragment shader load is independent of the visibility range. There are lots of forum users who have issues with low framerate - about anything (no random vegetation, no shaders, no random buildings, no complex planes, no AI traffic, no 3d clouds...) seems to help more than to get visibility down. I'm not aware of any single user who uses less than 20 km visibility because the framerate is not acceptable otherwise, and I have never seen anyone suggest this to users. Since vertex count goes quadratically in visibility, it matters a lot if you use 50 or 120 km, but not so much if you use 10 or 20. Nevertheless, at some point my suggestion would be to create a commandline-enabled legacy mode for really old hardware which gives you access to a minimal setup in which terrain radars, Advanced Weather Co are disabled, but define the default setup of FG in such a way that terrain interaction based stuff can make assumption about how much terrain is loaded. For a halfway decent system, 20 km should not be any problem if I could run 250 km on a 5-year old laptop, and I think we can at some point make that default assumption and have a fallback option in case it doesn't work. * 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
[Flightgear-devel] Regional texturing project - Cntrl. Alt. Click
Hey guys, I have been trying to work on some textures for NZ, but I cannot find the land-class via cntrl.alt.click. I have tried multiple aircraft, can anyone help? Spitfirebruce21. Lachlan. -- 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] Regional texturing project - Cntrl. Alt. Click
Hey guys, I have been trying to work on some textures for NZ, but I cannot find the land-class via cntrl.alt.click. I have tried multiple aircraft, can anyone help? It's an ufo feature... * 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
Re: [Flightgear-devel] Regional texturing project - Cntrl. Alt. Click
Hey thorsten, located the problem, I had an old version of the UFO, but Which part do I use to put in the materials... -- 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
