On Thursday, February 21, 2013 12:33:17 Renk Thorsten wrote: > > I was talking about the 16km value (sorry for not being more clear about > > that) and see below for the huge value. > > Let me get this straight. You state that the 16 km are a pretty sane value. > The proposal being discussed is to load terrain to 20 km no matter what the > visibility is. Vivian has concerns about memory on 32bit systems. I have > test data showing that I can do 250 km visibility on a 32bit system and 50 > km with trees and buildings and custom scenery. > > So as far as the topic of the discussion is concerned (which up to this > point had nothing to do with what visibility Advanced Weather may or may > not set) - can we agree that 20 km (or 16 km) of terrain loaded no matter > the visibility is a sane value even for a 32 bit system? Or do you have > different test data?
See below... > > This > > > There's no warning/statement about what that selection implies, nowhere. > > The average user doesn't know what that will do to his system, or how it > > will change behaviour of other parts, that seem unrelated, nor has he > > control over a simple thing that might improve his experience, while > > enjoying both high detail scenery+objects and advanced weather. > > has nothing to do with the question discussed (which is how much terrain we > load when the visibility is small). It is a quite different issue which you > bring here for no discernable reason whatsoever (the thread title is 'low > visibility issues' and you're suddenly switching to high values...). > > Your statement as made above is pure hypocrisy. > > 1) There is zero warning given what increasing the visibility with z might > imply (I just tried that to be sure). If you're concerned about the > correlation between memory usage and visibility, you should not care how > the large visibility is obtained, you should warn whenever this happens. Have you ever read the getstart.pdf? apparently not. In current version at page 61 getstart.pdf wrote: > – Rendering Options configures various graphical features. This allows > you to trade eye-candy such as shadows, 3D clouds and specular reflec- > tions for frame-rate. To help you achieve a good balance, enable the > “Show Frame Rate” option in the Display Options menu, which will > show the current frame-rate in frames-per-second in the bottom right > of the screen. Most people find a frame-rate of around 20fps adequate > for flying. The frame-rate is affected by the graphical features you > have enabled, the current visibility (set by Z/z), the number of objects > in view and their level of detail (LOD). ------------------------------------------------------------------------------------------------- > 2) Last time I checked, there was no warning given that the IAR-80 uses a > large chunk of memory. If you are genuinely concerned about users filling > up their memory, why don't you start here? Don't we like to compare apples and oranges... Hmm, let's see, your statement would be valid if: a) The IAR 80 would be part of the core distribution. It isn't. b) If parts of it would be a hidden requirement for the corect operation of other aircraft, under the apparence of optional usage (it isn't), while advanced weather is required to be on to get full advantage of the atmospheric scattering scheme, a thing that isn't specified anywhere (except in some obscure forum post, or wiki page, for which you need to search really hard and only when you know what you're looking for) c) it would completely override the operation of other core components just because it can, and would do seemingly unexpected things for the unaware user (it doesn't). As for the memory usage of the IAR80, you might be surprised if you botherd to check. BTW, weren't you the one "crying" on quite a few forum threads, some time ago, that aircraft need better 3d models/cockpits, the one who started rating them based on how they look... hmm... I suppose it was just an attempt at a personal attack, but, unlike you, I don't consider [more or less informed or documented] critique to my work as a personal affront. > > 3) In order for Advanced Weather to reach the really large visibilities, you > actually need to check a box labelled 'Realistic Visibility' This may also > provide a hint that we're not doing rendering for a 3d shooter where fog is > a device to hide the edge of the scene, but that visibility is an essential > and very relevant property for the environment we're trying to simulate - > it makes the difference between IFR, hard VFR and easy VFR. Even leaving > this argument aside, I would argue that a user who has a) set LOD bare to a > high value and b) checked this box can be assumed to have the intention to > render a high visibility. > > 4) I actually brought up the very same issue on this list - the correlation > between memory, choosing highly detailed options and getting a large > visibility delivered. There was a discussion and a decision was made to > attach the warning to the random buildings options, not to Advanced Weather > and to try to decrease memory usage of buildings. Strangely enough, things > didn't bother you then. I wonder what's the use of me bringing up points > for discussion if havign discussed it doesn't mean that it's settled. > > Sorry, but for me, forcing your usage-pattern on the user just because > > you think you know better what he wants is bad_design by definition. > > Advanced Weather specifies the visibility as a 4-dimensional field > vis(x,y,z,t), i.e. it changes laterally, vertically and in time. In > addition, Advanced Weather knows the correlation of weather phenomena and > visibility - it knows that rain implies low visibility, it knows that > visibility deteriorates when entering a cloudbase, it knows that visibility > stays poor in a warm sector pretty high up and similar things. Basic > Weather does not know these things, it's purely descriptive and has no > concept what the weather is. > > You can either micromanage visibility as Basic Weather does and give up on > all these details, or you can hand control to the simulation. There is no > GUI you could fill in less than 30 minutes which gives you a visibility > model as detailed as what Advanced Weather runs. If you see visibility as > 'just a device to hide the edge of the scene' rather than an important > property of the environment we're simulating, my advice is simply not to > use Advanced Weather. > > What you're asking for is equivalent to 'Can't I just _set_ the airplane > velocity to any value I like without the FDM computing it? I want more > direct control.' Doesn't make any sense, sorry, if you don't like using > FDMs, use the ufo. Trying to dumb down an FDM because you want direct > control over the airspeed is not the way to go, and trying to dumb down the > environment simulation because you want to micro-manage visibility is not > the way to do, sorry. It doesn't change the fact that it takes some well documented control out of the user hands, without warning him. It also doesn't change the fact that visbility/fog has (had and will have, in a sane setup) a dual purpose, that of being a _simulation_ (read approximation) of an atmospehric phenomenon thus providing visual hints, and of a resource management device, -in any simulated environment, be it a 3d shooter, a racing simulator, a flight simulator, a space flight simulator, a real time strategy game... As for the buildings warning, that was added because it caused/causes issues even in the default setup in certain areas. The bigger visibility issues on 32bit system occur even with builings off, but with trees on, once you start moving around (40km with trees on is a nono after you move around for a while, which leads me to believe that your 50 km test was a static test, or one limited to moving around just a short distance from the start position). > > Please note that this will be my only response to this topic, because a) it > has already been discussed and b) it's not related to the discussion of the > thread. > > * Thorsten If it has been discussed, but there are still issues, I don't think that hiding one's head in the sand, and ignoring them, is the right way to go, just because, as mentioned earlier, someone might feel offended if some part of his work is brought into question. (BTW: The forums are still there if you feel the need for a choir of "oooh ", "aaahhh" and "woooow"s at your carefuly crafted screenshots, which, I have no problem to admit, look stuning) As for the relation to this thread, the memory issues have been brought up, and I've expressed my concerns to how some related implementation might affect those, if that's wrong, feel free to ignore me. (and it's not me the one who split this thread off from the previous related discussion(s) ) Regards, Emilian ------------------------------------------------------------------------------ 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
