Autogen visibility distance

[Guest cwright]

I recently posted about the well-known autogen problem on the general forum ('Observations on the autogen problem'). After making some measurements I came to the conclusion that the visibility distance settings for some classes of objects was the cause of the problem (JonP01 had previously come to a similar conclusion). The problem is this: after flying over an urban area with dense autogen for a few minutes it becomes apparent that, when looking back, the frame rates have fallen by a large amount (I have seen it fall by a massive 80%). This becomes even more serious if you turn 180 degrees, for the problem then lies directly ahead. The problem can temporarily be cleared by refreshing the autogen (simply change the autogen density setting and then change it back to the initial setting). Sadly the new FS2004 scenery refresh function is completely useless for this problem as it does not refresh the autogen. I made a test area consisting of a flat plain with a single city land class. My measurements of memory and frame rates clearly showed the problem, but at the same time strongly suggested that the autogen was working correctly. The problem lay with the actual visibility distances. One thing unexplained was this: why does the problem only occur behind you and not in front? I have measured the visibility distances of a selection of objects and the figures answer that question quite nicely. This screenshots illustrate the problem. First I slewed a suitable distance and then, with a high zoom of 12, took a shot of the horizon ahead and then of the horizon behind. You can see the extra objects crowding the distant horizon in the rear view. If you increase the zoom you can recognise the objects and you will find they are all xml objects. On the test area there are no roads, so no vector objects appear. http:www.kline.demon.co.uk/AUTOGEN1.JPG http:www.kline.demon.co.uk/AUTOGEN2.JPG (oops - it's not showing the images from my ISP server) Here are the measurements. The three figures are the on and off distances (the distance at which the object appears and disappears) and the hysteresis (the difference between the on and off distance). The distances are in miles. ON DISTANCE, OFF DISTANCE, HYSTERESIS power station: 7, 24, 17telephone pole: 7.3, 21.8, 14.5road sign: 7, 21.5, 14.5tank: 6.7, 16.4, 9.6fast food (chicken): 7.1, 20, 12.9road sign: off distance 23gas station: off distance 23building: off distance 6.8FS2000 building: off distance 3.5building: 1.7, 1.9, 0.16FS2000 building: 2.9, 3.1, 0.2 All the objects with off distances greater than 10 miles are xml objects (i.e. they're called up in default.xml). The record holder is the power station, which remains visible up to a wopping distance of 24 miles! (and this is by far the most complex object) If the power station were an astronomical object it would have a record red shift. These figures certainly explain why removing the xml file greatly improves matters. On my test scenery I found that, with the xml file removed, there was no trace of any frame rate fall, so the problem appeared to be solved. But when I flew in the LA area without the xml file, the problem was still there although significantly reduced. Dick and some others pointed out the reason: vector objects. These are objects such as light poles and road signs that are linked with VTP lines, usually roads. I followed Dick's advice and turned off the vector objects in fs9.cfg. Result: no fall off in frame rates. Of course the downside is that the autogen is considerably less interesting - but it's still impressive. I can only describe the xml / vector visibility distances as bizarre. As well as ridiculously large off distances (from ground level, the telephone pole is far beyond the horizon!), the hysterisis values are also enormous. Of course, this explains why the problem is most noticeable behind the aircraft - due to the very large hysteresis there will be far more objects behind than in front. The non-xml objects such as trees and the old FS2000-style buildings have much more sensible figures, typically an off distance of 3 miles and hysteresis of just 0.2 miles.So, can the visibility distances by changed to more sensible values? Sadly, the answer is probably that, with the current state of knowledge, it is impossible. For now at least, the only solution is to remove the xml file (or use a reduced version) and to switch off vector objects in the cfg file. The xml and vector objects are probably all library objects and they probably have visibility distances encoded into the library files. This would be bad enough, as I believe the format of FS2004 libraries is different and it is not known how to change the visibility settings. But it gets worse. In the other thread on the general forum Arno stated (if I understand correctly) that the autogen probably ignores these settings and uses its own values, which are probably hard-coded. So, unless some genius can decode the autogen software, the solution will have to come from Microsoft, either in a patch or a scenery SDK. On past form, be prepared to wait a long time! And be prepared to be disappointed, as there's probably no guarantee the SDK's will answer these questions. My own feeling is that Microsoft should fix the visibility problem with a patch. The visibility distances I have seen make no sense at all. It's almost as if someone chose the figures by tossing a coin in the air or throwing darts at a dartboard. To put it bluntly, I think it's the result of a mistake that was not picked up before release. The patch would simply change the visibility distances. Even better, it would allow visibility distances for each class of objects to be set by the user in the cfg file - I regard this feature as almost essential, but it will probably have to wait until FS2006. Meanwhile, if anyone can come up with a way of altering autogen visibility distances, I'll buy him a (virtual) beer! After some complaints, some compliments. After having flown FS2004 and after looking into the autogen in some detail, I have to say that I am extremely impressed by the autogen in general. Apart from this problem, it seems to work flawlessly and makes the world come to life while still achieving excellent frame rates. You've done a great job, Microsoft. But, please, make the final effort to finish the job! Best regards, Chris

[Guest GerrishGray]

Hi again ChrisThe problem is not necessarily going to be as difficult to solve as you fear. As I tried to explain in my post on the previous thread, library objects do contain a 'range' (MS call it 'image power') setting. It is dubbed the 'PWR' parameter in SCASM's LibObj() statement. This is the same setting as that contained in the section 9 object header (or, in SCASM terms, the range parameter in the Area() command). When a library object is called from section 9 scenery, the range ('image power') of the object is probably ignored and it is the Area() range of the calling sequence that is important. But when objects are placed via the Autogen + default.xml method, it is very likely that it is the object's own 'image power' that determines the range for which it is active. I see no reason or evidence for Arno to think that the range is determined within the Autogen code itself - he could be right, of course, but let's hope that his guess is wrong!Although we will not be able to check this and edit/correct the range settings of the default objects until we get a new Scenery SDK, I would guess from the format of default.xml that it is actually going to be quite easy to substitute other objects of our own design anyway once we get a new Autogen SDK.CheersGerrish

[Guest cwright]

If you want to see the screenshot then hopefully this will work: the address is kline.demon.co.uk/AUTOGEN.JPG copy this into your browser (must be capitals as shown) then prefix with the usual http://www. Best regards, Chris

[Guest Kurt]

Chris,Is the power station you are talking about, one of these ?http://forums.avsim.net/user_files/42507.jpghttp://forums.avsim.net/user_files/42509.jpgKurt M

[rhumbaflappy 113]

Hi Chris.Although we might not like the behavior of these library objects, we have already found the patch... delete the XML file.MS has provided us with a very ambitiuos load of eye-candy in this version. There are some mistakes and misjudgements they have made. This has been true of all their versions.At this point, I feel as Gerrish does ( I believe ) in that we can write our own libraries and make our own substitutions. Until someone does just that, and we can confirm the library object's image power is the problem, the rest is speculation.I do find it odd that this problem inflames so many simmers. Eye-candy = low FPS. Nothing new there. Get rid of the eye-candy and the FPS rises. Nothing new there.==========================Meanwhile VTP polys are still vertically flipped, texture-based autogen is still crudely assigned and controlled, and once a mesh is flattened, we can never return to the mesh with a simple exclude... all problems MS has ignored to this point, and all problems of much greater concern to scenery designers.The default fish joints will probably get excluded from my sceneries anyways.. or I'll place them as objects where I wish.Dick

[Guest cwright]

>Hi Chris.>>Although we might not like the behavior of these library>objects, we have already found the patch... delete the XML>file. Hi, Dick, as you pointed out, you also have to switch off the vector objects. With just the xml file removed, frame rates can still fall 50%.>>At this point, I feel as Gerrish does ( I believe ) in that we>can write our own libraries and make our own substitutions. >>Until someone does just that, and we can confirm the library>object's image power is the problem, the rest is speculation. That occurred to me. But the question is: how exactly are the visibility distances set? Is it set in the libraries or is it in the autogen code itself?>>I do find it odd that this problem inflames so many simmers.>Eye-candy = low FPS. Nothing new there. Get rid of the>eye-candy and the FPS rises. Nothing new there. I agree that more complex scenery will give lower frame rates. That's reasonable. But here the low frame rates are probably a direct result of a mistake made by Microsoft. A visibility distance of over 20 miles for a light pole makes no sense. And I think most simmers would get inflamed by an error that can cut frame rates by 80 percent!>>==========================>>Meanwhile VTP polys are still vertically flipped,>texture-based autogen is still crudely assigned and>controlled, and once a mesh is flattened, we can never return>to the mesh with a simple exclude... all problems MS has>ignored to this point, and all problems of much greater>concern to scenery designers. True, these are problems of concern to scenery designers. But low frame rates are of huge concern to the general users of the sim, particularly if they don't have cutting-edge machines. You probably won't see many posts complaining about vertically-flipped VTP polys on the general forum - but you'll see a lot about this problem! By taking out the xml file and switching off vector objects you can eliminate this problem. But people shouldn't have to do that. With the visibility distances fixed you would have all those features - giant chickens included! - and still get great frame rates. Best regards, Chris

[Guest cwright]

Kurt, it's the one in the upper screenshot. It's not actually a power station, it's what we in Britain would probably call a sub-station. Best regards, Chris

[Guest cwright]

Hi Gerrish, that sounds promising. If the SDK does indeed document the library image power format, then we should be home and dry! One thought occurs. There are actually two numbers, the on and off distances. If we could just set the on distance of a light pole, say, to 2 miles, and if the hysteresis were still the same, then the off distance would still be 15 miles.... Best regards, Chris

[Guest GerrishGray]

Hi ChrisDon't get image power (range) confused with visibility. Image power determines the distance at which the object becomes 'active' as one flies towards it and ceases to be active as one flies away - both the same. On a fast modern PC there should be very little processing delay to cause any noticeable hysterisis. An active object is loaded into memory and FS continually processes its code to see whether it needs to display it on screen. But the fact that an object is 'active' does not immediately make it visible - this is controlled by other factors.For section 9 objects the image power range is set by Area( type lat lon range ) and for library objects it is set by the PWR parameter in LibObj().Actual visibility is theoretically controlled for a section 9 object by the V1 parameter in RefPoint(), although it seems to also be affected by factors such as the object culling that goes on nowadays in response to the frame rate optimiser (in older versions of FS, the RefPoint() scale also had a major affect on visibility for some unexplained reason, but this has since been corrected). In the case of library objects called direct by the Autogen mechanism, there is no separate setting for visibility and so the PWR range is probably the only controlling parameter (other than automatic culling), which would explain why some of these objects appear at such great distances. When writing the code for a library object, other techniques can be used to control maximum visibility distance, if necessary, such as doing an IfVSize() or IfHSize() check. To cure the Autogen memory-hogging problem, it's principally the PWR parameter of the objects that needs changing (at least, that's my present theory!).CheersGerrish

[Guest JonP01]

Hi Gerrish,The problem I have noted using libarary objects (either with 3rd party programs such as Airport or with MS's very own version 8.0 compiler) is that the visibility paramaters are only correctly realised in the sim when approaching the object. When flying away from the object and looking back, they remain visible well past the range at which I specify in my bgl source.Try it yourself. Set out a long string of 30 power pylons, each spaced 1 nautical mile apart with the signal set to 8000 metres. Then fly along them. They will apppear at the correct distance in front of you, but then look behind you. They don't go away until well and truly past the 8000 metres. Often they just stick in view all the way to the visibility distance set in the simulation itself.

[Guest GerrishGray]

Hi JonI don't think you need to be too worried about visibility range when you look out the back window. It will have no measurable effect on frame rates except when you are flying along looking out the back window. But if this is a crafty way in which we can get better visibility when we want it, so much the better! The reason that there will be no measurable effect on frame rates is because if the object is completely off screen (as is normally the case when it is behind you!), FS is not even trying to draw it. As I said before, the visibility range of an object seems to be subject to a number of factors. The V1 visibility range has never given total control, and I too have sometimes seen objects visible at a greater range ... (in fact, it has even made me wonder whether the sim really takes much notice of the V1 figure we carefully provide - although it definitely needs and uses the V2 figure that prevents premature culling as an object goes off screen).The problem we have been discussing concerns the 'image power' range set for the object, which is different from the V1 visibility range. This determines when the object is loaded into memory to be checked for visibility, and when it will be discarded again. This value is often set to a much higher figure than V1 (typically 20-30kms, as opposed to 8000m say) and I am guessing that the Autogen memory-hogging is being caused by a default figure of 100kms - way, way beyond the actual visibility range. Again, I am not sure that the control given by this parameter is 'absolute' - what really goes on in the FS engine when it reads and interprets the pseudo commands contained in a BGL file is for MS to know and the rest of us to guess! They are never going to tell us the full details because it is a valuable commercial 'property' that they put enormous amounts of development effort into on an ongoing basis.Hey, trying to out-guess them in order to get the best out of our scenery designs makes a fascinating hobby, don't you think! Apparently, we sometimes even discover things that they didn't know themselves (which is fairly normal with any complex piece of software, in truth).CheersGerrish

[Guest JonP01]

>Hi Jon>>I don't think you need to be too worried about visibility>range when you look out the back window. It will have no>measurable effect on frame rates except when you are flying>along looking out the back window...The reason that there will be no measurable effect on frame>rates is because if the object is completely off screen (as is>normally the case when it is behind you!), FS is not even>trying to draw it. G'day Gerrish,Well maybe, but I'm not totally convinced :) The sim must surely be doing something different, even if it is just holding the data in real memory to be reloaded every time you look out the window from where you have flown already. The more full the memory becomes, I would have thought the slower the reads and writes may become on account of the massive amount of data to be sifted through and paged. The other issue is if you fly VFR scenic flights and your flight plan calls for you to turn back in the general direction from whence you came, the effect of all those objects remaining stuck in view all the way to max visibility is quite noticeable. Granted if you are flying only great circle routes or have long distances between waypoints where you still proceed in the same general direction, any effects may not be obvious or even noticable. I think the particular problems reported kill the low 'n' slow VFR folks more than IFR at the flight levels. In any case, it still makes me a bit nervous about how to tackle scenery projects with large numbers of small objects.

[Guest cwright]

Hello Gerrish, thanks for the explanations of image power. I looked in the old FS2000 scenery SDK and found some very brief references to it, and saw that at one place it indeed did seem to be set to 100. However, there are still lots of questions. If only the image power is used, what determines the actual visibility distances? And what determines the hysteresis, which can in some cases be a wopping 17 miles? The vis distance could perhaps be a fixed fraction of the image power. But however the on and off distances were determined in the code, it looks like a major oversight was involved. Without prior knowledge from Microsoft it's going to be very difficult to be sure. As I think Arno suggested, this function could be handled exclusively by the autogen system itself. Another question is the relative efects of image power and actual visibility. If, when in the image power range but not visible, then most likely all the object data is in memory, just waiting for the switch to be thrown. That would suggest that image power could have a major effect on available memory. That may be what I see, with a (very vaguely!) suggested range of 30 to 40 miles. However, at least on my 512 Mb system, memory never runs out, so it's not a major problem. But a 256 Mb system could well run into trouble with the autogen turned up to max. On the other hand, I would think the frame rate hit of an object being checked for distance would be far smaller than if it were actually being rendered. My observations support that. The frame rates were fairly consistent with the number of objects actually being displayed. To summarise, my feeling is that the image power effect could cause low memory (as you stated in your last sentence!), while it is actual visibility that can cause low frame rates. As always, we'll have to wait for the you-know-what from Microsoft. Let's hope it comes out some time this decade! Best regards, Chris

[Guest cwright]

>I don't think you need to be too worried about visibility>range when you look out the back window. It will have no>measurable effect on frame rates except when you are flying>along looking out the back window. Hi, Gerrish, as Jon noted, this can cause a practical problem. Probably many of the reports were from pilots who had taken off, flown for a few miles and then turned back to the airport. In this case the problem will smack you right in the face! I've seen frame rate falls of 80% (i.e. the FR has fallen to just one-fifth). This could be so severe that it could make a landing quite difficult. When this happens the only option is to refresh the autogen, in which case the frame rates will magically return.>Hey, trying to out-guess them in order to get the best out of our >scenery designs makes a fascinating hobby, don't you think! I agree, it does have a kind of fascination. It can be like exploring an undiscovered country, with occasional surprising discoveries.... Best regards, Chris