> Often airports are in or > near very scenery-intensive areas and reducing visibility can help a lot > in making the sim run usably for take-off, whereas once you're up and > away it's nice to be able to open the view back up again for > cross-country flying.
This is applying a sledgehammer to a problem which asks for a screwdriver. Performance management with reducing visibility throws everything out - terrain mesh, static models, trees, random buildings,... As a result the load arriving at the vertex shader drops. First of all, this kind of performance management is bound to fail if you're not limited by the performance of the vertex shader - if the fragment shader is the bottleneck (as in the two more modern rendering schemes where we increasingly shift load to the more powerful fragment pipelines on modern GPUs) then you may change the number of vertices drastically, but the number of screen pixels covered by terrain and models changes insignificantly and the fragment load stays what it is. When I run Atmospheric Light Scattering on high detail, then my framerate is pretty much independent of visibility. I haven't tried it, but I am fairly sure the same is true for deferred rendering (Rembrandt) where the vertex stage of rendering is trivial and all the work is done per pixel. In fragment-dominated rendering schemes, the load of faraway models pretty much scales with the number of screen pixels they cover - so unloading them may free memory, but doesn't really change framerate. Also, if you're limited by cloud rendering performance (which unfortunately seems to be the case in many situations) changing visibility doesn't help you - only cloud draw range will do the trick. It may also be that the performance isn't limited by the GPU performance at all but by expensive Nasal (none of mine obviously :-) ) or terrain-probing features like a ground radar - in which case you can play with the visibility all day long and will not see any effect. So let's first note that performance management by visibility is only effective if certain conditions are met, likely to be ineffective in our modern rendering schemes and we should neither encourage it nor recommend it in general nowadays - performance scaling depends more often on the fine-print of what shaders you're running and what your GPU can do. If you nevertheless happen to be dominated by the vertex shader load, you'll notice that most of the load in scenery-heavy areas comes from models, not from the terrain. The fact that you need to get rid of models by drastically changing visibility indicates that the LOD range isn't configured properly, so what you actually need is a way to unload models at larger distance, not to increase visible fog and to unload terrain. I don't know if the LOD menu settings are honoured for static models and random objects (?) - but I'd give that a try before claiming that a visibility-changing key is needed for memory management. Of course, using a cheaper model shader may solve the trick equally well if models cause the main performance drain in the vertex shader. Before getting my current computer, I have had quite some performance limitations in the end and I've done a lot of tweaking of shaders and customizing my settings. The one thing I've never needed is adjusting visibility on the fly - it didn't ever help. All I needed is a safe limit to avoid going over the 32bit memory limit. > whereas once you're up and > away it's nice to be able to open the view back up again for > cross-country flying. Well, but can't you do it from the menu (if you must do it at all) ? > Maybe if that happened automatically somehow this > would become unimportant, but for now I think a lot of people rely on it. Well, we can safely rule out all people running Advanced Weather (because the trick doesn't work), Atmospheric Light Scattering at high detail and possiby Rembrandt (because there the fragment shader gets the work and dropping vertex load is not really effective) and probably the majority of people using online weather (what's the point of using online weather if you cheat with the visibility later). I don't think that leaves a lot of people. > I can't believe you're suggesting removing the FoV keybinding though! > I've used that for "zoom" in 3d cockpits for about as long as we've had > the things, completely essential in my opinion. I know it's not > strictly speaking "zoom" but it works, and is very quick and natural to > use, too. I actually agree with that, based on the reasoning that focusing on an instrument is something you can do in a real cockpit. Although personally I'm quite a fan of using the mouse wheel in view mode. * 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