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 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 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. Thanks, * Thorsten P.S.: Please no destructive comments along 'if you would have done it my way...' unless you're sure you understand the issue properly. ------------------------------------------------------------------------------ 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
