This FS2004 problem has been discussed quite a bit. It's certainly quite serious, as it can cause frame rates to fall as much as 80 percent. This is how the problem appears: suppose you re-load the scenery, take off from an area with dense autogen and then continue flying for a few minutes. Then, if you either look back or make a U-turn, you find that the frame rates have fallen sharply, making it difficult for the approach. Also the available memory continues to fall. I found that by refreshing the autogen (simply change the density setting and then change it back to the original setting) the frame rates and memory miraculously recover. But after a few minutes the frame rates again fall. This suggested that FS was not correctly deleting autogen objects during flight. It certainly looks like, feels and smells like a bug. But is it? First I looked to see if FS2002 has a similar problem. It showed the exact same effect (falling frame rates and memory), but it was far less marked. Typical frame rate falls were 30 percent, compared to 80 percent in FS2004. This makes sense, as autogen in FS2002 is far less dense. But nevertheless, both sims show the same basic effect. Thinking back, I think I do recall some reports of falling frame rates during flight. I then looked at the visibility distances in FS2004. What I found was surprising. I found that for 'normal' autogen objects (houses, trees etc) the vis distance was 2 to 3 miles. But for another class of objects it is an amazing 14 to 22 miles. I suspect this class of objects include the objects listed in the xml file (default.xml in the autogen folder). Possibly it is only the xml objects that have these large vis distances. The vis distance for the light and telegraph poles is 22 miles! Bearing in mind that these are very thin objects, this is quite bizarre. At a small fraction of that distance they will be less than one pixel wide. I strongly suspect that all the objects in the xml file also have very large visibility distances. This would certainly explain why removing this file has such a marked effect on frame rates. To get consistent results I made a large, flat area with a single city land class. I then slewed across and stopped every 5.5 miles (5 minutes of arc) to measure the available memory, frame rate and to take a screen shot of the horizon at a high zoom setting of 12 (looking backward!). Here are the readings:(I had to use commas to space the columns as the forum doesn't seem to allow multiple spaces).Memory (Mb),,,,,,,Frame rate (FPS),,,,,,,Distance travelled (miles) 227,,,,,,,,,,,,,,,,,,,,,,,,,,8.7,,,,,,,,,,,,,,,,,,,,,,,,,,,,0 189,,,,,,,,,,,,,,,,,,,,,,,,,,5.6,,,,,,,,,,,,,,,,,,,,,,,,,,,,5.5 173,,,,,,,,,,,,,,,,,,,,,,,,,,4.5,,,,,,,,,,,,,,,,,,,,,,,,,,,,11 155,,,,,,,,,,,,,,,,,,,,,,,,,,3.0,,,,,,,,,,,,,,,,,,,,,,,,,,,,16.5 154,,,,,,,,,,,,,,,,,,,,,,,,,,3.4,,,,,,,,,,,,,,,,,,,,,,,,,,,,22 139,,,,,,,,,,,,,,,,,,,,,,,,,,2.5,,,,,,,,,,,,,,,,,,,,,,,,,,,,27.5 145,,,,,,,,,,,,,,,,,,,,,,,,,,3.2,,,,,,,,,,,,,,,,,,,,,,,,,,,,33 135,,,,,,,,,,,,,,,,,,,,,,,,,,2.5,,,,,,,,,,,,,,,,,,,,,,,,,,,,38.5 139,,,,,,,,,,,,,,,,,,,,,,,,,,3.5,,,,,,,,,,,,,,,,,,,,,,,,,,,,44 132,,,,,,,,,,,,,,,,,,,,,,,,,,2.4,,,,,,,,,,,,,,,,,,,,,,,,,,,,49.5 141,,,,,,,,,,,,,,,,,,,,,,,,,,3.5,,,,,,,,,,,,,,,,,,,,,,,,,,,,55 137,,,,,,,,,,,,,,,,,,,,,,,,,,2.4,,,,,,,,,,,,,,,,,,,,,,,,,,,,60.5 REFRESH 172,,,,,,,,,,,,,,,,,,,,,,,,,,7.6,,,,,,,,,,,,,,,,,,,,,,,,,,,,60.5 The frame rates are fairly low because the city extends all the way to the horizon. The number of autogen objects is limited only be the visibility distance!For the first 27 miles the frame rate and memory continued to fall, but after that there was no clear trend. I think the changes after that were caused by complete areas of distant autogen being deleted. The horizon screen shots agreed with the figures very nicely. For the first 27 miles they showed the autogen moving further out to the horizon, and then further shots continued to show the autogen distance varying in agreement with the frame rates and memory. 27 miles agrees quite well with the maximum view distance of 22 miles. After travelling 27 miles the autogen extended to about 22 miles behind the aircraft. After that the max object distance would remain constant at 22 miles, and so there would be no further fall in frame rate and memory. That's pretty well what the figures show. In other words, there was no sign of any error or bug in the object culling. I don't think there's a bug in the actual autogen software. In fact I'm very impressed at how well it works. I think the problem lies with the visibility distances. When the autogen is refreshed the frame rate goes up dramatically. I think this is because, when reloading the scenery, the sim ignores the visibility distances and creates autogen in a smaller area. After refresh, I found that the greatest object distance was 7 miles. But when slewing, objects were at least 13 miles behind. And objects can appear at up to 22 miles. If limited to 13 miles, there would be four times as many objects when flying compared to after refresh. And that's a conservative figure. The real ratio could be more like 10, ie when flying, the autogen density behind the aircraft could be ten times higher than the density after a refresh or scenery load. That would obviously have a huge impact on frame rates. If confirmed, these observations strongly suggest that the fundamental problem lies with the visibility distances of some of the objects. I would guess that these objects are stored in a library and their vis distances cannot be altered. If so, then Microsoft will have to supply an updated library in a patch. If there is a way of changing the vis distances of library objects then that would be the ideal solution, but it's unlikely. Any experts out there have any ideas? There could be another solution: for some enterprising person to design an alternative set of objects in the xml file. These objects would have sensible visibility settings. It should be possible to use the existing textures. The objects could then be made into a library with Fsregen and a new xml file made. Any takers? To summarise: I don't think there is an actual bug in the autogen system (though there may have been a bit of a memory leak, but not too serious). The problem lies with the visibility setting for a set of objects that probably includes all the objects in the xml file. Frame rates are initially higher because, on refresh or scenery load, the sim ignores the visibility distances and places objects in a smaller circle. XP2400+, 512 Mb RAM, ATI 9200, Win XP Best regards, Chris

Hey Chris -Do you suggest that simmers who normally get between 8 and 15 fps set their visibility lower? I think I have mine set around 100 now.Thanks,Shawn

A brilliant and well detailed experiment!

Excellant piece of work and analysis.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). 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.Larry S.

Chris, I've wondered if vis distances are the issue as well. It may also explain why fps seem a bit less around airports. If you look around the airports "object" wise, there's some new objects--such as the new rotating beacons and fueling stations.(On a sidenote, lower your vis. to 1/4 mile, and position yourself looking up at an airport beacon.... Worth the trouble)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.Another option would be a feature that randomly removes autogen objects based on distance--say 25 pct of them at five miles, 50 pct at ten miles, and 100 pct at 20 miles....Good post--very good style to your testing... -John

Have you tried turning off autogen completely and doing the experiment over? That should tell us if it's autogen or not.Matt

I'm not trying to detract from Chris's observations, but I've been stating the problem is related to visibility - in these forums - repeatedly - for quite some time now. I therefore conclude no one bothers about what I have to say any more.

I think we should be able to change the library objects.I will take a look at this when I at home.Did anyone known the name of the Library BGL file? The BGL Library format is described in the FS2000 SDK's and didn't changed (so fa I know). So it should be possible to find the object entries and correct the view distance to lower values.Like said before, I will look at it when I'm at home.If someone has expierience with BGL file debugging, it should contact me.ByeMarkus

I've been looking at the default.xml structure and can see it has Defined Code areas Code A through to IIve noticed that the guids objects are repeated in each sectionalso Code sections Like Rural Large, Rural Medium, Urban small, Urban medium ,Urban LargeDoes anyone think that there is a way of trimming down the guids so they are not repeated ,could that be the problem that they are repeated in different code sections so muchCould we remove entire sections like Urban small plus Urban medium and just modify Urban large to contain what we want?Just Bouncing ideas around ,I'm no programer but do like to put some thought into thingsWhat concerned me was the number of repeated guids in each section [A to I] and that somehow code is triping over itselfWhat do theses A to I code sections mean or define cold we live with just urban medium fo instance and chop the rest??Just stuff for thought and explorationAnyone know of a Good freeware xml editorKind regards GregNew Zealand

Jon,at least I remember, taht you have stated that before! :-)But don't be too harsh with the folks here in the forums. Some threats are getting real long, espeacially the one's concerning performance, findings about bugs etc., so that it is sometimes nearly impossible to read all the posts in one thread. When the Europeans get up there are so many additional posts written by the Americans, Australians etc. and vice versa, that it can be quite a work to read all the new posts of a thread, or even dioscover a thread which has not existed when you went to bed, but has allready moved to page 4 when you wake up.Also I skip posts, when threads are getting too long and too complex, even when they are interesting to me.I remember, that last year there was a guy on the other forum, who decided it was his duty to keep interesting threads on the front page for the "other" half of the world v. v. by bumping or just writing some funny comments into the thread. Many forum mambers did not understand why he did this and complaint about him to the mods, which resulted that this guy finally was banned from the forum. :-(Wolfgang :-wave

Let's pass this to the scenery gurus next door, sure they will know about this and can guide us about those issues.Posting a link in the Scenery forum....Gabriel

I have a couple observations about what I've observed in FS. First, autogen has always been a resource hog. This was always the premier framerate killer due to the sheer number of objects being drawn. Thisis especially tru in FS9 due to the increased density of autogen, and the addition of new obejects like telephone poles and bridges. I beleive there was another post in the forum describing how you cold edit the autogen file to edit out the other objects so as to improve framerates. I personally choose not to do this, as I do not have a problem with the autogen.Next, the phenomenon which you describe about how you lose memory/framerates if you turn around makes a bit of sense, from my perspective. I have witnessed the same effect at highly detailed airports, where I have turned around for another look, and noticed my framerates were lower. So, this may not be limited to autogen, but it makes sense that it would be more pronounced due to the higher density of autogen.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.Ok, so when we design scenery, we try to use library objects, since the object will only have to be loaded once, but used many times in the scenery. Some examples of library objects are: baggage carts, fuel trucks, telephone poles, and the fast food restaurants that you see in the autogen (there are many others). 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.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.- Martin

Hmmm, after my post, I did some more thinking, and a couple things came to mind when I re-read your post.> I then looked at the visibility distances in FS2004. What I>found was surprising. I found that for 'normal' autogen>objects (houses, trees etc) the vis distance was 2 to 3 miles.>But for another class of objects it is an amazing 14 to 22>miles. I suspect this class of objects include the objects>listed in the xml file (default.xml in the autogen folder).>Possibly it is only the xml objects that have these large vis>distances.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. VTP objects are visible from very far away, but regular scenery objects (buildings and stuff) have a limited visibilty range of approx. 16km. You were right on when you made a distinction between the "normal" objects and the library ones.. > There could be another solution: for some enterprising>person to design an alternative set of objects in the xml>file. These objects would have sensible visibility settings.>It should be possible to use the existing textures. The>objects could then be made into a library with Fsregen and a>new xml file made. Any takers?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 think that simply deleteing (or, renaming) the xml file would be a good place to start if people are having framerate problems. This was described in other posts in the forum. If that isn't good enough, then we may need to turn down the autogen a little.- Martin

Hi Markus,I think this would not help. First the format of the Fs2004 libraries is different then the format of Fs2002 (and Fs2000, as described in the SDK), so we can not change them.But also the distance of the objects is not coded in the library normally. That is "given" to the object when it is placed. I think for the autogen this is something hardcoded (not sure).For the rest of this interesting problem I would need to do some testing myself, before I can make useful comments :).

>You were right on>when you made a distinction between the "normal" objects and>the library ones.. I think it would be better to distinguish VTP objects and normal objects. If you would place an autogen library object with a normal API, then they also have the limited range. So it is not the library object, but they way they are placed.>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 think you are right. Making a new object but placing it with the old method would not help I think, as it does not influence the range. Also the MS object are rather simple and have LOD models, so the new models would not be that much more efficient.