From: Renk T. <tho...@jy...> - 2013-02-21 06:53:49
|
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. * Thorsten |
From: Renk T. <tho...@jy...> - 2013-02-21 10:31:32
|
> I was not referring to a frame rate issue, but FG running out of memory. > > http://www.flightgear.org/forums/viewtopic.php?f=5&t=18913&p=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 |
From: Emilian H. <emi...@gm...> - 2013-02-21 10:53:45
|
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=5&t=18913&p=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 |
From: Vivian M. <viv...@li...> - 2013-02-21 14:37:38
|
Thorsten > -----Original Message----- > From: Renk Thorsten [mailto:tho...@jy...] > 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=5&t=18913&p=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 |
From: Renk T. <tho...@jy...> - 2013-02-21 11:13:31
|
> 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 |
From: Emilian H. <emi...@gm...> - 2013-02-21 11:34:08
|
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. |
From: Emilian H. <emi...@gm...> - 2013-02-21 11:44:40
|
> 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. |
From: James T. <zak...@ma...> - 2013-02-21 13:00:24
|
On 21 Feb 2013, at 11:33, Emilian Huminiuc <emi...@gm...> 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 |
From: Stuart B. <stu...@gm...> - 2013-02-21 15:54:53
|
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 |
From: James T. <zak...@ma...> - 2013-02-21 16:27:03
|
On 21 Feb 2013, at 15:54, Stuart Buchanan <stu...@gm...> 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 |
From: Lorenzo C. <lor...@ka...> - 2013-02-21 17:29:55
|
On 02/21/2013 04:26 PM, James Turner wrote: > On 21 Feb 2013, at 15:54, Stuart Buchanan <stu...@gm...> 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 > Fli...@li... > 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 |
From: Renk T. <tho...@jy...> - 2013-02-21 12:33:27
|
> 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 |
From: Emilian H. <emi...@gm...> - 2013-02-22 13:09:49
|
On Thursday, February 21, 2013 12:33:17 Renk Thorsten wrote: > > 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? See below... > > 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. Have you ever read the getstart.pdf? apparently not. In current version at page 61 getstart.pdf wrote: > – Rendering Options configures various graphical features. This allows > you to trade eye-candy such as shadows, 3D clouds and specular reflec- > tions for frame-rate. To help you achieve a good balance, enable the > “Show Frame Rate” option in the Display Options menu, which will > show the current frame-rate in frames-per-second in the bottom right > of the screen. Most people find a frame-rate of around 20fps adequate > for flying. The frame-rate is affected by the graphical features you > have enabled, the current visibility (set by Z/z), the number of objects > in view and their level of detail (LOD). ------------------------------------------------------------------------------------------------- > 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? Don't we like to compare apples and oranges... Hmm, let's see, your statement would be valid if: a) The IAR 80 would be part of the core distribution. It isn't. b) If parts of it would be a hidden requirement for the corect operation of other aircraft, under the apparence of optional usage (it isn't), while advanced weather is required to be on to get full advantage of the atmospheric scattering scheme, a thing that isn't specified anywhere (except in some obscure forum post, or wiki page, for which you need to search really hard and only when you know what you're looking for) c) it would completely override the operation of other core components just because it can, and would do seemingly unexpected things for the unaware user (it doesn't). As for the memory usage of the IAR80, you might be surprised if you botherd to check. BTW, weren't you the one "crying" on quite a few forum threads, some time ago, that aircraft need better 3d models/cockpits, the one who started rating them based on how they look... hmm... I suppose it was just an attempt at a personal attack, but, unlike you, I don't consider [more or less informed or documented] critique to my work as a personal affront. > > 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. It doesn't change the fact that it takes some well documented control out of the user hands, without warning him. It also doesn't change the fact that visbility/fog has (had and will have, in a sane setup) a dual purpose, that of being a _simulation_ (read approximation) of an atmospehric phenomenon thus providing visual hints, and of a resource management device, -in any simulated environment, be it a 3d shooter, a racing simulator, a flight simulator, a space flight simulator, a real time strategy game... As for the buildings warning, that was added because it caused/causes issues even in the default setup in certain areas. The bigger visibility issues on 32bit system occur even with builings off, but with trees on, once you start moving around (40km with trees on is a nono after you move around for a while, which leads me to believe that your 50 km test was a static test, or one limited to moving around just a short distance from the start position). > > 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 If it has been discussed, but there are still issues, I don't think that hiding one's head in the sand, and ignoring them, is the right way to go, just because, as mentioned earlier, someone might feel offended if some part of his work is brought into question. (BTW: The forums are still there if you feel the need for a choir of "oooh ", "aaahhh" and "woooow"s at your carefuly crafted screenshots, which, I have no problem to admit, look stuning) As for the relation to this thread, the memory issues have been brought up, and I've expressed my concerns to how some related implementation might affect those, if that's wrong, feel free to ignore me. (and it's not me the one who split this thread off from the previous related discussion(s) ) Regards, Emilian |
From: Renk T. <tho...@jy...> - 2013-02-21 16:33:09
|
> 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 |
From: James T. <zak...@ma...> - 2013-02-21 16:44:07
|
On 21 Feb 2013, at 16:32, Renk Thorsten <tho...@jy...> 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 |
From: Mathias F. <Mat...@gm...> - 2013-02-22 07:10:43
|
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 |
From: James T. <zak...@ma...> - 2013-02-22 09:06:54
|
On 22 Feb 2013, at 07:06, Mathias Fröhlich <Mat...@gm...> wrote: > 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. Yep, agreed - all I was saying is that our current model / scene hierarchy doesn't always use the OSG LOD system the best way, and that taking advantage of the LOD-bias feature would be very good. And hopefully quite a small, centralised change! (To pick one example, I'd like to put *every* object on a tile into a top-level LOD group, so that beyond a certain range we only render the base BTG, and no static/shared objects at all - although I did see some commits in this area from you back in the autumn, maybe this is already done now?) > > 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. That sounds excellent, hopefully the work to generate lower-detail tiles is also progressing. Regards, James |
From: Saikrishna A. <sai...@gm...> - 2013-02-22 12:29:44
|
Just to chime in, wouldn't rendering the base tile be "easier" for the GPU, and then static objects, and then dynamic objects? Saikrishna Arcot On Fri 22 Feb 2013 03:06:37 AM CST, James Turner wrote: > > On 22 Feb 2013, at 07:06, Mathias Fröhlich <Mat...@gm...> wrote: > >> 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. > > Yep, agreed - all I was saying is that our current model / scene hierarchy doesn't always use the OSG LOD system the best way, and that taking advantage of the LOD-bias feature would be very good. And hopefully quite a small, centralised change! > > (To pick one example, I'd like to put *every* object on a tile into a top-level LOD group, so that beyond a certain range we only render the base BTG, and no static/shared objects at all - although I did see some commits in this area from you back in the autumn, maybe this is already done now?) > >> >> 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. > > That sounds excellent, hopefully the work to generate lower-detail tiles is also progressing. > > Regards, > 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 > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: Renk T. <tho...@jy...> - 2013-02-21 18:53:20
|
> 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 ? Would you mind reading the previous messages in the thread? I don't mean to be impolite, but I really don't want to write everything twice. Thanks. * Thorsten |
From: Arnt K. <ar...@c2...> - 2013-02-21 22:37:29
|
On Thu, 21 Feb 2013 18:53:06 +0000, Renk wrote in message <E49...@mb...>: > > 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 ? > > Would you mind reading the previous messages in the thread? I don't > mean to be impolite, but I really don't want to write everything > twice. Thanks. > > * Thorsten ..a pointer to your previous message would help here, this thread is broken (in at least my MUA) and getting hard to follow. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. |
From: Renk T. <tho...@jy...> - 2013-02-23 07:08:53
|
> Have you ever read the getstart.pdf? apparently not. I've read it once, a long while ago. But I don't feel bound by what it says, in my view the logic is that we implement what's reasonable, then change the documentation accordingly, not that we first have a documentation as god-given and only implement what is in there for all future to come. So the question to me is if z/Z for Advanced Weather is reasonable or not, not what the documentation says. I do take the point that the documentation should be updated accordingly. > Don't we like to compare apples and oranges... Hmm, let's see, your > statement would be valid if: > a) The IAR 80 would be part of the core distribution. It isn't. So everything which is shipped with the core needs to contain warnings if it uses lots of resources? I don't think that's actually a design principle anywhere else. Neither Atmospheric Light Scattering not Advanced Weather are currently enabled by default. In order to run into the memory issues you're mentioning, you need to * switch Advanced Weather on * dial LOD bare to a high value * check 'realistic visibility' in the Advanced Weather dialog * move the max. visibility slider of Advanced Weather to a high value ( * install custom scenery, enable random vegetation, enable random buildings,...) I continue to argue that this can be taken as conscious intention of the user to render a high visibility scene, likewise that installing the IAR-80 (the b1900d,...) represents an intention to use a highly detailed airplane. I would argue that the user isn't stupid and knows that using better graphics usually costs more resources. > b) If parts of it would be a hidden requirement for the corect operation > of other aircraft, under the apparence of optional usage (it isn't), while > advanced weather is required to be on to get full advantage of the > atmospheric > scattering scheme, a thing that isn't specified anywhere (except in some > obscure forum post, or wiki page, for which you need to search really > hard and only when you know what you're looking for) Well, getting 'full advantage' is something other than 'being necessary' in my book. Atmospheric Light Scattering runs stable with Basic Weather, it just doesn't get all the goodies right. I am not happy about the state of affairs, but as I've stated a few times, I can't actually do anything about it. I'm not the maintainer of Basic Weather, I have a very vague notion where its internals are specified, and I'm not in a position to change them. I accept the point as valid, but not the responsibility as mine - I've offered again and again to help anyone who wants to drive Light Scattering properly from Basic Weather. By the way, the 'thing' is specified for instance in the release notes of 2.10, which doesn't really look like an attempt to hide it from the public to me. If you can come up with a suggestion where else it should be spelled out, let's do it. > c) it would completely override the operation of other core components > just because it can, and would do seemingly unexpected things for the unaware > user (it doesn't). Well, it uses dds, which hasn't gone well with some folks either... You seem to have trouble accepting a simple point: z/Z is not 'a core component' of anything. It is a key binding to modify a weather parameter, and FG operates fine without it. Advanced Weather does not override it 'because it can' but because there is a good reason - it conceptually does not mix with a physically reasonable model of the visibility in the atmosphere. You may not want to model realistic modelling of the visibility, which is fine, then you're free not to use Advanced Weather. It's a choice you have. > As for the memory usage of the IAR80, you might be surprised if you > botherd to check. I don't need to - you kindly published the number in the forum at one point. :-) It's significantly more than the terrain mesh has according to your own numbers. > BTW, weren't you the one "crying" on quite a few forum > threads, some time ago, that aircraft need better 3d models/cockpits, the one who > started rating them based on how they look... hmm... I'm saying that what you do is hypocrisy, i.e. you measure me by standard which you yourself don't adhere to. I think my own behaviour is quite consistent - I am arguing for more realistic cockpit designs, and I am arguing for more realistic environment and visuals. So please don't get this wrong, it's an important point: I think the IAR-80 is literally defining the standard of how a 5-star model can look like, and I would like to see many more. I'm not criticizing the way you did the IAR-80, I'm saying that if you think the way you did this is okay, you should also think the way Advanced Weather is implemented is okay, if you do not think Advanced Weather is implemented okay, you should change the way you handled the IAR-80. I believe in giving users a choice - those with high-end graphics cards should get the models/shaders/textures/environment settings to give them stunning visuals, but we should not throw away the alternative (legacy?) options for those who need high framerates or have weaker GPUs. But I do not believe that the high-end development should be restricted by what runs at the low end as long as it's optional. > I suppose it was just an attempt at a personal attack, but, unlike you, I > don't consider [more or less informed or documented] critique to my > work as a personal affront. No, the idea was simply to show you that you do not measure me by the same standards as you measure yourself. You yourself develop high-end visuals which don't run on some systems (see again e.g. the dds discussion), and you believe this is okay as long as it's optional. But you're not willing to accept me doing the same. As for personal attacks: "weren't you the one "crying" on quite a few forum threads" "The forums are still there if you feel the need for a choir of "oooh ", "aaahhh" and "woooow"s at your carefuly crafted screenshots" does sound a bit like that, doesn't it? > It also doesn't change the fact that visbility/fog has (had and will > have, in a sane setup) a dual purpose, that of being a _simulation_ (read > approximation) of an atmospehric phenomenon thus providing visual > hints, and of a resource management device, Yes, I know that. Which is why Advanced Weather has a slider to set max. visibility, so if you want to be sure that you don't run into trouble, you set the slider to 30 km. and the visibility will always be 30 km or less, but you get to keep the full modelling of lower visibility regions, or the vertical development of visibility and so on. That's why Advanced Weather also has the 'realistic visibility' checkbox to allow you to make a choice if you want to run the model in a less-demanding or in a fully-demanding mode. You're claiming that directly controlling visibility by z/Z is somehow the only way resource management can be implemented, but that is just not true. Advanced Weather has a resource management model which works along with the atmosphere modelling it does, not against it. It's also not true that this wouldn't be documented - Advanced Weather has a documentation where all this is spelled out. The only real point you make is that it isn't in getstarted.pdf, so the logical consequence would be to update the manual then, rather than to change the implementation, no? > As for the relation to this thread, the memory issues have been brought > up and I've expressed my concerns to how some related implementation might > affect those, if that's wrong, feel free to ignore me. Do you, or do you not agree that 20 (or 16) km terrain loaded regardless of the visibility is a sane value? Somehow, you haven't really answered the question, you're just expressing unspecified 'concerns' and attacking Advanced Weather. Note that I've been heavily using your own numbers for memory usage which you published in the forum where you argued that what's expensive about scenery is not vertex count but textures - do you no longer hold that view? * Thorsten |
From: Emilian H. <emi...@gm...> - 2013-02-23 10:25:18
|
On Saturday, February 23, 2013 07:08:41 Renk Thorsten wrote: >A lot of stuff, mostly deflecting the discussion to other irelevant points > > * Thorsten While I should know better than to answer to this, as it will again get deflected to other areas, let's imagine ourselves a simple scenario: Let's say I'm an average user with a 32bit system, I can barely find my way through the maze of menus and dialogs flightgear presents to me, and I want to use this more advanced weather simulation engine. After I accidentaly find out how to enable it (it's hidden under a rather confusing radio-button selection "Model overall weather conditions based on metar"), great, select "Fair weather" scneario, Apply, OK, let's go flying. I muck around, wonder at the nice sky/clouds, notice that my visibility improved somewhat, then bam after 15 minutes flightgear crashes, uhm.. oohh, why did that happen? That didn't happen before? All I did was change the way the weather is interpreted... What's wrong here??? Well, now let's see what actually happens in a default flightgear instalation (all settings are from preferences.xml, and Environment/local-weather- defaults.xml) ->trees are enabled by default ->default visibility with "Fair weather" is ~16km ->local weather comes in and sets a default value for max visibility of 120km (o.O), ok, that's a bit far, but in practice I see that's actually hovering in the 40km range (+-10km based on altitude). (roughly 3x more than the default) So in the default scheme we load 9 tiles at startup, then we keep loading tiles in the direction we're traveling, and those initial tiles remain resident in the tile cache for a while (in case you decide to double back). But let's stay with the startup condition. when you ramp up the visibility to 40km you demand 3 extra "rings" of tiles to be loaded. That would give you at least 69 tiles loaded (81 if the "rings" are square). So that's an instant increase of 7-9x the memory requirements of the terrain + objects + trees (tres being the largest contributor here), just because you click an option that says it just _interprets_ the METAR string differently. Do you think that's an expected result? I don't. Well, our average user might have read the manual, might have mucked about with the visibility setting before, and he remeber that all things being the same, visibility is what impacts performance/memory the most, so he decides to try again, this time trying to use z/Z to limit how far the visibility goes, maybe he gets lucky and it won't crash again, but he's in for a surprise... z/Z doesn't work... You might argue that he should know better, go into the advanced settings dialog, figure out what all those sliders and selection boxes do, etc, etc... But remeber, our user is an average one, he wants things to just work (with time, he might find a use for the more advanced configuration stuff, but for now he's not interested, he just want to click something, and be done with it), The z/Z case above might be a lucky one where he might have read the manual. The problem is not with "Advanced weather" in itself, the problem is in the details of a part of it, themost important part from the user POV. Your approach might work, given unlimited resources, but as it is Flightgear has to run on a variety of puny little desktop/laptop machines. You have already implemented half of the control, is it so hard to implement the rest and provide a system that's consistent with the rest? Yes it breaks the "real world" scheme, but this is a simulation, we lie, carefully crafted lies, that give a global impression of truth, of copying the real world behaviour, but in the end they are lies. Fog/view-distance is one of those lies, they need just be plausible, not a faithful representation of the real world (and a faithful representation of the real-world is practically impossible given the current state of the technology). You are comfortable with abdicating from that when it suits you, but where it really matters you defend the "minute detail faithfull representation of the real world scheme" vigorously... Don't you think thre's something amiss here? As someone said in another thread, there are various techniques that are not constrained by the "real-time" requirement, that do a pretty good job of giving you "real" results, but their place is not here. Here we have to do our best to trick the mind, while doing that as fast as possible, with a reasonable usage of resources. Just because you can set visibility to 1000km doesn't mean you should, just because you can shove a lot of data into a shading scheme and get back "photoreal" results doesn't mean you should, if said results reduce performance, increase the probability of running out of memory, etc. You'll argue again with the IAR as an example. Well, take a look at those numbers again, and you'll see that for the amount of detail it presents to the user it uses ~0.66 of the memory used by the bare terrain. I don't think that's unreasonable, others might think differently. (I could have very well modelled every rivet, nut and bolt on it, I didn't, why? because there are pretty good techniques of faking that, with plausible results. If you look really hard you notice that the detail is all fake, that the reflection has nothing to do with the actual environment etc... but that's irrelevant for the normal use case) You look at view-distance/fog just as an atmospheric phenomenon, that you think should be represented verbatim, well it's not. It's not just that in any case, and if for it to fulfil all its roles you need to abdicate from the verbatim aproach, well then I'm sorry but my opinion is that you should. I never claimed that it's the only resource management device, I only claimed that it's role is much more than just visual cue to the environment, and that role should not be underestimated, or thrown aside... Regards, Emilian |
From: Vivian M. <viv...@li...> - 2013-02-24 18:47:04
|
Emilian wrote > > On Saturday, February 23, 2013 07:08:41 Renk Thorsten wrote: > >A lot of stuff, mostly deflecting the discussion to other irelevant > >points > > > > * Thorsten > > While I should know better than to answer to this, as it will again get > deflected to other areas, let's imagine ourselves a simple scenario: > > Let's say I'm an average user with a 32bit system, I can barely find my way > through the maze of menus and dialogs flightgear presents to me, and I want > to use this more advanced weather simulation engine. After I accidentaly > find out how to enable it (it's hidden under a rather confusing radio-button > selection "Model overall weather conditions based on metar"), great, select > "Fair weather" scneario, Apply, OK, let's go flying. > I muck around, wonder at the nice sky/clouds, notice that my visibility > improved somewhat, then bam after 15 minutes flightgear crashes, uhm.. > oohh, why did that happen? That didn't happen before? > All I did was change the way the weather is interpreted... What's wrong > here??? > > Well, now let's see what actually happens in a default flightgear instalation > (all settings are from preferences.xml, and Environment/local-weather- > defaults.xml) > ->trees are enabled by default > ->default visibility with "Fair weather" is ~16km local weather comes in > ->and sets a default value for max visibility of 120km > (o.O), ok, that's a bit far, but in practice I see that's actually hovering in the > 40km range (+-10km based on altitude). (roughly 3x more than the default) > > So in the default scheme we load 9 tiles at startup, then we keep loading tiles > in the direction we're traveling, and those initial tiles remain resident in the > tile cache for a while (in case you decide to double back). > But let's stay with the startup condition. when you ramp up the visibility to > 40km you demand 3 extra "rings" of tiles to be loaded. That would give you at > least 69 tiles loaded (81 if the "rings" are square). So that's an instant increase > of 7-9x the memory requirements of the terrain + objects + trees (tres being > the largest contributor here), just because you click an option that says it just > _interprets_ the METAR string differently. Do you think that's an expected > result? I don't. > > Well, our average user might have read the manual, might have mucked > about with the visibility setting before, and he remeber that all things being > the same, visibility is what impacts performance/memory the most, so he > decides to try again, this time trying to use z/Z to limit how far the visibility > goes, maybe he gets lucky and it won't crash again, but he's in for a surprise... > z/Z doesn't work... > > You might argue that he should know better, go into the advanced settings > dialog, figure out what all those sliders and selection boxes do, etc, etc... > But remeber, our user is an average one, he wants things to just work (with > time, he might find a use for the more advanced configuration stuff, but for > now he's not interested, he just want to click something, and be done with > it), The z/Z case above might be a lucky one where he might have read the > manual. > > The problem is not with "Advanced weather" in itself, the problem is in the > details of a part of it, themost important part from the user POV. Your > approach might work, given unlimited resources, but as it is Flightgear has to > run on a variety of puny little desktop/laptop machines. You have already > implemented half of the control, is it so hard to implement the rest and > provide a system that's consistent with the rest? > Yes it breaks the "real world" scheme, but this is a simulation, we lie, carefully > crafted lies, that give a global impression of truth, of copying the real world > behaviour, but in the end they are lies. Fog/view-distance is one of those > lies, they need just be plausible, not a faithful representation of the real > world (and a faithful representation of the real-world is practically impossible > given the current state of the technology). > > You are comfortable with abdicating from that when it suits you, but where it > really matters you defend the "minute detail faithfull representation of the > real world scheme" vigorously... Don't you think thre's something amiss > here? > > As someone said in another thread, there are various techniques that are not > constrained by the "real-time" requirement, that do a pretty good job of > giving you "real" results, but their place is not here. Here we have to do our > best to trick the mind, while doing that as fast as possible, with a reasonable > usage of resources. Just because you can set visibility to 1000km doesn't > mean you should, just because you can shove a lot of data into a shading > scheme and get back "photoreal" results doesn't mean you should, if said > results reduce performance, increase the probability of running out of > memory, etc. > > You'll argue again with the IAR as an example. Well, take a look at those > numbers again, and you'll see that for the amount of detail it presents to the > user it uses ~0.66 of the memory used by the bare terrain. I don't think that's > unreasonable, others might think differently. (I could have very well > modelled every rivet, nut and bolt on it, I didn't, why? because there are > pretty good techniques of faking that, with plausible results. If you look really > hard you notice that the detail is all fake, that the reflection has nothing to do > with the actual environment etc... but that's irrelevant for the normal use > case) > > You look at view-distance/fog just as an atmospheric phenomenon, that you > think should be represented verbatim, well it's not. It's not just that in any > case, and if for it to fulfil all its roles you need to abdicate from the verbatim > aproach, well then I'm sorry but my opinion is that you should. > I never claimed that it's the only resource management device, I only claimed > that it's role is much more than just visual cue to the environment, and that > role should not be underestimated, or thrown aside... > I'm probably a day late and a dollar short here - but try as I will so far I've failed to find a visibility slider under environment->weather. It's probably staring me in the face - but could someone point it out to me? Vivian |
From: Stefan S. <ni...@de...> - 2013-02-24 20:37:43
|
On Sunday 24 February 2013 18:46:08 Vivian Meazza wrote: > I'm probably a day late and a dollar short here - but try as I will so far > I've failed to find a visibility slider under environment->weather. It's > probably staring me in the face - but could someone point it out to me? In the Weather dialog: Model overall weather conditions based on METAR Advanced Settings Thermic Visibility and Settings Max visibility Stefan |
From: Vivian M. <viv...@li...> - 2013-02-24 23:40:47
|
Stefan Seifert wrote > > On Sunday 24 February 2013 18:46:08 Vivian Meazza wrote: > > > I'm probably a day late and a dollar short here - but try as I will so > > far I've failed to find a visibility slider under > > environment->weather. It's probably staring me in the face - but could > someone point it out to me? > > In the Weather dialog: > > Model overall weather conditions based on METAR Advanced Settings > Thermic Visibility and Settings Max visibility > Got it - thanks - as I said staring me right in the face. So, am I right in thinking that we have 3 different ways of setting the vis: 1. z/Z - works with Basic Weather - sets the vis directly. Does not work with Advanced Weather, but is still available when that option is selected and looks as if it should work. 2. Slider in Advanced Weather - Advanced Settings - sets a max value . The displayed vis in the min value of this and the value derived by Advanced Weather. (Is this true? I'm only inferring this). 3. Checkbox named realistic visibility in Advanced Weather - Advanced Settings. What does this do? I can't see any effect here. I used the old terms Basic/Advanced Weather, but I note that these have disappeared from the GUI. How would the user know why or when he would chose ether option? Scope for some rationalisation here I would think. I'm extremely disappointed to see that while I was off on a short holiday that this discussion has deteriorated to the point that one of a valued developers feels that he can no longer contribute to FG. Vivian |