Re: [Flightgear-devel] Discussion culture clashes
On Saturday 23 February 2013 07:33:54 Renk Thorsten wrote: - I agree with Vivian, we can't do realistic distances for radar because of memory issues Lorenzo: 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 ? - Assumes that we want to set the limits by equipment (radar) rather than visuals, although we've just said we don't want to do this because of memory issues, and I've listed several points besides radar why I'd like to do it. Actually, I think what he tried to suggest was, that the needs of visuals and the needs equipment like radar should not be mixed. For visuals we need the terrain and all the objects like trees and buildings which are hard on performance. For radar we would only need a probably simplified form of terrain and can easily do without all those objects. So even 200km of radar range could be implemented without hitting too hard on memory. Essentially he was asking for some kind of LOD, be it automatic or manually by having separate data sources. The language barrier makes it somewhat hard to be sure, but that's how I interpreted his original message. 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] Discussion culture clashes
Actually, I think what he tried to suggest was, that the needs of visuals and the needs equipment like radar should not be mixed. For visuals we need the terrain and all the objects like trees and buildings which are hard on performance. It's a fact that the distances out to which we draw trees and buildings are considerably less than how far we potentially draw terrain (120 km max.) So these things are separated even now - we don't attempt to render random buildings in 80 km distance even if we render terrain. Nobody proposed to render buildings to the visibility range either. Also let me quote what James said immediately before: 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). So this doesn't lead to any more gracious interpretation. * 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] Discussion culture clashes
On Sat, 23 Feb 2013 07:13:21 +, Renk wrote in message e495a106ff5f31448739e79d34138c192789b...@mbs2.ad.jyu.fi: ..see? Here you go again, snipping away too agressively, so the pointer to my forgotten point, is lost. Fix that. ;o) ..a point I forgot to make: you (or your MUA?) don't attribute properly what I wrote below, which may be part of the thread breaking problem. Arnt, you do know that 'you' in the English language doesn't necessarily refer to you personally, but that it doubles as an unspecified 'one'? ..true, and if I meant more than you Renk, I would have said (or your MUAs?). :o) On the other hand though, it _may_ be a combination of several peoples MUA configurations, or even a bug in my MUA that has been triggered by this thread. Either way, I still need that pointer to your original message if you want me understanding your point of view, so I asked because I saw more people might have the same need and because we are in the same time zone. If I say 'If you don't understand, then do X' I mean 'Anyone who doesn't understand should do X'. So the remarks are pretty much addressed to anyone, including myself, certainly not to you personally. It occurred to me later that this feature of English might lead to trouble with some non-native speakers - sorry for any confusion. * Thorsten .. :o) -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- 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] Adds on FlightGear.org
Hi all, I won't ask for the adds to be removed (apparently that is not possible), but I do want to bring the result of that decision under your attention. Is this really what we want? http://www.flightsim.com/vbfs/content.php?13546-FlightGear-v2-10-Is-Released#comments http://www.flightsim.com/vbfs/showthread.php?260718-FlightGear-2-10-is-now-available-!p=1747315#post1747315 Cheers, Gijs -- 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] Discussion culture clashes
On Saturday, February 23, 2013 09:36:23 Renk Thorsten wrote: It's a fact that the distances out to which we draw trees and buildings are considerably less than how far we potentially draw terrain (120 km max.) So these things are separated even now - we don't attempt to render random buildings in 80 km distance even if we render terrain. Nobody proposed to render buildings to the visibility range either. Buildings/trees are generated at tile load time currently, and remain resident in memory, for as long as the tile is loaded. If you don't se them on screen doens't mean they're not there. 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] Adds on FlightGear.org
On 02/23/2013 11:13 AM, Gijs de Rooy wrote: Hi all, I won't ask for the adds to be removed (apparently that is not possible), but I do want to bring the result of that decision under your attention. Is this really what we want? One quick option would be to move the navigation bar below the FligthGear banner (and just above the add and image gallery). But I agree, it looks a bit messy now. Erik -- http://www.adalin.com - Hardware accelerated AeonWave and OpenAL for Windows and Linux -- 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] Adds on FlightGear.org
Hi Gijs, et al., Slowly coming back to FlightGear land, now that my deadline is met. :-) Yes, I think that this is undesirable. Having adds inside the content area of a website is usually considered to be poor design, from a usability perspective. I don't mind if we have some adds on the top, or on the right side of the page. The current layout is confusing. Cheers, Durk On 23 Feb 2013, at 11:13, Gijs de Rooy wrote: Hi all, I won't ask for the adds to be removed (apparently that is not possible), but I do want to bring the result of that decision under your attention. Is this really what we want? http://www.flightsim.com/vbfs/content.php?13546-FlightGear-v2-10-Is-Released#comments http://www.flightsim.com/vbfs/showthread.php?260718-FlightGear-2-10-is-now-available-!p=1747315#post1747315 Cheers, Gijs -- 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 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] Adds on FlightGear.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/23/2013 11:26 AM, Durk Talsma wrote: Hi Gijs, et al., Slowly coming back to FlightGear land, now that my deadline is met. :-) Yes, I think that this is undesirable. Having adds inside the content area of a website is usually considered to be poor design, from a usability perspective. I don't mind if we have some adds on the top, or on the right side of the page. The current layout is confusing. Cheers, Durk On 23 Feb 2013, at 11:13, Gijs de Rooy wrote: Hi all, I won't ask for the adds to be removed (apparently that is not possible), but I do want to bring the result of that decision under your attention. Is this really what we want? http://www.flightsim.com/vbfs/content.php?13546-FlightGear-v2-10-Is-Released#comments http://www.flightsim.com/vbfs/showthread.php?260718-FlightGear-2-10-is-now-available-!p=1747315#post1747315 Cheers, Gijs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEorbcACgkQty+BhcbHvXgI5ACeNSEUN6W457APhy3+OlQNOqC3 94IAoNMUEjzmTZ32HX23SlRoxVN0G7Ag =Nyuf -END PGP SIGNATURE- -- 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] Adds on FlightGear.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sorry for empty message. Here it is. :) Here is now an alternative tracker (I also track my FGFS-related torrents to the original + in addition to my tracker) for all BitTorrent download: http://flightgear.mxchange.org:23456/ Just click on the links you want to download. As someone complained about low download speeds from HTTP/FTP (?) servers, I currently download the setup.exe file with my Internet connection here and have ~600-900 kByte/sec. download speed, quite acceptable. :) I have tested the Windows installer (InfoHash: 3cdd600202344f578809a7c3c9b9e0a0bf7bf1ed), it only install OpenAL and was ads-free. So they might have downloaded it somewhere else where that hoster has added some ads and free offers to the installer. :( This however can be beaten by adding signatures as I have heard. Regards, Roland -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEosLUACgkQty+BhcbHvXgevwCfSS0gkwqMBcwk0RGHgBb5D1EK g+AAoMnGuendhvZqLn8l3uzc7XAuAZHS =olLx -END PGP SIGNATURE- -- 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] Discussion culture clashes
Buildings/trees are generated at tile load time currently, and remain resident in memory, for as long as the tile is loaded. If you don't se them on screen doens't mean they're not there. Yes, but strangely enough, this part of the discussion happened to be about LOD systems and performance rather than memory usage. And as far as the GPU performance footprint of trees or buildings seems to be concerned, if you don't see them on the screen, they don't take GPU performance. Please don't take bits of what I say out of their context. * 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] Adds on FlightGear.org
Hi Gijs, De : Gijs de Rooy gijsr...@hotmail.com Envoyé le : Samedi 23 février 2013 11h13 I won't ask for the adds to be removed (apparently that is not possible), but I do want to bring the result of that decision under your attention. Is this really what we want? Using Adblock for years, I enjoy browsing the web ad-free. But sure the confusion is really bad. I understand that Google ads enables us to pay for the domain name, right+hosting, right? Olivier -- 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] Adds on FlightGear.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/23/2013 03:50 PM, Olivier wrote: Hi Gijs, *De :* Gijs de Rooy gijsr...@hotmail.com *Envoyé le :* Samedi 23 février 2013 11h13 ** I won't ask for the adds to be removed (apparently that is not possible), but I do want to bring the result of that decision under your attention. Is this really what we want? Using Adblock for years, I enjoy browsing the web ad-free. But sure the confusion is really bad. I understand that Google ads enables us to pay for the domain name, right+hosting, right? Olivier Hello Oliver and Gijs, I can pay my server (root access, not shared with others) from my small money I get here + domains. That is always payable. :) So my non-profit software pages are all free of ads. Please don't get confused with some banners I have placed there, they don't give me money for linking them. Roland -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEo3HYACgkQty+BhcbHvXiRvwCcCl/GoRalDnTS5+g1hcPQodtw 2IgAnRWw/5mQe66nVVLWn9ukqFGL3W3O =Zhlm -END PGP SIGNATURE- -- 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
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] Discussion culture clashes
While I think that sometimes Thorsten may give people more benefit of the doubt... After sleeping over it, I have to admit that Stefan is right. I was angry about the way the discussion was turning away from being productive, and that colored my response to Lorenzo, which is not how things should be. Lorenzo, will you please accept my apology for that? * 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
