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
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] 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] 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
Re: [Flightgear-devel] Discussion culture clashes
On Fri, 22 Feb 2013 07:10:30 +, Renk wrote in message e495a106ff5f31448739e79d34138c192789b...@mbs2.ad.jyu.fi: ..a pointer to your previous message would help here, this thread is broken (in at least my MUA) and getting hard to follow. Maybe we just have some cultural misunderstandings? ..no, in this case we _also_ have a broken thread at in least my MUA (claws-mail 3.8.1) which helps aggravate cultural _etc_ misunderstandings, which again stalls meaningful discussion of the new things you guys wanna do here. Etc. The way I see it - if you want to make a statement in a discussion, you have to read what has been said before. No matter how hard it is to follow. No matter how long. ..agreed, that includes even the missing bits that I asked for. Everything else is impolite - you're in essence sending the message I don't really care what you've been saying already, but I think my opinion is so important so that I neither need to react to what you've been saying previously nor to care not to repeat what's already been solved - but I expect you to react to what I have to say. You don't want to follow the discussion because it's so complicated, that's fine, but then don't speak up. ..you assume here that I have the complete picture but that I'm to lazy to read it all. The way this thread is broken, makes me doubt I have the complete thread or picture, and chances are I'm not alone, so I speak up. The categorical imperative will tell you that it doesn't work if some people want special treatment. In the event Lorenzo argues for instance against loading terrain far out for radar purposes. Nobody has proposed to do that, so it's a strawman argument in the first place. Vivian has mentioned the dangers of the approach, I have agreed with him, so what is the possible point of arguing against something no one wants to do? Replying to that only keeps the discussion in one more unproductive cycle and doesn't make anything clearer. He argues for using visibility as a device to adjust framerate, ignoring all arguments brought against seeing visibility as a mere tool to adjust framerate, and despite James sketching a LOD bias system as a well-defined alternative way to get framerate adjusted using LOD ranges. So he doesn't bother to read what Vivian, James and I have been saying - why should it then be my job to give him pointers? The way I see it, if you want to criticize something, you first make sure you understand the problem so that you can deliver a meaningful critique, and ideally you can even suggest a better alternative. If you speak without understanding the problem, you're choosing a very unfriendly way to ask others to take their time and explain it to you when understanding it should have been your job in the first place. ..you assume here that I have the complete picture but that I'm to lazy to read it all. The way this thread is broken, makes me doubt I have the complete thread or picture, and chances are I'm not alone, so I speak up. If you don't understand, you ask politely for an explanation, only if you understand and disagree, you can criticize. The way I see it, if you have criticized without understanding, you owe an apology. ..perfectly happy to do that, if it helps fix a broken down thread or discussion. The appropriate time to criticize without understanding, comes when it's getting clear that some critical bits are missing, so those bits can be put in their proper place to help the understanding. ..keep in mind, everyone here is criticizing you and everyone else here because they _think_ they may know a better to do what they _think_ you are proposing, without neccessarily understanding properly how you are thinking, or even what you are thinking. :o) The way I see it, arguments should be based on what's correct, not what's familiar. I'm repeatedly observing that familiar flaws are seen as completely acceptable, ..aye, take e.g. the ATI viewport fix for the proprietary driver which I get shoved down my throat using the X.org radeon driver, I could have tested it if anyone had bothered to tell me how to disable it. but any flaw in new features is jumped on eagerly. ..these are super easy to spot, exactly because they are new and stand out. The old crud is hidden because it is not properly understood, and not neccessarily seen too. ..if you go back a few years, you'll find me talking about black planes on ATI cards with the X.org radeon driver, that no-one else here saw, because they were all running nvidea drivers on nVidea hardware. ..in a non-radeon world, this approach _works_ for all the nvidea people, and they can then take their time to try figure out how to fix this properly once we the ATI viewport fix tested on the X.org radeon etc free drivers too. I'm even observing that any change is held to the standard of what was previously installed and is perceived wrong if different. In the forum, there was
Re: [Flightgear-devel] Discussion culture clashes
On Fri, 22 Feb 2013 17:26:34 +0100, Arnt wrote in message 20130222172634.0b083...@celsius.lan: On Fri, 22 Feb 2013 07:10:30 +, Renk wrote in message e495a106ff5f31448739e79d34138c192789b...@mbs2.ad.jyu.fi: ..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. ..a pointer to your previous message would help here, this thread is broken (in at least my MUA) and getting hard to follow. Maybe we just have some cultural misunderstandings? ..no, in this case we _also_ have a broken thread at in least my MUA (claws-mail 3.8.1) which helps aggravate cultural _etc_ misunderstandings, which again stalls meaningful discussion of the new things you guys wanna do here. Etc. The way I see it - if you want to make a statement in a discussion, you have to read what has been said before. No matter how hard it is to follow. No matter how long. ..agreed, that includes even the missing bits that I asked for. Everything else is impolite - you're in essence sending the message I don't really care what you've been saying already, but I think my opinion is so important so that I neither need to react to what you've been saying previously nor to care not to repeat what's already been solved - but I expect you to react to what I have to say. You don't want to follow the discussion because it's so complicated, that's fine, but then don't speak up. ..you assume here that I have the complete picture but that I'm to lazy to read it all. The way this thread is broken, makes me doubt I have the complete thread or picture, and chances are I'm not alone, so I speak up. The categorical imperative will tell you that it doesn't work if some people want special treatment. In the event Lorenzo argues for instance against loading terrain far out for radar purposes. Nobody has proposed to do that, so it's a strawman argument in the first place. Vivian has mentioned the dangers of the approach, I have agreed with him, so what is the possible point of arguing against something no one wants to do? Replying to that only keeps the discussion in one more unproductive cycle and doesn't make anything clearer. He argues for using visibility as a device to adjust framerate, ignoring all arguments brought against seeing visibility as a mere tool to adjust framerate, and despite James sketching a LOD bias system as a well-defined alternative way to get framerate adjusted using LOD ranges. So he doesn't bother to read what Vivian, James and I have been saying - why should it then be my job to give him pointers? The way I see it, if you want to criticize something, you first make sure you understand the problem so that you can deliver a meaningful critique, and ideally you can even suggest a better alternative. If you speak without understanding the problem, you're choosing a very unfriendly way to ask others to take their time and explain it to you when understanding it should have been your job in the first place. ..you assume here that I have the complete picture but that I'm to lazy to read it all. The way this thread is broken, makes me doubt I have the complete thread or picture, and chances are I'm not alone, so I speak up. If you don't understand, you ask politely for an explanation, only if you understand and disagree, you can criticize. The way I see it, if you have criticized without understanding, you owe an apology. ..perfectly happy to do that, if it helps fix a broken down thread or discussion. The appropriate time to criticize without understanding, comes when it's getting clear that some critical bits are missing, so those bits can be put in their proper place to help the understanding. ..keep in mind, everyone here is criticizing you and everyone else here because they _think_ they may know a better to do what they _think_ you are proposing, without neccessarily understanding properly how you are thinking, or even what you are thinking. :o) The way I see it, arguments should be based on what's correct, not what's familiar. I'm repeatedly observing that familiar flaws are seen as completely acceptable, ..aye, take e.g. the ATI viewport fix for the proprietary driver which I get shoved down my throat using the X.org radeon driver, I could have tested it if anyone had bothered to tell me how to disable it. but any flaw in new features is jumped on eagerly. ..these are super easy to spot, exactly because they are new and stand out. The old crud is hidden because it is not properly understood, and not neccessarily seen too. ..if you go back a few years, you'll find me talking about black planes on ATI cards with the X.org radeon driver, that no-one else here saw, because they were all running nvidea drivers on nVidea hardware. ..in a non-radeon world, this approach _works_
Re: [Flightgear-devel] Discussion culture clashes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/22/2013 07:10 AM, Renk Thorsten wrote: ..a pointer to your previous message would help here, this thread is broken (in at least my MUA) and getting hard to follow. Maybe we just have some cultural misunderstandings? The way I see it - if you want to make a statement in a discussion, you have to read what has been said before. No matter how hard it is to follow. No matter how long. Everything else is impolite - you're in essence sending the message I don't really care what you've been saying already, but I think my opinion is so important so that I neither need to react to what you've been saying previously nor to care not to repeat what's already been solved - but I expect you to react to what I have to say. You don't want to follow the discussion because it's so complicated, that's fine, but then don't speak up. The categorical imperative will tell you that it doesn't work if some people want special treatment. In the event Lorenzo argues for instance against loading terrain far out for radar purposes. Nobody has proposed to do that, so it's a strawman argument in the first place. Vivian has mentioned the dangers of the approach, I have agreed with him, so what is the possible point of arguing against something no one wants to do? Replying to that only keeps the discussion in one more unproductive cycle and doesn't make anything clearer. He argues for using visibility as a device to adjust framerate, ignoring all arguments brought against seeing visibility as a mere tool to adjust framerate, and despite James sketching a LOD bias system as a well-defined alternative way to get framerate adjusted using LOD ranges. So he doesn't bother to read what Vivian, James and I have been saying - why should it then be my job to give him pointers? Straw man ?!?!? http://en.wikipedia.org/wiki/Straw_man [See :: structure point 2.5] and you will understand that simplifying my point of view trying to invalidate it is ... a straw man technique. Are you so sure that it is not what you have done concluding rushy that I do not had read the previous posts and spoofing the rest ??? If my post was unclear you had could ask for make more clear. At second read I believe it was unclear but It was a neutral question and not an attack to anything ! Let me tell you that for one that come from outside, yes I am new in FG devel, but not in FG (years) nor in programming (decades), it is really difficult to made up a relatively sufficient big picture !!! I spent months to read ALL what I could catch, docs, wiki, sources, read quietly all what was going on forums, mailing lists in order to *feel* the air the team breathe, and the result ??? a big black cloud and low visibility. okay? Do not try to argument the contrary. And it is a shame for the spirit of the open source ! Where is the sharing spirit when what we see in LOT of posts is energy to destroy the opponent view/argument ... Is some want to see his argument shinning there far up, he NEED to develop it and raise it and NOT to bomb and the colleagues arguments and positions! I started one project (actually two) for FG and I am scarred to see that this place where we should see creative spirit is an arena the resolve personal frustrations. By the way, Mr Thorsten, it was my first post in this mailing list, I have appreciated a lot the welcome touch. What was you trying, ... make me feel like a dog in a bowling game ? Straw man... Keep knowing that I speak for my self with ideas from my head and justified with emotions ! If you don't want to be impolite, well, just don't. The way I see it, if you want to criticize something, you first make sure you understand the problem so that you can deliver a meaningful critique, and ideally you can even suggest a better alternative. If you speak without understanding the problem, you're choosing a very unfriendly way to ask others to take their time and explain it to you when understanding it should have been your job in the first place. If you don't understand, you ask politely for an explanation, only if you understand and disagree, you can criticize. The way I see it, if you have criticized without understanding, you owe an apology. The way I see it, arguments should be based on what's correct, not what's familiar. I'm repeatedly observing that familiar flaws are seen as completely acceptable, but any flaw in new features is jumped on eagerly. I'm even observing that any change is held to the standard of what was previously installed and is perceived wrong if different. In the forum, there was an argument that 012345Z 23010KT 5000 SHRA SCT012 BKN018 OVC060 15/11 Q1010 is wrongly interpreted because it comes out much darker than in 2.0.0 - illustrated with screenshots showing 3/8 cloud cover. The familiar trumps the correct, even given that 3/8 cloud cover is definitely not what the METAR says - it doesn't matter that we now have the correct cloud cover
Re: [Flightgear-devel] Discussion culture clashes
..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'? 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 -- 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
Straw man ?!?!? http://en.wikipedia.org/wiki/Straw_man [See :: structure point 2.5] and you will understand that simplifying my point of view trying to invalidate it is ... a straw man technique. Are you so sure that it is not what you have done concluding rushy that I do not had read the previous posts and spoofing the rest ??? Wikipedia: A straw man or straw person, (...) is a type of argument and is an informal fallacy based on misrepresentation of an opponent's position. I say: (...) * terrain radar code (which'd be especially useful in low visibility conditions) breaks as it can't probe terrain elevations ahead (...) 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 - Can we do 20 km? It would hep for may things, including radar. Vivian says: 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. As an aside, with custom detailed scenery, memory is already marginal for 32 bit systems, reading comments of the forum. - For real radar, we'd need much more and we can't do this for memory reasons. I say: 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. (...) 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 - 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. Yep - that's a straw man - it's based on misrepresenting my and Vivian's position. By the way, Mr Thorsten, it was my first post in this mailing list, I have appreciated a lot the welcome touch. What was you trying, ... make me feel like a dog in a bowling game ? Well, seems you have quite the way to introduce yourself. This might have to do something with my reaction. ;-) Is some want to see his argument shinning there far up, he NEED to develop it and raise it and NOT to bomb and the colleagues arguments and positions! With all due respect, I think you should read what people have said and you need to try to understand what the ongoing argument is about before entering a discussion. I don't think it's particularly polite what you have done, and you should not be surprised at the reaction. Best, * 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
- 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. On re-reading, this sounds pretty hilarious... What I mean is: We have just said we don't want to do 100 km (as would be indicated by a realistic radar), and I've given several reasons besides radar to do 20 km. * 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
[Flightgear-devel] Discussion culture clashes
..a pointer to your previous message would help here, this thread is broken (in at least my MUA) and getting hard to follow. Maybe we just have some cultural misunderstandings? The way I see it - if you want to make a statement in a discussion, you have to read what has been said before. No matter how hard it is to follow. No matter how long. Everything else is impolite - you're in essence sending the message I don't really care what you've been saying already, but I think my opinion is so important so that I neither need to react to what you've been saying previously nor to care not to repeat what's already been solved - but I expect you to react to what I have to say. You don't want to follow the discussion because it's so complicated, that's fine, but then don't speak up. The categorical imperative will tell you that it doesn't work if some people want special treatment. In the event Lorenzo argues for instance against loading terrain far out for radar purposes. Nobody has proposed to do that, so it's a strawman argument in the first place. Vivian has mentioned the dangers of the approach, I have agreed with him, so what is the possible point of arguing against something no one wants to do? Replying to that only keeps the discussion in one more unproductive cycle and doesn't make anything clearer. He argues for using visibility as a device to adjust framerate, ignoring all arguments brought against seeing visibility as a mere tool to adjust framerate, and despite James sketching a LOD bias system as a well-defined alternative way to get framerate adjusted using LOD ranges. So he doesn't bother to read what Vivian, James and I have been saying - why should it then be my job to give him pointers? The way I see it, if you want to criticize something, you first make sure you understand the problem so that you can deliver a meaningful critique, and ideally you can even suggest a better alternative. If you speak without understanding the problem, you're choosing a very unfriendly way to ask others to take their time and explain it to you when understanding it should have been your job in the first place. If you don't understand, you ask politely for an explanation, only if you understand and disagree, you can criticize. The way I see it, if you have criticized without understanding, you owe an apology. The way I see it, arguments should be based on what's correct, not what's familiar. I'm repeatedly observing that familiar flaws are seen as completely acceptable, but any flaw in new features is jumped on eagerly. I'm even observing that any change is held to the standard of what was previously installed and is perceived wrong if different. In the forum, there was an argument that 012345Z 23010KT 5000 SHRA SCT012 BKN018 OVC060 15/11 Q1010 is wrongly interpreted because it comes out much darker than in 2.0.0 - illustrated with screenshots showing 3/8 cloud cover. The familiar trumps the correct, even given that 3/8 cloud cover is definitely not what the METAR says - it doesn't matter that we now have the correct cloud cover specified by the weather, it matters that it's no longer what is familiar, and this isn't the way to make an argument. Having z/Z control visibility because one is used to it is no argument for or against it. The way I see it, arguments should be backed up with evidence. The memory consumption of loading 20 km (50 km, 100 km) of terrain is a number in a certain range - we don't need to toss concerns back and forth if we go ahead and measure the number, and we should base decisions on evidence rather than belief if we can get the evidence. I don't think these are grossly unreasonable foundations for meaningful, productive discussions. I'm not in a position to make anyone else adopt such standards as the goal for having a discussions, but could we perhaps give it a thought? * Thorsten -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
