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
