> Another option would be to move the visibility control to a dialog, with > a slider / spin box, and explicitly disable it when advanced weather is > selection. Then we could lose the keybinding completely, which is > something I want to move towards for options that are infrequently used, > but taking up 'keyboard space'. (...) > I agree that it shouldn't be a keyboard assignment, and we should remove > it. > I'd need to check, but I thought this was already part of the weather > configuration dialog.
My view is as well that visibility should be set as part of the environment setup and not quickly by a key. This is currently possible when you either select 'configure weather manually' (by entering a value into the form) or in a limited way in 'model weather based on METAR conditions' (here you can check 'Realistic visibility' and specify the max. visibility and the ground haze thickness'). You can not do it if you have selected 'interpret METAR directly' - maybe if that button is chosen, there should be an advanced options menu available to override the METAR settings partially (?) and allow to specify a higher visibility (METAR often reports 10 miles or 10 km, which is awfully low, and Advanced Weather has some heuristics at work to translate that into more realistic values, so a slider here would make sense). > Perhaps I wasn't clear enough. Let me try again 20 km isn't really enough > for a realistic AG radar - we really need an order more, but we could > possibly manage with 50 - 100 km. (To put that in context, the Blue > Parrot radar fitted in the Buccaneer had an AG range of 200 nm). It's at these > bigger numbers, coupled with detailed scenery, that we run into the > problem of running out of memory. I do agree with that, but if my visibility is 300 m, I'd be more than happy to take the 20 km ahead resolved in a ground radar rather than having 2 km of real terrain ahead of me. Computing cloud configurations which interact with terrain runs into the same problem. You need to have terrain loaded to compute them, so if you want to see clouds to 70 km distance, you need to load terrain out to 90 km or so even if the terrain can't be seen. I guess for several applications we'd like to know the terrain out to (far) larger distances than we render it, but here I do see memory issues. That's why I proposed to load a minimum of 20 km, not the 100 km which would be comfortable for me ;-) > We are also facing the user with a bewildering array of options, spread > over 2 menus in the GUI, with limited guidance on how or why they should be > used. Does anyone actually have a handle on this? I think not... I was about to bring this up as well. We have a mixture of real visibilities and auxiliary LOD parameters * we have visibility-m and ground-visibility-m which are actually used for rendering, i.e. they really correspond to visible fog * visibility-m doubles as indication how far out terrain is loaded, and by extension how far out it is safe to build new weather tiles (since they require terrain) -> we have a separate slider to adjust ground visibility for Advanced Weather. Admittedly it has no real justification except that it looks pretty darn impressive to play with ground fog when you're looking at a mountain range, and I can remove it if desired * we have LOD bare which specifies a maximum out to which distance terrain is loaded -> this is conceptually similar to the Advanced Weather max. visibility and could be merged - but max. visibility is runtime, I think LOD bare is read only at startup (?) -> or we start a divorce here and have one parameter independent of the visibility which determines how far out we load terrain - for instance for radar on high end systems * we also have LOD rough and LOD detailed but I do not know what they influence * we have separate drawing ranges for trees, random buildings, clouds full detail and clouds with dropped sprites -> these somehow are related to the LOD ranges and should be adjusted there (?) Do we have even more? So we'd adjust the *real* visibility parameters under 'Weather' and the 'draw object X out until' under 'Rendering'. Does that make sense? > 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. Okay, I will modify the model shader in such a way that it takes an extra flag. If the flag is set to zero, it will fog based on a sliding cutoff rather than a fixed cutoff and not fog the cockpit most of the time. If the flag is 1 or -1, it will either go through the fogging computation regardless of distance (exterior surface) or do no fogging (interior surface). This should work properly if someone modifies the aircraft and declares surfaces and give reasonable but not perfect results otherwise. * 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
