I think I finally experienced the dynamic scenery slowdown issue, and it's pretty easy to reproduce.I was flying to Mooney into 16L at KPAE. As I turned on final, I noticed my fps dropped WAY down. I went into display settings and moved Dynamic Scenery from Extremely Dense to Very Dense. Fps went back up to about 28. I went back into display settings and moved it back to Extremely Dense and they stayed high. Landed and decided to go around again.On the second pass, I experienced the same thing. A flip of the Dynamic Scenery slider down a notch and back up restored my fps.I will run a Perfmon counter on this tomorrow if I have time and report my findings.Jim

Well there's no doubt in my mind that it's there. And yes, it's easily reproducible. :-erks Be interesting to see your findings. MDavis has posted some findings before too.Regards,Jim

>I went into display>settings and moved Dynamic Scenery from Extremely Dense to>Very Dense. Fps went back up to about 28I Guess you mean autogen scenery and not dynamic scenery?Wolfgang

Yes I did. :) It was late.Jim

As you are testing, set up a hotkey assigned to the Refresh Scenery function under the Options > Assignments menu. See if pressing that one key accomplishes the same thing as changing the slider. It works for me and its quicker and easier than the other way.Someone posted this tip on this forum (JohnCi, I believe) but it has never gotten the attention that I think it deserves; it's a great workaround.Another way to make the assignment is to place this line into the {KEYBOARD} section of your FS9.cfg file:REFRESH_SCENERY=83,11This assigns Ctrl+Shift+s to the function. R-

Good idea. Thanks.What I'm really interested in is getting some concrete information as to what is causing it. I have seen many people speculate that it's this or that. However, I haven't seen any concrete proof from anyone. A Perfmon log will definitely show us what's going on.Jim

I ran a perfmon on this tonight. It's definitely not a memory leak, but something's going on. See the image below. The green line is private bytes for the fs9.exe process. As I flew from Seattle to KPAE, you can see the memory increasing a little and dropping a little. Right before the big dip, I was on final to KPAE and saw frame rates drop to about 11 or so. Note that there is no increase in memory usage at the time of the slowdown. However, there is a significant drop after I changed display settings.I went into display settings and set autogen down a notch. I then clicked OK, went back into display settings right away and moved it back up. There was a significant increase in framerate after doing that and I was back up to about 30-35, and as you can see from my counter log, there was also a fair amount of decrease in memory usage. For me, seeing it in a Perfmon log makes it real. No disputing real data. It's definitely not a leak, but something's going on.JimP.S. The blue line is handles. Just checking to see if it was a handle leak. :)http://forums.avsim.net/user_files/44984.jpg

Jim, I looked into this recently and I think I understood the root cause. Unfortunately at the moment the solution has to come from Microsoft. I believe the problem is caused by excessively large visibility distances of a certain class of autogen objects (JonP01 came to the same conclusion). There is also a huge difference between the on distance and the off distance (the distance at which they appear and disappear). This difference explains why the problem becomes serious when you look back or turn back. An example: for the telephone pole, the on distance is 7 miles (compared to less than 3 miles for 'normal' autogen buildings), but the off distance is a wopping 22 miles! That means that, after flying past a pole, it will still be rendered until you have flown another 22 miles. In practice, when you're flying over urban areas a huge backlog of autogen objects builds up behind you, so when you look back the frame rate can fall drastically. I've measured falls of 80 percent! When you change the autogen setting everything is flushed out so the frame rate recovers to normal. Gerrish Grey pointed out something that may well explain the memory use. There is an extended area where FS keeps the objects in memory, because it repeatedly checks to see if an object comes back into visibility range (Microsoft uses the term 'image power'). Again, when the autogen setting is changed these objects in memory (not just the visible ones) will be flushed out, so available memory will increase. The problem objects are the ones defined in the default.xml file in the autogen folder. If you remove this the problem will be a lot less severe. To remove the problem entirely you also need to switch off autogen vector objects (telephone poles, light poles etc) in fs9.cfg. Hopefully Microsoft will fix the visibility distances in a patch or give us the information so we can do the job. But until then, probably the only way to remove the problem is to remove the objects, which is a shame! By the way, there was some discussion of this in the scenery forum. It'll be a few pges back, look for the word 'visibility'. Best regards, Chris

Chris, Makes perfect sense. Originally, I saw people saying this was a memory leak, but it just didn't seem like it to me. The Perfmon log proves it's not a memory leak. However, your conclusion is right on.In order for me to reproduce this, I had to fly from SEA-TAC to KPAE and then fly the pattern to 16L or 16R. It reproduced doing that because KPAE is almost due north of SEA-TAC. Excellent troubleshooting on the part of you and the others, Chris. I know that this topic has been beat to death, and the workaround of deleting the default autogen XML file has been mentioned a thousand times. I was just curious to confirm what was going on with real data. :)Jim

Hi Chris.It's hard to keep it straight, but Image Power is not a visibility setting. It is a setting that tells the program to account for the object ( and all it's polygons ) in the XYZ calculations that place images. If the Image Power is too small, objects can suddenly disappear at the I-P theshhold. If it is too large, the CPU will bog down as objects that aren't even seen anymore are calculated.In FS2002, I noted that MS broke it's own SDK recommendations with their default objects, concerning what in SCASM is called V1 and V2... simply assigning them as "0", which gave some objects maximum visibility range ( 22 kilometers ? ). They very well may have broke their own rules again by assigning the Image Power ( or it's new equivalent ) to "0" for the autogen library objects.... or worse yet, it may be hardcoded into the sim.The problem is compounded by the fact that the viewport affects the FPS as well. Increase the zoom, and FPS will rise, as the number of objects ( and their polygons ) is decreased in the view. Zoom out, and the FPS will crawl downwards, as more objects crowd the screen. This has been true of past FS versions.Bottom line is that this is still a CPU problem caused by the rendering of too many polygons. The "normal" autogen doesn't have this extreme problem, as they are 2-plane trees and shrubs, and simple box-like buildings. Burger joints, minimalls, and telephone poles are much more complex objects, and require much more CPU time to place the facets in the 3D world.FS9 is a whole new ball game as the old BGL format is now entirely changed, and we'll need an SDK and a new compiler to test out new ideas ( and a new decompiler to see what damage the default BGLs have done ).FS9 seems to smooth out a bit with newer CPUs such as the Athlon64s or hypertheading Pentiums. That seems to support my claim that this will be a non-problem 2 years down the road, as we start upgrading to 5+ Ghz processors and PC10000 memory. Newer vodeo cards won't help, as it's the CPU spatial calculations that are bogging down the sim.Dick