On 21 Feb 2013, at 16:32, Renk Thorsten <thorsten.i.r...@jyu.fi> wrote:
> 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 is moving in the right direction for sure. I'd like to go a little further, and make the LOD setting a simple checkbox labelled 'reduce detail adaptively'. Then make the LOD ranges (for trees, clouds, AI models, whatever) internal properties, and crucially, enable OSG's LOD-bias feature. This effectively scales the 'visible distance' used to select LOD by a factor, and we can use a PID controller to adapt it based on target and actual frame-rate. (Of course I didn't try it for real yet). This ought to nicely adjust the LOD bias, and hence the final LOD, to keep a target rate (say 30 or 60fps). Of course if you enable every conceivable shader effect, the PID will drive the LOD-bias to a large value trying to keep 60fps with almost nothing drawn, so this needs some testing and sensible limits, but I hope could give much more flyable results - stuff will just disappear rather than the frame-rate plummeting as you approach LFPG or EHAM (or KSFO, even) (Of course it also needs an audit of our LOD hierarchy, which is currently a bit cumbersome, but that's all good incremental work) 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
