On Saturday, February 23, 2013 07:08:41 Renk Thorsten wrote:
>A lot of stuff, mostly deflecting the discussion to other irelevant points
> 
> * Thorsten

While I should know better than to answer to this, as it will again get 
deflected to other areas, let's  imagine ourselves a simple scenario:

Let's say I'm an average user with a 32bit system, I can barely find my way 
through the maze of menus and dialogs flightgear presents to me, and I want to 
use this more advanced weather simulation engine. After I accidentaly find out 
how to enable it (it's hidden under a rather confusing radio-button selection 
"Model overall weather conditions based on metar"), great, select "Fair 
weather" scneario,  Apply, OK, let's go flying.
I muck around, wonder at the nice sky/clouds, notice that my visibility 
improved somewhat, then bam after 15 minutes flightgear crashes, uhm.. oohh, 
why did that happen? That didn't happen before?
All I did was change the way the weather is interpreted... What's wrong 
here???

Well, now let's see what actually happens in a default flightgear instalation
(all settings are from preferences.xml, and Environment/local-weather-
defaults.xml)
->trees are enabled by default
->default visibility with "Fair weather" is ~16km
->local weather comes in and sets a default value for max visibility of 120km 
(o.O), ok, that's a bit far, but in practice I see that's actually hovering in 
the 40km range (+-10km based on altitude). (roughly 3x more than the default)

So in the default scheme we load 9 tiles at startup, then we keep loading 
tiles in the direction we're traveling, and those initial tiles remain 
resident in the tile cache for a while (in case you decide to double back). 
But let's stay with the startup condition. when you ramp up the visibility to 
40km you demand 3 extra "rings" of tiles to be loaded. That would give you at 
least 69 tiles loaded (81 if the "rings" are square). So that's an instant 
increase of 7-9x the memory requirements of the terrain + objects + trees 
(tres being the largest contributor here), just because you click an option 
that says it just _interprets_ the METAR string differently. Do you think 
that's an expected result? I don't.

Well, our average user might have read the manual, might have mucked about 
with the visibility setting before, and he remeber that all things being the 
same, visibility is what impacts performance/memory the most, so he decides to 
try again, this time trying to use z/Z to limit how far the visibility goes, 
maybe he gets lucky and it won't crash again, but he's in for a surprise... 
z/Z doesn't work...

You might argue that he should know better, go into the advanced settings 
dialog, figure out what all those sliders and selection boxes do, etc, etc... 
But remeber, our user is an average one, he wants things to just work (with 
time, he might find a use for the more advanced configuration stuff, but for 
now 
he's not interested, he just want to click something, and be done with it), 
The z/Z case above might be a lucky one where he might have read the manual.

The problem is not with "Advanced weather" in itself, the problem is in the 
details of a part of it, themost important part from the user POV. Your 
approach might work, given unlimited resources, but as it is Flightgear has to 
run on a variety of puny little desktop/laptop machines. You have already 
implemented half of the control, is it so hard to implement the rest and 
provide a system that's consistent with the rest? 
Yes it breaks the "real world" scheme, but this is a simulation, we lie, 
carefully crafted lies, that give a global impression of truth, of copying the 
real world behaviour, but in the end they are lies. Fog/view-distance is one 
of those lies, they need just be plausible, not a faithful representation of 
the real world (and a faithful representation of the real-world is practically 
impossible given the current state of the technology).

You are comfortable with abdicating from that when it suits you, but where it 
really matters you defend the "minute detail faithfull representation of the 
real world scheme" vigorously... Don't you think thre's something amiss here?

As someone said in another thread, there are various techniques that are not 
constrained by the "real-time" requirement, that do a pretty good job of 
giving you "real" results, but their place is not here. Here we have to do our 
best to trick the mind, while doing that as fast as possible, with a 
reasonable usage of resources. Just because you can set visibility to 1000km 
doesn't mean you should, just because you can shove a lot of data into a 
shading scheme and get back "photoreal" results doesn't mean you should, if 
said results reduce performance, increase the probability of running out of 
memory, etc.

You'll argue again with the IAR as an example. Well, take a look at those 
numbers again, and you'll see that for the amount of detail it presents to the 
user it uses ~0.66 of the memory used by the bare terrain. I don't think 
that's unreasonable, others might think differently. (I could have very well 
modelled every rivet, nut and bolt on it, I didn't, why? because there are 
pretty good techniques of faking that, with plausible results. If you look 
really hard you notice that the detail is all fake, that the reflection has 
nothing to do with the actual environment etc... but that's irrelevant for the 
normal use case) 

You look at view-distance/fog just as an atmospheric phenomenon, that you 
think should be represented verbatim, well it's not. It's not just that in any 
case, and if for it to fulfil all its roles you need to abdicate from the 
verbatim aproach, well then I'm sorry but my opinion is that you should.
I never claimed that it's the only resource management device, I only claimed 
that it's role is  much more than just visual cue to the environment, and that 
role should not be underestimated, or thrown aside...

Regards,
Emilian









------------------------------------------------------------------------------
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

Reply via email to