Re: [Flightgear-devel] Low visibility issues
On Sun, Mar 3, 2013 at 2:07 AM, Renk Thorsten thorsten.i.r...@jyu.fi wrote: *Please* don't drop the z/Z key binding. This is one of the most useful and direct controls we have to affect the visual experience. (...) It's fecking difficult to operate a mouse/menu/slider while using a joystick unless you are ambidextrous (which I'm not) Can anyone please explain to me why one needs to change visibility manually during flight so often? [snip] I understand that visibility needs to be manually controllable for setting up specific training conditions. But this doesn't need to happen in-flight all the time and can be from the menu. I understand that visibility has a role for memory management, but that doesn't need to be done in-flight either, memory management can be done much more efficiently by setting a max. visibility value once and just store it. You can't micro-manage memory consumption by adjusting visibility all the time because a) you'd need to have an open system monitor to see memory occupancy and b) you'd need to know in advance how much memory the next tiles to be loaded will have. [snip] The question to me is not 'Do some people use it?' The question we should answer is 'Given the alternative between a key binding to change visibility and assigning a new key-binding to a function you can actually perform in a cockpit, isn't the second option better'? For instance assume we would assign z/Z to changing the NAV1 frequency or the heading of the AP - these are functions which I perform basically all the time when I don't do pure VFR and it's rather awkward to open the menu or hit a tiny clickspot. Personally, I think reserving key binding for things which you can really do in a real cockpit is not a bad concept. And I would really like to understand why some people think it's necessary to change the visibility so often that a menu option doesn't work for them whereas I need to change my NAV frequencies in the menu (while flying the plane with the mouse... I can do this with just one control device) As a Linux desktop user, in recent times I've come to expect this kind of discussion to be followed by permanent deletion of the entire feature in question, especially when it's related to user configuration and controllability. So I'll certainly cop to over-reacting on that basis - it was starting to sound like visibility would no longer be user-controllable at all. I have no issue with setting it by a slider or whatever, only with the idea of deleting it altogether, and it sounds like that wasn't being discussed after all. Given that, your detailed rationale for selecting key bindings makes a lot of sense. Gary -- 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 10:54 AM, 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. On Fri, Mar 1, 2013 at 8:02 AM, Renk Thorsten thorsten.i.r...@jyu.fi wrote: I don't think any of this is a real issue or under debate at the moment (?) - the whole discussion about z/Z is if the keybinding should be removed [...] *Please* don't drop the z/Z key binding. This is one of the most useful and direct controls we have to affect the visual experience. It allows the user to directly control the view out the window, trade off visuals for frame rate and smoothness on older hardware or complex scenery, and trade off realism of flight experience for the simple pleasure of looking out the window for those more into tourism. It can be useful for modifying a built-in weather scenario that's close but not exactly what is wanted. In short, it allows even the newest user to control their FlightGear visual experience according to their particular use case and need for realism. I have no problem at all with disabling the keys when (say) advanced weather is selected, but for several classes of users and types of use, it really is an important capability and is used often. Gary -- 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 2 Mar 2013, at 17:09, Gary Carvell gary.carv...@gmail.com wrote: I have no problem at all with disabling the keys when (say) advanced weather is selected, but for several classes of users and types of use, it really is an important capability and is used often. I don't see anything in your list, that wouldn't work as a slider in a suitable GUI dialog. (Which dialog it is, is a question to be decided, for sure) The advantage there being we can disable the slider, when advanced weather is selected, and provide a label explaining *why*. 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
Gary Carvell wrote: On Thu, Feb 21, 2013 at 10:54 AM, 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. On Fri, Mar 1, 2013 at 8:02 AM, Renk Thorsten thorsten.i.r...@jyu.fi wrote: I don't think any of this is a real issue or under debate at the moment (?) - the whole discussion about z/Z is if the keybinding should be removed [...] *Please* don't drop the z/Z key binding. This is one of the most useful and direct controls we have to affect the visual experience. It allows the user to directly control the view out the window, trade off visuals for frame rate and smoothness on older hardware or complex scenery, and trade off realism of flight experience for the simple pleasure of looking out the window for those more into tourism. It can be useful for modifying a built-in weather scenario that's close but not exactly what is wanted. In short, it allows even the newest user to control their FlightGear visual experience according to their particular use case and need for realism. I have no problem at all with disabling the keys when (say) advanced weather is selected, but for several classes of users and types of use, it really is an important capability and is used often. I agree. I am just finishing a patch which leaves z/Z as is for Basic Weather, but makes z/Z control max vis. for Detailed Weather, just like the slider in the menu. Should give us the best of both worlds. Testing atm, should be in fgdata soon. 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
James Turner On 2 Mar 2013, at 17:09, Gary Carvell gary.carv...@gmail.com wrote: I have no problem at all with disabling the keys when (say) advanced weather is selected, but for several classes of users and types of use, it really is an important capability and is used often. I don't see anything in your list, that wouldn't work as a slider in a suitable GUI dialog. (Which dialog it is, is a question to be decided, for sure) The advantage there being we can disable the slider, when advanced weather is selected, and provide a label explaining *why*. It's fecking difficult to operate a mouse/menu/slider while using a joystick unless you are ambidextrous (which I'm not). And even then I shouldn't think it easy. You can try using the Detailed Weather/Advanced Settings. There is absolutely no need to disable z/Z in Detailed Weather. It ain't broke - could we avoid fixing it and turn our attention to something that is like memory usage or moving clouds? 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
*Please* don't drop the z/Z key binding. This is one of the most useful and direct controls we have to affect the visual experience. (...) It's fecking difficult to operate a mouse/menu/slider while using a joystick unless you are ambidextrous (which I'm not) Can anyone please explain to me why one needs to change visibility manually during flight so often? We're trying to create a simulated experience. Which means that for me there are things which I adjust before flying, i.e. I set the airplane, the location, the weather, the environment, the time,... And there are things which I can adjust in-flight - there's the throttle, levers for gear, flaps, various buttons, where I look and what I focus on. But the simulated environment in-flight largely is what it is if you aim for realism of the experience - if the weather deteriorates, I have to deal with it. If the visibility drops below VFR conditions, I have to change my plans. Conceptually, I understand that key bindings make sense in the context of a simulator standing for things I can do in-flight in the cockpit, because I may need to be able to perform these actions quickly or while I'm doing something else (like controlling an airplane). In many cases, we do not have a keybinding, and performing a real possible action ends up being awkward - you need to mouse-click something while flying on, or you even need to open an menu. Changing visibility magically is not of this group, it's not a realistic option which you could perform in a real cockpit. I understand that visibility needs to be manually controllable for setting up specific training conditions. But this doesn't need to happen in-flight all the time and can be from the menu. I understand that visibility has a role for memory management, but that doesn't need to be done in-flight either, memory management can be done much more efficiently by setting a max. visibility value once and just store it. You can't micro-manage memory consumption by adjusting visibility all the time because a) you'd need to have an open system monitor to see memory occupancy and b) you'd need to know in advance how much memory the next tiles to be loaded will have. About the only reason why I can see one would want to adjust visibility often in-flight is 'cheating' - you just take a quick look in bad visibility where you are. This is fine, it's a simulation after all, we have AP support for planes which have no AP in reality and an in-built GPS - but why do we need to support that with a key-binding? The question to me is not 'Do some people use it?' The question we should answer is 'Given the alternative between a key binding to change visibility and assigning a new key-binding to a function you can actually perform in a cockpit, isn't the second option better'? For instance assume we would assign z/Z to changing the NAV1 frequency or the heading of the AP - these are functions which I perform basically all the time when I don't do pure VFR and it's rather awkward to open the menu or hit a tiny clickspot. Personally, I think reserving key binding for things which you can really do in a real cockpit is not a bad concept. And I would really like to understand why some people think it's necessary to change the visibility so often that a menu option doesn't work for them whereas I need to change my NAV frequencies in the menu (while flying the plane with the mouse... I can do this with just one control device) * 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
Am 28.02.2013 16:38, schrieb Curtis Olson: We've always been able to set the individual weather parameters, either through the built in weather dialog box, or by setting raw property values. Setting raw property values allows nasal script control over the weather (as I'm sure you well know) :-) but it also allows external control of the weather, for instance by some external gui tool, or by some tool that wants to setup equivalent visual conditions across multiple FlightGear PC's running in sync. And please don't forget, there are command line options like --visibility, --wind, --random-wind etc. All those options override the other weather-magic. It took me quite some time to make all this behave in a somewhat reasonable way with basic-weather and I'd love to keep all that functionality. Best, Torsten -- 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
Torsten wrote Am 28.02.2013 16:38, schrieb Curtis Olson: We've always been able to set the individual weather parameters, either through the built in weather dialog box, or by setting raw property values. Setting raw property values allows nasal script control over the weather (as I'm sure you well know) :-) but it also allows external control of the weather, for instance by some external gui tool, or by some tool that wants to setup equivalent visual conditions across multiple FlightGear PC's running in sync. And please don't forget, there are command line options like --visibility, -- wind, --random-wind etc. All those options override the other weather-magic. It took me quite some time to make all this behave in a somewhat reasonable way with basic- weather and I'd love to keep all that functionality. At a very personal level, I like being able to adjust the vis other factors using the keyboard with my left hand while using a joystick with my right. I certainly can't imagine flying the Camel and trying to manipulate a mouse and menu. 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
So whatever we do, we can't override the ability to get low level granular control of the weather parameters, and not just so that advanced weather can manipulate them exclusively, also so that external tools can manipulate them without advanced weather getting in the way or overriding the settings. (...) And please don't forget, there are command line options like --visibility, --wind, --random-wind etc. All those options override the other weather-magic. It took me quite some time to make all this behave in a somewhat reasonable way with basic-weather and I'd love to keep all that functionality. I don't think any of this is a real issue or under debate at the moment (?) - the whole discussion about z/Z is if the keybinding should be removed, but the internal control structure of the system shouldn't change. The current structure seems sane to me: * shaders which render the visibility take values from the property tree and are agnostic to how these got there * so does the terrain manager * the weather system has an 'idle' mode in which no properties are set by the system automatically, and it is possible to define weather with the property browser * Basic Weather can run and fill the properties based on interpolation tables * Advanced Weather can run using the idle mode and set the parameters from Nasal - once you stop the Nasal loops, you're back in idle mode and can set properties by hand * any external/future system can likewise use the idle mode to set parameters - any shader will render these parameters regardless of how they were put into the tree. - what you can't do is run two different systems at the same time The only problem arising is that Atmospheric Light Scattering uses three visibility-defining parameters to render rather than one, so if you define only one of them on the commandline, the rendering task is ill-defined and the framework falls back to the defaults as specified in environment.xml - which may or may not be appropriate for the weather situation you have in mind. The system is sane in the sense that it will always use the lower of visibility and ground visibility, so if you set visibility to a very low value, you'll not get to see the higher default ground-visibility on the ground. You can in any case specify the info by setting /environment-ground-visibility-m and /environment/ground-haze-thickness from the commandline and you will see the system responding appropriately, and Basic Weather or any external application could likewise set these parameters to other than default if so desired. There's a also host of secondary calculation of light attenuation and color rotation underneath clouds which are pretty complicated, and there's no chance to just set them to the right defaults - so unless you have a system which does the equivalent of these computations as done by Advanced Weather and sets the properties for the shader, you will get implausible lighting under some conditions. But that's an aestetic issue - FG remains usable with the defaults, it just doesn't give you the full eye candy. The whole part of the discussion about the max. visbility slider and realistic visibility checkbox in Advanced Weather is a completely different beast because it refers to Nasal-internal parameters which are not seen when any other system runs and not relevant for the shaders or the FG core. I think we need to keep parameters which are exchanged between subsystems in the discussion separate from parameters which stay inside a subsystem - there are many different wind parameters set by property rules for the water shader, others written for internal reference by Advanced Weather, yet others used to store the config of Basic Weather - but none of them has any relevance for the FDM for instance. So if there's any genuine concern that we might block options for any other development, I'd like to know what it is, because keeping options open is something which is high on my agenda as well. * 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
Say, while you all are on the subject of key bindings, could anyone tell me where these keymappings are defined in flightgear? My friend is having a severe (to him) issue with the program, in that he loves flying in the sim but is running I believe three monitors. He is able to get the view across all three of his monitors by setting a very wide field of view, but this involves clicking for a _very_ long time on the widen field of view key. I'd love to be able to customize his build for him so it either defaults to where he wants it or else changes in much larger increments. Also, I just got myself a new joystick with fancy buttons all over it, and would like to remap some functions to them. Any advice appreciated! Thanks, Chris On Thu, Feb 28, 2013 at 1:31 AM, Renk Thorsten thorsten.i.r...@jyu.fiwrote: You asked for ideas for a more descriptive text - I've gone one better and added descriptive texts to the gui. My design aim was to provide the average user with some indication of which option he should choose and in which circumstance. It's only a shallow redesign. It would be nice, I think, to allow max vis range to be as low as 10kms, and also if this could be driven by z/Z. However, these items are beyond the scope of what I set out to do. Thanks. I can do the first item easily (I do think 10 km max visibility are a bit on the low side, but it doesn't hurt anyone..). As for z/Z - can we reach a decision first what to do with this? James and Stuart seemed to be considering to drop this key binding, and I would actually prefer that as well. Is there a compelling reason to manage visibility by key? For me, this resembles more an arcade game strategy than a realistic simulation. (If we keep z/Z, it'd be nice if anyone can give me a pointer how to link it with the max. visibility or just do it, because I don't know how it's done...) * 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 -- 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 28, 2013 at 4:47 PM, Chris Calef wrote: Say, while you all are on the subject of key bindings, could anyone tell me where these keymappings are defined in flightgear? My friend is having a severe (to him) issue with the program, in that he loves flying in the sim but is running I believe three monitors. He is able to get the view across all three of his monitors by setting a very wide field of view, but this involves clicking for a _very_ long time on the widen field of view key. You may also wish to visit this page on our wiki which talks about how to create a custom xml configuration file for multiple cameras on multiple displays: http://wiki.flightgear.org/Howto:Configure_camera_view_windows The system even allows you to define an independent camera for each display so you don't have to deal with increasing distortion at the fringes and can spread the view offset by a little extra to account for the margins on your monitor (so a straight line such as a runway edge flows straight into the next display without forming a stair step. You can search out README.multiscreen -- located in $(FGDATA)/Docs/README.multiscreen if you have FlightGear installed. There are a couple approaches that are supported, ranging from creating a 3 windows, one for each display to creating a single window that spans all the displays and defining separate camera parameters for each 1/3 of the window. If you spend a bit of time tweaking this, you can get way better results than simply stretching a window across three displays and. Regards, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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
You asked for ideas for a more descriptive text - I've gone one better and added descriptive texts to the gui. My design aim was to provide the average user with some indication of which option he should choose and in which circumstance. It's only a shallow redesign. It would be nice, I think, to allow max vis range to be as low as 10kms, and also if this could be driven by z/Z. However, these items are beyond the scope of what I set out to do. Thanks. I can do the first item easily (I do think 10 km max visibility are a bit on the low side, but it doesn't hurt anyone..). As for z/Z - can we reach a decision first what to do with this? James and Stuart seemed to be considering to drop this key binding, and I would actually prefer that as well. Is there a compelling reason to manage visibility by key? For me, this resembles more an arcade game strategy than a realistic simulation. (If we keep z/Z, it'd be nice if anyone can give me a pointer how to link it with the max. visibility or just do it, because I don't know how it's done...) * 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
Hi Thorsten, Using z/Z to adjust visibility is something from the earliest days of the simulator project, before METAR weather, probably before clouds, and the sky dome. I don't personally mind if the z/Z key bindings go away. What I do care about though is that FlightGear continues to be useable as a flight training tool. An instructor working with a student may wish to set a specific visibility, specific cloud layers, specific winds, specific turbulence, all as part of a training scenario designed to instruct or challenge or catch a student off guard. We've always been able to set the individual weather parameters, either through the built in weather dialog box, or by setting raw property values. Setting raw property values allows nasal script control over the weather (as I'm sure you well know) :-) but it also allows external control of the weather, for instance by some external gui tool, or by some tool that wants to setup equivalent visual conditions across multiple FlightGear PC's running in sync. So whatever we do, we can't override the ability to get low level granular control of the weather parameters, and not just so that advanced weather can manipulate them exclusively, also so that external tools can manipulate them without advanced weather getting in the way or overriding the settings. BTW, your email name is configured as Renk Thorsten so if you do find yourself being called by your last name, it may be a simple misunderstanding deriving from that. My dad calls all his neighbors by their last name out of friendliness and respect, so it could also be that too. :-) Thanks, Curt. On Thu, Feb 28, 2013 at 3:31 AM, Renk Thorsten wrote: You asked for ideas for a more descriptive text - I've gone one better and added descriptive texts to the gui. My design aim was to provide the average user with some indication of which option he should choose and in which circumstance. It's only a shallow redesign. It would be nice, I think, to allow max vis range to be as low as 10kms, and also if this could be driven by z/Z. However, these items are beyond the scope of what I set out to do. Thanks. I can do the first item easily (I do think 10 km max visibility are a bit on the low side, but it doesn't hurt anyone..). As for z/Z - can we reach a decision first what to do with this? James and Stuart seemed to be considering to drop this key binding, and I would actually prefer that as well. Is there a compelling reason to manage visibility by key? For me, this resembles more an arcade game strategy than a realistic simulation. (If we keep z/Z, it'd be nice if anyone can give me a pointer how to link it with the max. visibility or just do it, because I don't know how it's done...) * 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 -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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 Renk wrote ... snip The design idea behind the current GUI was that the user should no longer be presented with two different weather options to choose from, but just see a single GUI which controls weather. If that is still the idea, it works remarkably well. If you have an idea for a more descriptive text, please let us know. Snip ... You asked for ideas for a more descriptive text - I've gone one better and added descriptive texts to the gui. My design aim was to provide the average user with some indication of which option he should choose and in which circumstance. It's only a shallow redesign. It would be nice, I think, to allow max vis range to be as low as 10kms, and also if this could be driven by z/Z. However, these items are beyond the scope of what I set out to do. I've pushed it to fgdata. 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
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
Re: [Flightgear-devel] Low visibility issues
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 -- 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
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 -- 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
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). True. 3. Checkbox named realistic visibility in Advanced Weather - Advanced Settings. What does this do? I can't see any effect here. It changes the internal model used to derive visibility as a function of altitude. In reality, once you clear the lowest convective layer which is normally pretty hazy, the visibility often goes to hundreds of kilometers. The checkbox largely controls where Advanced Weather would set it - if you don't check it, visibility increases more slowly with altitude, if you check it, you will in many weather situations open the visibility to 120 km (or whatever max. value you specified) a few hundred meters above the lowest convective layer. Basically, checking the box means 'model my visibility as real as you can do within the FG framework' and unchecking it 'model it halfway realistically, but keep an eye on performance and memory issues'. 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. The design idea behind the current GUI was that the user should no longer be presented with two different weather options to choose from, but just see a single GUI which controls weather. If that is still the idea, it works remarkably well. If you have an idea for a more descriptive text, please let us know. 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. Is there an xml way to do that? I know how to do it with a listener from Nasal, but that seems like an overkill... Or am I thinking too complicated? In other matters, I was able to make some progress. I've replaced the hard cutoff by a smoothed, sliding cutoff, so the circle is gone. Fogging clouds properly turns out a no-go because the fog color is way too expensive to obtain, but it occurred to me that one can cheat here - rather than fading to fog color, one can fade clouds to transparent for distances larger than 2-3 times visibility. That gives the desired disappearance of the cloud layer in poor visibility from below (I have to check if it has any undesirable side effects in situations with high visibility). It's also neat because the fragment shader will drop transparent pixels - so performance of fading to transparent is better than fading to fog color. Since there are still unspecified but serious concerns about loading 20 km of terrain, I've hacked my way around it... so please drop the idea. This is what CAT IIIb now results in: http://users.jyu.fi/~trenk/pics/catIIIb.jpg There are some remaining issues. Specular light is way too strong in the picture, I have to tune that down (that's also the case in default rendering). As you can see, the lights are way too visible for CATIIIb - it took me 5 minutes to figure out that they are actually 100% fogged, but since they are fogged in the default scheme for some reason, the fog color is much brighter, and so it seems as if they were unfogged. Does anyone know where the various runway and other lights enter the rendering pipeline and what should be done to get a shader to process them? Can they be assigned to model-default, or do they need extra treatment? A similar issue is the sun (which is never fogged). It used to be hidden by the clouds, but if we fade the clouds to transparent rather than to fog color, that no longer works. In the default scheme, I think the sun becomes hidden when the skydome unloads - but that doesn't work either, the scheme needs the skydome. So we'd need some control over what we show of the sun - that's also relevant if the sun is below the horizon, but the horizon terrain is rendered by the skydome - in this case the sun can be seen through the 'terrain'. Does anyone have an idea how we could control the appearance of the sun? * 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 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
Re: [Flightgear-devel] Low visibility issues
On Saturday 23 February 2013 12:21:02 Emilian Huminiuc wrote: 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). So there's a bug in the tile cache. When caching stuff leads to an out of memory condition, the cache is at fault. The whole purpose of such a cache is to improve performance. A crashed application has the worst performance of all. So this cache should be fixed to automatically reduce the number of cached tiles in low memory conditions. 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... So the manual is wrong as well. Like you said yourself, trees give a larger memory hit than terrain. So the first thing to do should be to disable trees. 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. Since advanced weather seems to have a slider for maximum visibility, why not change the key binding to make z/Z control this maximum visibility? This still leaves control of visibility with advanced weather but should satisfy the people using this key for memory management (however wrong that approach may be in my opinion) 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... From this whole discussion I get the impression that FG's memory management simply sucks. We have caches eating too much memory at times, several memory intensive features but no information about how much memory they really use. Yet still we push responsibility for keeping memory requirements within the limits of his machine to the user. The one who has the least chance of getting it right. The solution is not to give crude tools like limiting visibility to the user. The solution is to fix FG to be consious about how much memory is available and make the best use of it. Yes, many games simply limit visibility if memory or performance pressure gets high. But FG is a flight simulator. Visibility is a very important part of flight (at least for me as a VFR pilot). Stefan -- 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 Saturday, February 23, 2013 11:51:55 Stefan Seifert wrote: The solution is not to give crude tools like limiting visibility to the user. The solution is to fix FG to be consious about how much memory is available and make the best use of it. Yes, many games simply limit visibility if memory or performance pressure gets high. But FG is a flight simulator. Visibility is a very important part of flight (at least for me as a VFR pilot). Stefan Guess what happens when memory is limited and visibility is set to 120km? You see the end of the world, because no more tiles can be loaded to reach that distance. Guess what you need to adjust then, independent of what the real world says? Visibility distance (implicitly fog) to mask it. Regarding trees: you think that way, I might, someone else in the know might too, but the average user sees that they work well with his setup in the default condition, why would he want to disable them? The only thing that new setting advertises is it reads the METAR string in a more advanced way... Manual setting of this has the added benefit that you're not moving tiles back and forth through the tile cache/display as memory becomes more or less available. You set a max setting that suits your machine and or the area you fly in (in the carribean you can easyly reach that 120km, not so much at KLAX) and you're done with it. And why should you have to set that in _n_ places, when there was a perfectly reasonable documented setting in the first place. This thing with the visibility is just one part of a bigger problem here, that someone doesn't want, or doesn't uderstand that he has to take shortcuts, use tricks, and abdicate from a faithfull model of the real world. Instead he shoves everything but the kitchen sink in, disregarding what effects that might have, expects everyone else to accomodate any needs that might arise from that and considers any bit of critique or negative comment as a personal affront. Now if that's how things are supposed to work around here, I'm not the one to decide, but for me it's not. Regards, 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
On Saturday 23 February 2013 13:20:49 Emilian Huminiuc wrote: Guess what happens when memory is limited and visibility is set to 120km? You see the end of the world, because no more tiles can be loaded to reach that distance. Guess what you need to adjust then, independent of what the real world says? Visibility distance (implicitly fog) to mask it. I just tried it. Turned off random trees, objects and buildings and set visibility to about 120km using the z key with basic weather. fgfs used about 960MB of memory. That's about 4€ worth of memory and well below any 32 Bit limit. I do have automatic scenery download enabled and it did not see a reason to download anything, so I'd say I do have the scenery tiles for this visibility range. Regarding trees: you think that way, I might, someone else in the know might too, but the average user sees that they work well with his setup in the default condition, why would he want to disable them? He doesn't. Because he doesn't know they use so much memory. Instead he fiddles around with something that according to my test actually doesn't seem to help all that much. The only thing that new setting advertises is it reads the METAR string in a more advanced way... There are plenty of other options that do not advertise in any way how they affect memory usage. So it would seem that advanced weather simply sticks to what's considered normal for FG features. Manual setting of this has the added benefit that you're not moving tiles back and forth through the tile cache/display as memory becomes more or less available. You set a max setting that suits your machine and or the area you fly in (in the carribean you can easyly reach that 120km, not so much at KLAX) and you're done with it. And how do I as a user know how much visibility I can afford? Do you suggest the solution for users is to do trial and error until he finds a setting where FG doesn't crash 5 minutes before landing? I just can't see how this would be better than FG just being more intelligent about memory usage. And why should you have to set that in _n_ places, when there was a perfectly reasonable documented setting in the first place. Why do you want the user to have to repeatedly press a key after starting the sim instead of setting the maximum visibility once and for all in the advanced weather dialog? In other words: why should the user press a key _n_ times instead of setting a slider once? This thing with the visibility is just one part of a bigger problem here, that someone doesn't want, or doesn't uderstand that he has to take shortcuts, use tricks, and abdicate from a faithfull model of the real world. Instead he shoves everything but the kitchen sink in, disregarding what effects that might have, expects everyone else to accomodate any needs that might arise from that And I'm very very grateful for this. As a glider pilot I can't express how much I love having even a somewhat realistic simulation of weather and atmospheric effects. You know what's also great about it? It's all optional! If a user doesn't care about all these realistic details, he can just turn them off. Or even more: not turn them on since they are off by default anyway. and considers any bit of critique or negative comment as a personal affront. This is simply not true. While I think that sometimes Thorsten may give people more benefit of the doubt, I'm actually very impressed with how civilised and patiently he reacts to criticism and how much time he spends explaining his rationale. Your statement is untrue and unfair and does not belong to a technical discussion. Stefan -- 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 Saturday, February 23, 2013 13:09:29 Stefan Seifert wrote: Why do you want the user to have to repeatedly press a key after starting the sim instead of setting the maximum visibility once and for all in the advanced weather dialog? In other words: why should the user press a key _n_ times instead of setting a slider once? I don't care if it's _a_ key / slider / command line option/ registry setting/automagic ... just use one, and be consistent about it's use, is that so hard to do? If there's a docummented option (key shortcut, command-line switch, property setting) about setting that, is it so hard to obey it? If it's there chances are it's there for a good reason. Use that, don't go about creating layer after layer of property options that duplicate/triplecate existing ones, just because you canand then expecting everyone else to fold in line. I have nothing about the core of the Advanced weather engine, I have an issue of how you interact with it, and how it interacts with other parts of the whole system... and in my view this is broken. I also have nothing against the idea of the atmospheric scattering, I have an issue with how it's done, which is suboptimal in my view... and again of how you can interact with it/ how it affects other systems, and how it's affected by other systems. These are not just isolated litle bits that can do all they want without affecting anything, they're integrated into a bigger picture, and a small seemingly insignificant change can bring down the whole system, why? Just because someone saw that it's possible to set view distance to 1000 km, or that his gpu can handle 1k LOC in a shader. And all this is solvable just by adding a crappy line of text as a warning in a dialog, and making a slider take the global setting. Just that. BUT no, we can't do that, because it's not a faithfull model of the real world then... As if everything else would be much more than a few little rgb points on a display. Regards, 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
Emilian, just up-front to keep this discussion focused on what it actually is about: Do you, or do you not agree that 20 (or 16) km terrain loaded regardless of the visibility is a sane value? Somehow, you still haven't really answered the question, you're just expressing unspecified 'concerns' and attacking Advanced Weather. 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. At this point you've already made a decision that you do not want to run the default weather engine but this 'more advanced engine'. Some folks might say that you could guess that it also needs more resources. As for the 'rather confusing radio button selection', there was a discussion here initiated by Stuart (who did this version of the weather GUI) how to do this properly. Presenting the user a single GUI which blurs the difference between Advanced Weather and Basic Weather has considered a design goal. Don't you think it would have been more useful then to express your concerns? The way the GUI works is not my idea, but it's based on a decision following a discussion in which I had my say, so I back it now. improved somewhat, then bam after 15 minutes flightgear crashes, uhm.. oohh, why did that happen? That didn't happen before? No, that's in fact not what happens. What actually happens is that as visibility expands, you're going to realize that the terrain edges become visible because the visibility is greater than the terrain LOD setting. It so happens that we have precisely the question answered by Bjoern describing running Advanced Weather on an old 2 GB machine. http://www.flightgear.org/forums/viewtopic.php?f=68t=19201#p177724 So rather than a crash, you get the end of terrain, which isn't optimal but might prompt you to investigate either the weather options or the LOD settings (I think we should be able to handle that better, but that's a different story). I also think max. visibility set by default to 120 km is a mistake - it must have slipped in, the value I had forseen is 35 km and I will correct this). 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. It's _optional_ for god's sake. Which means you don't have to use it if you don't like the approach, end of story. Some folks (like me) do think it matters, so they check the option. If there's a docummented option (key shortcut, command-line switch, property setting) about setting that, is it so hard to obey it? Yes. Because which is the visibility you want to affect? Ground visibility? The visibility in the rain patch ahead of you? The visibility at your altitude? Visibility is re-computed every frame, that's why you can't adjust it to a single value. I have nothing about the core of the Advanced weather engine, I have an issue of how you interact with it, and how it interacts with other parts of the whole system... and in my view this is broken. I also have nothing against the idea of the atmospheric scattering, I have an issue with how it's done, which is suboptimal in my view... and again of how you can interact with it/ how it affects other systems, and how it's affected by other systems. This is called development. We used to have a system in which visibility is a single value, and for that setup all you need to do is set the value. Now we have an (optional) new and more sophisticated system in which light is different at every point in the scene and in which visibility is a complicated beast changing for every point of the scene. (This is also a discussion which we had on the list...) How on earth do you expect it to interact with a previously existing system which was never designed to handle that new concept of visibility or light? Regardless of how well that old system was designed and documented, it can not deliver all the information which the new system needs. Advanced Weather as well as Atmospheric Light Scattering have genuine new requirements as to what input they need. You can't expect that they interface seamlessly with systems like Basic Weather or a visibility changing key which were never designed to have that kind of information about the environment. If you want weather which interacts with the terrain, you have to have the terrain in memory by the time you build the weather. It's not 'just because I can',
Re: [Flightgear-devel] Low visibility issues
Let's please be honest here. I'll repeat it once more, I don't have a personal problem with you, I have a problem with your methods, and AFAIK I'm not the only one, but (un)fortunately, the other ones chose to stay silent... If you refer to my methods of coding, I don't think we've had too much silence here. Vivian and ThorstenB are rather outspoken in that they think large-scale coding lin Nasal such as done for Advanced Weather is bad, Mathias hasn't made a secret out of his dislike for the way Atmospheric Light Scattering is set up, James has let me know that he thinks my GUI is too complicated, so has Stuart in the past... there've been plenty of productive and unproductive disagreements. I think this misses the point with regrad to what is going on now. Could Mathias have written Atmospheric Light Scattering? Perhaps - clearly he is far better in the technical aspects of GLSL than I will ever be, but there's also a fair share of physics and approximation schemes in, something I am rather good at. Would Atmospheric Light Scattering, written the way Mathias would write it, be better? Almost certainly. But all that's a bit beside the point, because neither he nor anyone else who knows after the fact how it should really have been done did actually write it or try help writing it. The choice is not between what we have now and a 'properly' (whatever that means, and whoever gets to define the term) written bit of software because I would not have taken six months off from work to catch up with Mathias' comprehension of rendering. The choice is between having nothing and having Atmospheric Light Scattering as I can write it with the help I can get (obviously, things like Stuart's coding of a Nasal interface to create clouds did help a lot for Advanced Weather). Strangely enough, as for interfacing and the way weather parameters are set, I seem to get along just fine and find reasonable solutions with Stuart and TorstenD who are the maintainers of Basic Weather and the clouds setup and know all the details. As for my methods of discussing, I think your next sentence sums it about up - I'm trying to get you to answer if 20 km is a safe radius, and you give me this? I guess that's it, we all have to bow to the great leader Let's investigate what I am actually arguing for: My quest for FG domination here is * to find out if we can load 20 km of terrain regardless if the visibility is lower * to defend the idea to _optionally_ model visibility based more on what's happening in a real atmosphere rather than keeping it a single user-controlled parameter * that you (or anyone else) is measured by the same standards I am measured with by you (or anyone else) Honestly, it doesn't sound like an ambitious agenda to me. In a broader context - yes, we offer many options to the user. Yes, it gets too confusing, so we need to un-clutter the GUI and streamline things. This doesn't necessarily imply we need to throw the new stuff away though. It means we need to sit down, talk, get proposals on the table and find an agreement how to reasonably change things - precisely what James has started to do. It's actually pretty much similar to the original purpose of this discussion - to get a picture how others would like to see problems handled before I start coding. I'l remove myself from this list, and any contributions that can be removed without affecting anyhting else from fgdata (don't want to leave unmaintained cruft around, and anyway it's being frownde upon because it uses thoe goddamn dirty .dds files, and who knows what else) Quoting myself: 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 (...) It is true that some people have reservations against dds files, but it's not true that I have issues with dds or that I would frown upon your work. All I am arguing, if you think it's correct that you can implement an optional feature which doesn't necessarily run on all systems, you should extend the same right to me and not criticize me for doing so. There is no contribution you can remove without affecting anyone else - you'll certainly affect every user who wants to fly the plane. I reserve this right under the copyright provision of the right to retract one's work, so please do not reinstate it. I am not an expert on GPL, but I think what you released under GPL belongs to the community in the sense that people can do whatever they see fit with it as long as they adhere to GPL and you cannot reserve any rights of forcing people not using it. I thus think it's not your right under any copyright provision but depends on the community agreeing to honour your wish. Where would any GPL'd project end up if everyone retracts his work over disagreements? If Stuart and I get angry, FG suddenly has no weather? A
Re: [Flightgear-devel] Low visibility issues
On 22 Feb 2013, at 07:06, Mathias Fröhlich mathias.froehl...@gmx.net 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Low visibility issues
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 mathias.froehl...@gmx.net 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 Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- 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 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
Re: [Flightgear-devel] Low visibility issues
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
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] Low visibility issues
Vivian wrote a while ago: I've only tested Atmospheric Light Scattering for about 10 mins - and so far I've discovered that the Cat III scenario looks decidedly odd with a clear circle around my aircraft on the ground and black skies. I've taken a few hours to look into low visibility scenarios, and it's... complicated. It's not complicated to make a low visibility scenario, but it's complicated to make one which blends smoothly into the rest. So I would like to put this up for discussion as a list of options and get some feedback, with hopefully a decent picture of what we should do for 3.0. Status: Atmospheric Light Scattering is in my tests good to a visibility of ~1000 m - below one starts running into a number of increasingly severe isses - Vivian has encountered a few of them, but there are more. One option is - we can leave things as they are, with no additional complication and framerate cost. That's not unprecedented, the default rendering scheme doesn't deliver good results at high altitude, so if you fly Concorde, SR-71 Blackbird, X-15 or Vostok-1 you don't get to see correct earth curvature or the atmosphere below. We accept that the scheme simply can't handle this and trust that users which want to see plausible visuals at high altitude switch rendering scheme. Similarly, we could accept that anyone who wants to deal with visibility much below 1000 m would have to switch rendering scheme (and even make the Cat II and Cat III shown only optional dependent on what rendering scheme is selected for instance). Failing that, here's a list of issues which need to be addressed, options to fix them and projected costs: 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. Options: a) If the skydome really unloads in Basic Weather, set the property correctly to prevent that. - no bad side effects 2) Clear circle around the plane: A while ago, I presented the problem that fog computations are done for the cockpit as well since they run over the same model shader as anything else, so we waste a lot of GPU time on something that is physically wrong (the cabin interior is not fogged) and results in a close-to-zero result in most cases. The advice I got was to use a distance cut to prevent these computations, so I used 40 m which is supposed to prevent the cabin interior in passenger planes from being affected. Of course, once the visibility gets just low enough, you see this distance cut as the circle Vivian describes. Options: a) We change this against a sliding distance cut not fogging for the closest 5% of the distance with some smoothing. This doesn't fix the issue but makes it a bit more subtle. - there may appear fogging computations on the cockpit, costing extra framerate, the cabin interior can still be fogged b) We fix it properly by using a different effect for all aircraft interior surfaces which never does fog computations (easy to do shader-side by passing a flag) - every aircraft needs to be modified and declare surfaces as interior or exterior for this to work 3) Terrain unloads: Currently the terrain manager unloads all terrain not in the visible range. This means that for 100 m visibility, hardly any terrain is loaded. This is bad in a number of ways: * 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 Options: a) From a performance point of view, it makes no sense to massively unload terrain when the visibility drops over a short time - re-loading is far too expensive than just keeping it. So one could simply change the terrain manager to never unload terrain if it's closer than 20 km - this would basically
Re: [Flightgear-devel] Low visibility issues
On 20 Feb 2013, at 08:44, Renk Thorsten thorsten.i.r...@jyu.fi wrote: 2) Clear circle around the plane: A while ago, I presented the problem that fog computations are done for the cockpit as well since they run over the same model shader as anything else, so we waste a lot of GPU time on something that is physically wrong (the cabin interior is not fogged) and results in a close-to-zero result in most cases. The advice I got was to use a distance cut to prevent these computations, so I used 40 m which is supposed to prevent the cabin interior in passenger planes from being affected. Of course, once the visibility gets just low enough, you see this distance cut as the circle Vivian describes. Options: a) We change this against a sliding distance cut not fogging for the closest 5% of the distance with some smoothing. This doesn't fix the issue but makes it a bit more subtle. - there may appear fogging computations on the cockpit, costing extra framerate, the cabin interior can still be fogged b) We fix it properly by using a different effect for all aircraft interior surfaces which never does fog computations (easy to do shader-side by passing a flag) - every aircraft needs to be modified and declare surfaces as interior or exterior for this to work I would push for b) because it would also enable some other good things in the future; much easier to auto-hide internal features in exterior views, more potential to do a an early pass with internal geometry to fill Z, etc. 3) Terrain unloads: Currently the terrain manager unloads all terrain not in the visible range. This means that for 100 m visibility, hardly any terrain is loaded. This is bad in a number of ways: * 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 Options: a) From a performance point of view, it makes no sense to massively unload terrain when the visibility drops over a short time - re-loading is far too expensive than just keeping it. So one could simply change the terrain manager to never unload terrain if it's closer than 20 km - this would basically fix all problems - someone needs to do it b) It would barely seem possible to adapt the terrain sampling routines to the visibility and to spend some extra performance to try to fix the color mismatches between skydome and real terrain - I don't know if it could be done, it's difficult to guess what altitude the terrain should have where it isn't - not a proper solution, just a bad fix 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. 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 20 Feb 2013, at 09:14, James Turner zakal...@mac.com wrote: I would push for b) because it would also enable some other good things in the future; much easier to auto-hide internal features in exterior views, more potential to do a an early pass with internal geometry to fill Z, etc. (Possibly including in-cockpit precipitation….) -- 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 wrote -Original Message- From: Renk Thorsten [mailto:thorsten.i.r...@jyu.fi] Sent: 20 February 2013 08:44 To: FlightGear developers discussions Subject: [Flightgear-devel] Low visibility issues Vivian wrote a while ago: I've only tested Atmospheric Light Scattering for about 10 mins - and so far I've discovered that the Cat III scenario looks decidedly odd with a clear circle around my aircraft on the ground and black skies. I've taken a few hours to look into low visibility scenarios, and it's... complicated. It's not complicated to make a low visibility scenario, but it's complicated to make one which blends smoothly into the rest. So I would like to put this up for discussion as a list of options and get some feedback, with hopefully a decent picture of what we should do for 3.0. Status: Atmospheric Light Scattering is in my tests good to a visibility of ~1000 m - below one starts running into a number of increasingly severe isses - Vivian has encountered a few of them, but there are more. One option is - we can leave things as they are, with no additional complication and framerate cost. That's not unprecedented, the default rendering scheme doesn't deliver good results at high altitude, so if you fly Concorde, SR-71 Blackbird, X-15 or Vostok-1 you don't get to see correct earth curvature or the atmosphere below. We accept that the scheme simply can't handle this and trust that users which want to see plausible visuals at high altitude switch rendering scheme. Similarly, we could accept that anyone who wants to deal with visibility much below 1000 m would have to switch rendering scheme (and even make the Cat II and Cat III shown only optional dependent on what rendering scheme is selected for instance). At the minimum we need to avoid FG just looking broken, so making the Cat II III dependent on rendering scheme would work. Better to fix it properly though Failing that, here's a list of issues which need to be addressed, options to fix them and projected costs: 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. Options: a) If the skydome really unloads in Basic Weather, set the property correctly to prevent that. - no bad side effects 2) Clear circle around the plane: A while ago, I presented the problem that fog computations are done for the cockpit as well since they run over the same model shader as anything else, so we waste a lot of GPU time on something that is physically wrong (the cabin interior is not fogged) and results in a close-to-zero result in most cases. The advice I got was to use a distance cut to prevent these computations, so I used 40 m which is supposed to prevent the cabin interior in passenger planes from being affected. Of course, once the visibility gets just low enough, you see this distance cut as the circle Vivian describes. Options: a) We change this against a sliding distance cut not fogging for the closest 5% of the distance with some smoothing. This doesn't fix the issue but makes it a bit more subtle. - there may appear fogging computations on the cockpit, costing extra - framerate, the cabin interior can still be fogged This would be acceptable - I think it's the hard demarcation which catches the eye and looks unrealistic. b) We fix it properly by using a different effect for all aircraft interior surfaces which never does fog computations (easy to do shader-side by passing a flag) - every aircraft needs to be modified and declare surfaces as interior - or exterior for this to work 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. 3) Terrain unloads: Currently the terrain manager unloads all terrain not in the visible range. This means that for 100 m visibility, hardly any terrain is loaded. This is bad in a number of ways: * 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
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. * 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
