Re: [Flightgear-devel] Low visibility issues
Thorsten wrote: -Original Message- From: Renk Thorsten [mailto:thorsten.i.r...@jyu.fi] Sent: 21 February 2013 06:54 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Low visibility issues Vivian: There seem to be significant issues with the loading of terrain. If we load too much, the frame rate drops, if we load too little it looks poor, and AG radar doesn't work. Actually. We don't load enough for AG radar to work realistically in any case. We probably need something between 50 and 100 k for this , and we're unlikely to accommodate the memory requirements of this, at least for 32 bit systems. James: 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. Okay, here are some experimental facts on my old 32bit system. I had a GeForce 8600M and 4 GB of memory with a 32bit Linux installation. With this setup, without using random vegetation and random buildings, I could render terrain with 250 km visibility range (I patched the binary for that purpose, otherwise it gets clipped at 120 km) without any problems in default scenery. I could easily do 120 km in custom scenery, and even with vegetation and buildings on 55 km were quite safe in custom scenery. So it's not true that fixing a minimum visibility of 20 km we'd run into 32bi memory issues. As for framerate, I'd guess that GPUs which are so old that they have real issues processing the vertex count of 20 km scenery fast enough are hit also hard by the fragment shader - but fragment shader load is independent of the visibility range. There are lots of forum users who have issues with low framerate - about anything (no random vegetation, no shaders, no random buildings, no complex planes, no AI traffic, no 3d clouds...) seems to help more than to get visibility down. I'm not aware of any single user who uses less than 20 km visibility because the framerate is not acceptable otherwise, and I have never seen anyone suggest this to users. Since vertex count goes quadratically in visibility, it matters a lot if you use 50 or 120 km, but not so much if you use 10 or 20. Nevertheless, at some point my suggestion would be to create a commandline-enabled legacy mode for really old hardware which gives you access to a minimal setup in which terrain radars, Advanced Weather Co are disabled, but define the default setup of FG in such a way that terrain interaction based stuff can make assumption about how much terrain is loaded. For a halfway decent system, 20 km should not be any problem if I could run 250 km on a 5-year old laptop, and I think we can at some point make that default assumption and have a fallback option in case it doesn't work. I was not referring to a frame rate issue, but FG running out of memory. http://www.flightgear.org/forums/viewtopic.php?f=5t=18913p=177392#p177392 It is rare to see that happening using the current scenery, but here if I select random buildings and objects with a high value for trees, I can get Win32 to run out of memory. Apparently at least one other user has a problem. Vivian -- 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
Re: [Flightgear-devel] Low visibility issues
I was not referring to a frame rate issue, but FG running out of memory. http://www.flightgear.org/forums/viewtopic.php?f=5t=18913p=177392#p177392 It is rare to see that happening using the current scenery, but here if I select random buildings and objects with a high value for trees, I can get Win32 to run out of memory. Apparently at least one other user has a problem. I do not doubt that you can make FG run out of memory on a 32 bit system (you can also do it on a 64 bit system if you try really hard). My point is more that memory issues should be dealt with by eliminating the root cause, i.e. by switching off random buildings and trees on a low memory system and by not using hires textures, not by reducing visibility to low values. Compared to the memory footprint coming from high-detail aircraft and random buildings, the effect of 10 km vs 20 km visibility on memory is negligible. We have aircraft in the repository which fill more than 300 MB of GPU memory - loading terrain vertices worth 20 km is a very small fraction of that, even in hires scenery. Even in custom Italy with 50 km visibility, I had about half a million of terrain vertices in the scene, that's 1.5 million or so numbers. That's the order of magnitude of a good-sized texture sheet - 1024x1024 has about a million numbers - with a lower precision, but with added mipmapping,... * 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
Re: [Flightgear-devel] Low visibility issues
On Wednesday, February 20, 2013 08:44:24 Renk Thorsten wrote: . 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. Thanks, * Thorsten This should be easily fixable by having the atmospheric scattering checkbox set the value of: /sim/rendering/minimum-sky-visibility to 0, and returning it to the default value when unchecked. -- 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
Re: [Flightgear-devel] Low visibility issues
On Thursday, February 21, 2013 10:31:18 Renk Thorsten wrote: I was not referring to a frame rate issue, but FG running out of memory. http://www.flightgear.org/forums/viewtopic.php?f=5t=18913p=177392#p17739 2 It is rare to see that happening using the current scenery, but here if I select random buildings and objects with a high value for trees, I can get Win32 to run out of memory. Apparently at least one other user has a problem. I do not doubt that you can make FG run out of memory on a 32 bit system (you can also do it on a 64 bit system if you try really hard). My point is more that memory issues should be dealt with by eliminating the root cause, i.e. by switching off random buildings and trees on a low memory system and by not using hires textures, not by reducing visibility to low values. Compared to the memory footprint coming from high-detail aircraft and random buildings, the effect of 10 km vs 20 km visibility on memory is negligible. We have aircraft in the repository which fill more than 300 MB of GPU memory - loading terrain vertices worth 20 km is a very small fraction of that, even in hires scenery. Even in custom Italy with 50 km visibility, I had about half a million of terrain vertices in the scene, that's 1.5 million or so numbers. That's the order of magnitude of a good-sized texture sheet - 1024x1024 has about a million numbers - with a lower precision, but with added mipmapping,... * Thorsten Draw distance and, consequently, fog used to mask the edge, has always been used as a device to limit graphics workload, resources needed, and improve performance of 3d applications. It allows you to fill the visible scene with as much detail as you can handle, and provides a fairly gracious and credible way of hiding the cutoff. And this technique isn't going away soon. And this is exactly the case of decent GPUs stuck on a limited memory system (be they 32bit or low memory ones), they can handle all the goodies in a limited scene (maybe even more), but their memory can't hold the wide scenes. Why should those users be forced to give up on those goodies just because one part of the rendering scheme doesn't want to play by the rules? Even more so when there's no indication that happens... The default max visibility value is a pretty sane default, and simply increasing that to huge values without any kind of warning of the implications provided to the unaware user is simply _BAD_DESIGN_ imho. (As is disabling the z/Z key behaviour in one of the weather options, again without any warning provided whatsoever). Cheers, Emilian -- 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
Re: [Flightgear-devel] Low visibility issues
Why should those users be forced to give up on those goodies just because one part of the rendering scheme doesn't want to play by the rules? Even more so when there's no indication that happens... The default max visibility value is a pretty sane default, and simply increasing that to huge values without any kind of warning of the implications provided to the unaware user is simply _BAD_DESIGN_ imho. (As is disabling the z/Z key behaviour in one of the weather options, again without any warning provided whatsoever). Fact check: 1) I'm proposing to set the distance out to which the terrain is unconditionally loaded to a value of 20 km. The hard-coded default max value of the visibility is currently 120 km. FGs default visibility at startup is about 16 km (and I'd be fine with that value as well). No idea why my proposed 20 km would be a 'huge value'. 2) There is LOD bare under user control which allows you to unconditionally set a lower value for the terrain you load. There is a max. visibility slider for Advanced Weather which allows you to define the maximum visibility that Advanced Weather will ever reach - this is initialized to a rather low value. I don't know if this is synchronized with the max. visibility in Basic Weather, it isn't in Advanced Weather, which is something I can fix if needed. There is _no_ talk about 'giving up goodies' here if goodies are a limited range of the scene, and there is _no_ bad design here because all can be controlled in a sane way from the GUI. 3) The purpose of loading unconditionally 20 km worth of terrain is not 'because one rendering scheme doesn't play along' but to prevent * 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 4) z/Z is disabled because weather comes with a model for the vertical change of visibility as you go to different altitudes. You are allowed to affect that model (that's what sliders are for), but you are not supposed to micro-manage the weather simulation. There's a clear idea behind all of this, which is that in Advanced Weather you trust the simulation to have an understanding of weather and terrain and get the details right, you do not adjust the details. I'm not forcing any Basic Weather user to the Advanced Weather philosophy, don't try the reverse on me. Leaving your obvious expression of dislike for Advanced Weather aside, is there anything in your post which has relevance for what we're discussing here? If yes, please explain. * 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
Re: [Flightgear-devel] Low visibility issues
On Thursday, February 21, 2013 11:13:21 Renk Thorsten wrote: Why should those users be forced to give up on those goodies just because one part of the rendering scheme doesn't want to play by the rules? Even more so when there's no indication that happens... The default max visibility value is a pretty sane default, and simply increasing that to huge values without any kind of warning of the implications provided to the unaware user is simply _BAD_DESIGN_ imho. (As is disabling the z/Z key behaviour in one of the weather options, again without any warning provided whatsoever). Fact check: 1) I'm proposing to set the distance out to which the terrain is unconditionally loaded to a value of 20 km. The hard-coded default max value of the visibility is currently 120 km. FGs default visibility at startup is about 16 km (and I'd be fine with that value as well). No idea why my proposed 20 km would be a 'huge value'. I was talking about the 16km value (sorry for not being more clear about that) 2) 3) I wasn't talking about these, neither was Vivian. 4) z/Z is disabled because weather comes with a model for the vertical change of visibility as you go to different altitudes. You are allowed to affect that model (that's what sliders are for), but you are not supposed to micro-manage the weather simulation. There's a clear idea behind all of this, which is that in Advanced Weather you trust the simulation to have an understanding of weather and terrain and get the details right, you do not adjust the details. I'm not forcing any Basic Weather user to the Advanced Weather philosophy, don't try the reverse on me. Leaving your obvious expression of dislike for Advanced Weather aside, is there anything in your post which has relevance for what we're discussing here? If yes, please explain. * Thorsten There's no warning/statement about what that selection implies, nowhere. The average user doesn't know what that will do to his system, or how it will change behaviour of other parts, that seem unrelated, nor has he control over a simple thing that might improve his experience, while enjoying both high detail scenery+objects and advanced weather. Sorry, but for me, forcing your usage-pattern on the user just because you think you know better what he wants is bad_design by definition. -- 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
Re: [Flightgear-devel] Low visibility issues
I was talking about the 16km value (sorry for not being more clear about that) Sorry this should have read: I was talking about the 16km value (sorry for not being more clear about that) and see below for the huge value. -- 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
Re: [Flightgear-devel] Low visibility issues
I was talking about the 16km value (sorry for not being more clear about that) and see below for the huge value. Let me get this straight. You state that the 16 km are a pretty sane value. The proposal being discussed is to load terrain to 20 km no matter what the visibility is. Vivian has concerns about memory on 32bit systems. I have test data showing that I can do 250 km visibility on a 32bit system and 50 km with trees and buildings and custom scenery. So as far as the topic of the discussion is concerned (which up to this point had nothing to do with what visibility Advanced Weather may or may not set) - can we agree that 20 km (or 16 km) of terrain loaded no matter the visibility is a sane value even for a 32 bit system? Or do you have different test data? This There's no warning/statement about what that selection implies, nowhere. The average user doesn't know what that will do to his system, or how it will change behaviour of other parts, that seem unrelated, nor has he control over a simple thing that might improve his experience, while enjoying both high detail scenery+objects and advanced weather. has nothing to do with the question discussed (which is how much terrain we load when the visibility is small). It is a quite different issue which you bring here for no discernable reason whatsoever (the thread title is 'low visibility issues' and you're suddenly switching to high values...). Your statement as made above is pure hypocrisy. 1) There is zero warning given what increasing the visibility with z might imply (I just tried that to be sure). If you're concerned about the correlation between memory usage and visibility, you should not care how the large visibility is obtained, you should warn whenever this happens. 2) Last time I checked, there was no warning given that the IAR-80 uses a large chunk of memory. If you are genuinely concerned about users filling up their memory, why don't you start here? 3) In order for Advanced Weather to reach the really large visibilities, you actually need to check a box labelled 'Realistic Visibility' This may also provide a hint that we're not doing rendering for a 3d shooter where fog is a device to hide the edge of the scene, but that visibility is an essential and very relevant property for the environment we're trying to simulate - it makes the difference between IFR, hard VFR and easy VFR. Even leaving this argument aside, I would argue that a user who has a) set LOD bare to a high value and b) checked this box can be assumed to have the intention to render a high visibility. 4) I actually brought up the very same issue on this list - the correlation between memory, choosing highly detailed options and getting a large visibility delivered. There was a discussion and a decision was made to attach the warning to the random buildings options, not to Advanced Weather and to try to decrease memory usage of buildings. Strangely enough, things didn't bother you then. I wonder what's the use of me bringing up points for discussion if havign discussed it doesn't mean that it's settled. Sorry, but for me, forcing your usage-pattern on the user just because you think you know better what he wants is bad_design by definition. Advanced Weather specifies the visibility as a 4-dimensional field vis(x,y,z,t), i.e. it changes laterally, vertically and in time. In addition, Advanced Weather knows the correlation of weather phenomena and visibility - it knows that rain implies low visibility, it knows that visibility deteriorates when entering a cloudbase, it knows that visibility stays poor in a warm sector pretty high up and similar things. Basic Weather does not know these things, it's purely descriptive and has no concept what the weather is. You can either micromanage visibility as Basic Weather does and give up on all these details, or you can hand control to the simulation. There is no GUI you could fill in less than 30 minutes which gives you a visibility model as detailed as what Advanced Weather runs. If you see visibility as 'just a device to hide the edge of the scene' rather than an important property of the environment we're simulating, my advice is simply not to use Advanced Weather. What you're asking for is equivalent to 'Can't I just _set_ the airplane velocity to any value I like without the FDM computing it? I want more direct control.' Doesn't make any sense, sorry, if you don't like using FDMs, use the ufo. Trying to dumb down an FDM because you want direct control over the airspeed is not the way to go, and trying to dumb down the environment simulation because you want to micro-manage visibility is not the way to do, sorry. Please note that this will be my only response to this topic, because a) it has already been discussed and b) it's not related to the discussion of the thread. * Thorsten
Re: [Flightgear-devel] Low visibility issues
On 21 Feb 2013, at 11:33, Emilian Huminiuc emili...@gmail.com wrote: 4) z/Z is disabled because weather comes with a model for the vertical change of visibility as you go to different altitudes. You are allowed to affect that model (that's what sliders are for), but you are not supposed to micro-manage the weather simulation. There's a clear idea behind all of this, which is that in Advanced Weather you trust the simulation to have an understanding of weather and terrain and get the details right, you do not adjust the details. Suggestion - if z/Z are pressed with advanced weather enabled, make the popup-message say 'disabled since visibility is being controlled by advanced weather'. 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'. 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
Re: [Flightgear-devel] Low visibility issues
Thorsten -Original Message- From: Renk Thorsten [mailto:thorsten.i.r...@jyu.fi] Sent: 21 February 2013 10:31 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Low visibility issues I was not referring to a frame rate issue, but FG running out of memory. http://www.flightgear.org/forums/viewtopic.php?f=5t=18913p=177392# p1 77392 It is rare to see that happening using the current scenery, but here if I select random buildings and objects with a high value for trees, I can get Win32 to run out of memory. Apparently at least one other user has a problem. I do not doubt that you can make FG run out of memory on a 32 bit system (you can also do it on a 64 bit system if you try really hard). My point is more that memory issues should be dealt with by eliminating the root cause, i.e. by switching off random buildings and trees on a low memory system and by not using hires textures, not by reducing visibility to low values. Compared to the memory footprint coming from high-detail aircraft and random buildings, the effect of 10 km vs 20 km visibility on memory is negligible. We have aircraft in the repository which fill more than 300 MB of GPU memory - loading terrain vertices worth 20 km is a very small fraction of that, even in hires scenery. Even in custom Italy with 50 km visibility, I had about half a million of terrain vertices in the scene, that's 1.5 million or so numbers. That's the order of magnitude of a good-sized texture sheet - 1024x1024 has about a million numbers - with a lower precision, but with added mipmapping,... 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'm not saying that we shouldn't do it, but we should do it with our eyes open. Or perhaps there are techniques, such as an inner and outer scenery caches which would help us to a better solution than tuning off nice features such as trees. 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 thought I was an experienced FG user, but this one is getting away from me. That said, with the right settings, FG can look absolutely stunning - just before it runs out of memory :-( Vivian -- 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
Re: [Flightgear-devel] Low visibility issues
On Thu, Feb 21, 2013 at 12:59 PM, James Turner wrote: Suggestion - if z/Z are pressed with advanced weather enabled, make the popup-message say 'disabled since visibility is being controlled by advanced weather'. 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. -Stuart -- 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
Re: [Flightgear-devel] Low visibility issues
On 21 Feb 2013, at 15:54, Stuart Buchanan stuar...@gmail.com wrote: On Thu, Feb 21, 2013 at 12:59 PM, James Turner wrote: Suggestion - if z/Z are pressed with advanced weather enabled, make the popup-message say 'disabled since visibility is being controlled by advanced weather'. 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. We had a discussion about this keybinding (and some others, a larger issue of mine) on IRC and discovered that all the people using it are developers / scenery authors, to 'test stuff'. This makes me think it should be in a debug option somewhere, or that we might need a 'scenery test mode' which for example, disables weather of any kind completely. (Arguably fgviewer is the right solution for this, though it would then be hard to test interaction of scenery / models and different Effects options, I guess) I also think the FoV setting should move to a dialog, but I have the impression normal people (not developers) *are* using that to look around 3D cockpits and 'zoom' on details. Of course FoV and zoom are not quite the same thing, but it does work in practice. 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
Re: [Flightgear-devel] Low visibility issues
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
Re: [Flightgear-devel] Low visibility issues
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
Re: [Flightgear-devel] Low visibility issues
On 02/21/2013 04:26 PM, James Turner wrote: On 21 Feb 2013, at 15:54, Stuart Buchanan stuar...@gmail.com wrote: On Thu, Feb 21, 2013 at 12:59 PM, James Turner wrote: Suggestion - if z/Z are pressed with advanced weather enabled, make the popup-message say 'disabled since visibility is being controlled by advanced weather'. 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. We had a discussion about this keybinding (and some others, a larger issue of mine) on IRC and discovered that all the people using it are developers / scenery authors, to 'test stuff'. This makes me think it should be in a debug option somewhere, or that we might need a 'scenery test mode' which for example, disables weather of any kind completely. (Arguably fgviewer is the right solution for this, though it would then be hard to test interaction of scenery / models and different Effects options, I guess) I also think the FoV setting should move to a dialog, but I have the impression normal people (not developers) *are* using that to look around 3D cockpits and 'zoom' on details. Of course FoV and zoom are not quite the same thing, but it does work in practice. 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 limit of EYE vision and limit of EQUIPMENT vision the reason to be of the EQUIPMENT is to override the limit of the EYE vision. Are we doing the error to merging this two ? IMHO, and by logiX there must be out-here people NOT DEVEL, using z/Z x/Z. I used to use it long time before diving in FG devel. I my case the reason was to adjust the weight of the GPU computing a better frame rate. 1. When the plane is on the tarmac, the weight is due to numerous building etc So the limit-of-visibility can help. ok. 2. When it go away from Airport climbing the number of objects is lower and frame rate raise up. 3. But at some fly level, the scope of view is so big that the number of visible objects increase and the frame rate decrease. (and I have a powerful card RADEON but unhappily with bad driver support) So what about user with less GPU power ??? The BIG weight of processing is the VISION So, is there not possible to separate the radar calculations ? I do not know, but just as hint, if we are avoiding to load a lot of TERRAIN to spare RAM, can't we have have radars reading infos from NEW files, much lighter, with info extracted from TERRAIN ? -- Lorenzo -- 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
Re: [Flightgear-devel] Low visibility issues
Hi, On Thursday, February 21, 2013 16:43:51 James Turner wrote: 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) Well, that's on the way. Please do not steer any lod ranges except may be the lod bias by any property. That's again cross connecting code areas that do not need to be connected and that then suffer from updates into the scene graph that are unneeded. The osg LOD system is simple but effective if used in a sensible way. The spt loader used in fgviewer also has lod hierarchies built in. You can already load - may be I need to push this series to the latest version - lower level of detail huger tiles if you put them into the right directories. That's in preparation and has no upstream support form the scenery yet. Greetings Mathias -- 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
[Flightgear-devel] Discussion culture clashes
..a pointer to your previous message would help here, this thread is broken (in at least my MUA) and getting hard to follow. Maybe we just have some cultural misunderstandings? The way I see it - if you want to make a statement in a discussion, you have to read what has been said before. No matter how hard it is to follow. No matter how long. Everything else is impolite - you're in essence sending the message I don't really care what you've been saying already, but I think my opinion is so important so that I neither need to react to what you've been saying previously nor to care not to repeat what's already been solved - but I expect you to react to what I have to say. You don't want to follow the discussion because it's so complicated, that's fine, but then don't speak up. The categorical imperative will tell you that it doesn't work if some people want special treatment. In the event Lorenzo argues for instance against loading terrain far out for radar purposes. Nobody has proposed to do that, so it's a strawman argument in the first place. Vivian has mentioned the dangers of the approach, I have agreed with him, so what is the possible point of arguing against something no one wants to do? Replying to that only keeps the discussion in one more unproductive cycle and doesn't make anything clearer. He argues for using visibility as a device to adjust framerate, ignoring all arguments brought against seeing visibility as a mere tool to adjust framerate, and despite James sketching a LOD bias system as a well-defined alternative way to get framerate adjusted using LOD ranges. So he doesn't bother to read what Vivian, James and I have been saying - why should it then be my job to give him pointers? The way I see it, if you want to criticize something, you first make sure you understand the problem so that you can deliver a meaningful critique, and ideally you can even suggest a better alternative. If you speak without understanding the problem, you're choosing a very unfriendly way to ask others to take their time and explain it to you when understanding it should have been your job in the first place. If you don't understand, you ask politely for an explanation, only if you understand and disagree, you can criticize. The way I see it, if you have criticized without understanding, you owe an apology. The way I see it, arguments should be based on what's correct, not what's familiar. I'm repeatedly observing that familiar flaws are seen as completely acceptable, but any flaw in new features is jumped on eagerly. I'm even observing that any change is held to the standard of what was previously installed and is perceived wrong if different. In the forum, there was an argument that 012345Z 23010KT 5000 SHRA SCT012 BKN018 OVC060 15/11 Q1010 is wrongly interpreted because it comes out much darker than in 2.0.0 - illustrated with screenshots showing 3/8 cloud cover. The familiar trumps the correct, even given that 3/8 cloud cover is definitely not what the METAR says - it doesn't matter that we now have the correct cloud cover specified by the weather, it matters that it's no longer what is familiar, and this isn't the way to make an argument. Having z/Z control visibility because one is used to it is no argument for or against it. The way I see it, arguments should be backed up with evidence. The memory consumption of loading 20 km (50 km, 100 km) of terrain is a number in a certain range - we don't need to toss concerns back and forth if we go ahead and measure the number, and we should base decisions on evidence rather than belief if we can get the evidence. I don't think these are grossly unreasonable foundations for meaningful, productive discussions. I'm not in a position to make anyone else adopt such standards as the goal for having a discussions, but could we perhaps give it a thought? * 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
