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 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 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. As an aside, with custom detailed scenery, memory is already marginal for 32 bit systems, reading comments of the forum. Adrian Musceac has developed a patch which employs an inner and out cache for the terrain - I wonder if this might help? What happened to that one? > 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 > > 4) Clouds are not fogged consistently. I am not sure how one would define > consistent fogging of clouds, as in a low visibility scene the clouds basically > *are* identical with the fog, but in practice we probably don't want to show > any glimpse of the cloud layer above but rather have a completely grey > screen at very low visibility (?). > > a) Fix it properly, i.e. fog clouds in the same scheme that treats skydome and > terrain > -> This costs 50% of the framerate you get with a nice Cu cloud sky and > -> probably ~75% with an overcast sky, *regardless* what the visibility > -> actually is > > b) One can use the fact that the weather system knows the relative position > of viewpos and cloud layer, so the weather system can pass a decent > approximation to the real computation to the cloud shader which uses this > information > -> This would break Basic Weather in Atmospheric Light Scattering, > -> there's no way a reasonable default value can be set for this > -> parameter, and someone has to fix up Basic Weather then > > c) Improve the light computations so that clouds blend better against the > pretty dark fog - this woudn't make them invisible, but would de-emphasize > them > -> costs some extra framerate in the cloud shader, which is a bottleneck > -> to begin with > > 5) There's a couple of Advanced Weather issues (interpolated visibility vs. > effect volume visibility vs. ground visibility validity selection, modelling or the > vertical visibility gradient,...) which are not working fully consistent (for > instance, currently setting an effect volume with 1000 m visibility sets the > visibility to that value even if the visibility outside interpolates to 200 m - > while this is correct as far as the code goes, this is not necessarily the > intended behaviour and it would seem nice to enter a minimum statement > somewhere). > -> I simply need to fix those > > So, to summarize, there are a number of fixes I could do, ranging from > proper solutions to de-emphasizing a problem, many of them would cost > performance no matter what the visibility range actually is. Opinions please if > fixes are desirable and if so, which ones. > Proper solutions would be nice, but where these cost too much or are impractical, I would go along with hiding the problem. Just so the view out of the window looks plausible. 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
