Shawn, I took a look at the effect of the weather visibility settings. First, after the scenery has been refreshed: When reducing from unlimited to 5 miles there was no increase in frame rates. But after that (3 miles or less) there was a marked increase. After flying or slewing for some time so that the frame rates when looking back have fallen significantly: When reducing from unlimited to 20 miles there was no increase. But with 10 miles or less there was a marked increase. This is quite consistent with my measurements. After refresh the most distant objects are at a maximum distance of 5 miles, so any larger visibility setting will have no effect. The same applies after experiencing a frame rate loss: now objects extend to about 20 miles, so any setting less than 20 miles improves the frame rate. This implies that (very approximately) if you set a visibility of 10 miles then the sim does indeed delete any autogen beyond 10 miles. Unfortunately this won't help if you like to fly in reasonably clear weather! Best regards, Chris

>Excellant piece of work and analysis. Thanks!>>FWIW, I have renamed the .xml file so that it does not get>used. I still see towers (poles) at 20 miles out from a>standing position at the airport (these are on top of some of>the mountains in this area, KRNO, NV). I've also removed the xml file. The autogen still looks great and the frame rates are much better. I've noticed, like you, that, although the telegraph poles are called up in the xml file they still appear along roads. I think it implies that, even if an object is removed from the xml file, it may still appear. Come to think of it, I'm not really sure what the precise purpose of the xml file is! >This, at least, says>that the problem may not be only with the default.xml file but>with other aspects of the autogen as well. When I wrote the original post I did suspect that the xml file was the villain of the piece. But I've changed my mind. After removing the xml file I found that on my test scenery (a large, flat plane with a single city land class and nothing else) there was no trace of falling frame rates. That seemed to confirm that the problem was indeed caused by the xml file. However, I just did a test flight around LA and I was surprised to find the problem was still there! However, the frame rate fall was far less extreme, so removing the xml file does help. It could be that, as I said, objects listed in the xml file can still appear even if they've been removed from the file. Or possibly lots of other objects have a large spread of visibility distances. It would need a lot of research to find out.... Best regards, Chris

>If you're right about the view distance, Microsoft may be able>to add a .ini that controls view distances of various object>classes. I've always said it's the "missing" slider. Some>people want more detail in their immediate surroundings, and>don't care beyond a certain point. John, that would be really useful. The lack of control of visibility distances can be really annoying sometimes. Some time back there was discussion about setting the distance for effects. It turned out there was no known way to do that. If you designed, say, a huge and spectacular volcanic eruption, it would only appear when you were practically flying over the volcano. cfg settings for different object classes (different autogen types, conventional buildings, effects etc) would be really good. The setting could specify either the default (whatever is assigned to the object) or a minimum and maximum pair of numbers to override the default. Best regards, Chris

Matt, I'll try that but I'm pretty confident it is specific to autogen. One reason is that there are such a huge number of autogen objects with the max setting (I always use that if posssible). Another point is that you can clear the problem (if only temporarily) by changing the autogen density setting and then returning it to the original setting. If I find the problem occurs with autogen off I'll report back! Best regards, Chris

Jon, sorry about that! If I had known I would certainly have credited you. My internet connection has been almost unusable the last few weeks, so I probably missed quite a bit. The man from British Telecom came last Sunday and fixed the problem on the line. Now my modem is working faster than ever! And if I did read your posts I may have missed the significance as I hadn't experienced the problem at the time. Also, my memory is a bit like a sieve! Best regards, Chris

Greg, I think the xml file may not be the cause of the problem. With the xml file removed the problem still appeared flying around LA, though it was a lot less severe. Also, I found that, although the telegraph poles are listed in the file, they still appear along roads with the file removed. But it would certainly be interesting to understand exactly what the xml file is doing. I believe Microsoft have a free xml editor, it may be called XML Notepad or something similar. Best regards, Chris

-"It could be that, as I said, objects listed in the xml file can still appear even if they've been removed from the file."-some of the same objects are placed by the default.xml file and as vector objects in the terrain.cfg file.ag_TelephonePole46f3d6cb43734270fb89e9aea92e4638// Medium road with light poles and telephone poles[Autogen.3.0.0]AutoObject="046f3d6cbh,043734270h,0fb89e9aeh,0a92e4638h"ObjectSize=219ExclusionWidth=3ClipData=1Offset=15Density=95PlaceOnWater=0MinAutogenDensity=20Kurt M

>So, why does this happen? From everything I've learned in>scenery design, FS likes to keep objects in memory since it>thinks they might get used again soon. You can see this>happen when a detailed object comes into your view, and>sometimes the textures don't load immediately. Well, if you>turn so that the object is out of your field of view, and turn>back to look at it again, you will not witness the same>texture loading again, since the object was still in memory.Martin, I was puzzled by something but I think your remarks have cleared it up. I ran my test scenery (a very wide, flat plane with a single city land class and nothing else) with the xml file removed. Of course, frame rates were a lot higher. As I slewed along there was no sign of a fall in frame rate. And yet the memory was constantly falling, just as in my original measurements with the xml file present. It must be that, as you say, although the distant objects were no longer visible, they were being kept in memory, just in case the pilot decided to do a U-turn and fly back!> However, I believe that the autogen buildings are>not library objects, but are older style FS2000 buildings that>FS creates on the fly using the autogen markup file. I base>this on the 8-bit textures that autogen uses and the autogen>SDK from MS. I'm not sure about the trees. So, the theory is>that if the autogen buildings are not library objects, then>framerates will suffer, which I think we have seen. I noted that what I called 'ordinary' buildings seemed to behave well with sensible visibility distances. These are probably the FS2000-style buildings. Trees also had sensible distances. The buildings that had the very large vis distances (up to 22 miles) were the more exotic types, some of which are in the xml file. My test scenery is located off the coast of East Africa, and so many of the long distance objects appeared to be mosques - I don't think they appear in the xml file. My assumption is that these 'exotic' buildings that cause the problems are library objects, but I don't really know.>>So, I don't think this is a bug, since the scenery is simply>being loaded like it should, but it is a product of the>trade-off that MS had to decide upon when it created autogen. >It came down to better framerates (library objects) versus>better objects (more variety). I'm sure that MS would respond>by saying that we can always turn down autogen, so if this is>causing a problem for some users then it may be your only>answer.> I'm sure Microsoft would say that! But don't forget, if the theory is right, the fundamental problem is caused by unreasonably large visibility distances for possibly a large sub-set of the objects. The result is a large fall in frame rates, although there is no corresponding improvement in the scenery display. A visibility distance of 22 miles for a telephone pole makes no sense, so to some extent it is Microsoft's problem. It would be great if someone could find a way of modifying the vis distances but that may not be possible.... Best regards, Chris

>The objects in this file are library objects, which I spoke>about in my previous post. However, the objects like bridges>and telephone poles are not placed like regular objects. They>are part of the VTP layer, and are placed in the same method>as roads and streams. Martin, I noticed something interesting. Of course, telephone poles are linked with roads (I think the term is 'vector objects'). But in my test scenery there are no roads (it's placed in the ocean), and yet some isolated telephone poles did appear. I think Microsoft used them as standard autogen objects as well as vector objects. No reason why not, if they're standard library objects.>>I think this would work. We had already discussed it in the>scenery design forum awhile back. The xml file only refers to>the library object that needs to be drawn, so it seem to>follow that we could make a new library bgl file and>associated xml file. However, would this solve the problem? >These files aren't used to draw the majority of library>objects anyway, and by making our own library objects,>wouldn't we be replacing one object for another? I suppose we>could provide better optimization, and that might help. I'm assuming that if replacement objects could be made, say, in Gmax, then they could be assigned reasonable visibility distances. I'm sure that would help. However, I'm now also quite sure that many of the long distance objects are not in the xml file. So, for a 'complete' solution, we'd need to do the following.1. Identify all objects with too-large vis distances.2. Either modify the libraries or make replacement libraries. As Arno pointed out, the FS2004 library format is not compatible, so we would probably have to wait for the scenery SDK and hope it contains the necessary information. On past form, that won't be until well into next year.... Best regards, Chris

Good work, Chris. This follows up on the post I made back a few weeks ago about testing with repeated views over time of the same area, and the point I made that there is no memory "leak" problem in FS9. The reason I have not had a problem with the autogen "slowdown" is that I am running a 3.2Ghz machine with 2 gigs of RAM and an 8 meg cache on my 7200 RPM HD.As I mentioned, if you have sufficient RAM, there is no need to cache the "saved" data to the HD. If you will recall older versions of FS, when you first view a wing view, it takes a second for the detail to load, but then, going back, it appears nearly instantly.I have found that you can use up OVER 512 megs of RAM with high slider settings quite easily. Reference the thread "FS9 - the facts" earlier in this forum and my post #94 or 95.MDavis

In FS9.cfg:TERRAIN_USE_VECTOR_OBJECTS=0Will delete all the VTP placed autogen. By using that and dleting the default.xml file in the Autogen folder, you should be back to FS2002.==================================These VTP autogen are defined in the terrain.cfg file.As Arno has stated, the display distance appears to be hardcoded for these objects.Dick

> By using that and>dleting the default.xml file in the Autogen folder, you should>be back to FS2002. Hi, Dick, as I said in my original post, I found that FS2002 also shows this problem, though it's far less severe, probably because of the less dense autogen. I've made some more measurements which explain why the problem occurs behind the aircraft and not in front. I'll post it in the scenery forum probably later today. Best regards, Chris

>What concerned me was the number of repeated guids in each>section [A to I] and that somehow code is triping over itself>What do theses A to I code sections mean or define cold we>live with just urban medium fo instance and chop the rest?? Greg, I think the A to I sections are for different world regions (certainly in the E-W direction and possibly for the N-S direction as well). My test scenery was off the coast of East Africa, and showed plenty of mosques but no chickens! When I moved the test area to just off the US coast the objects were quite different. With this in mind, you would expect many of the common objects to be repeated. Best regards, Chris

I think that FS2002 does NOT show this problem. During my testing, there was a drop no bigger than 1-2 FPS in FS2002, while the drop was 10x greater in FS2004. The denser autogen isn't the problem. The problem is that it's not being handled correctly by the sim. At least no the vector objects and objects defined in default.xml.Glad to see someone else investigate the problem, though. I kind of gave up because every time I posted a new finding, people would reply with things like "There's probably a problem with your system" or "Your expectations are too high" or "I don't experience these problems so they don't exist" etc...

"I think the xml file may not be the cause of the problem. With the xml file removed the problem still appeared flying around LA, though it was a lot less severe. Also, I found that, although the telegraph poles are listed in the file, they still appear along roads with the file removed. But it would certainly be interesting to understand exactly what the xml file is doing."That's because there is another place were troublesome objects are defined. Check the terraintextures.cfg file (I think), it has definitions for telephone poles, high voltage towers etc. You can disable these by editing the fs9.cfg file and setting "vector objects" to 0. I don't remember exactly the name of the line, and I can't check because I no longer have FS2004 installed, but look for something with the words vector objects in it and set it to 0. This will remove the telephone poles etc. and completely fix the slowdowns.