So, my question is this: why do people with high performance machines suffer this problem while FlyTampa and ImagineSim sceneries (Boston & VHHH) do not seem to pause to load *ANY* kind of scenery objects? FSDT seems to 'pause' the entire sim for 1 second for loading objects.. .
Also, as I've already explained in another reply to you here:
http://www.fsdreamteam.com/forum/index.php?topic=1653.msg13042#msg13042No need to repeat all the explanation again but, it's always miseleading to compare different sceneries located in different areas. Remember that, before we released JFK, many people tought it would be impossible to have a full JFK running in FSX. If we had an Imagesim's JFK, it would be interesting to judge both fps and quality.
Also, comparison with photoreal sceneries shouldn't be done, because they are just too different from an airport. Comparison with Manhattan X is also not very useful, because that scenery, as complex as it is, is spread over a larger area compared to an airport. The issue with airports, it's the extremely high object count in a very small area so, the chance of optimize using visual ranges and LOD is much smaller.
Note that, a scenery made with BGL only, usually has a visible range of about 10000 meters so, less than 6 nm. Meaning: the whole scenery will be loaded in memory at that distance. This means, an higher Antipopup value that will be able to duplicate this situation, should not make any difference, at least once the scenery has loaded. The value of 20 should be able to do this, because no objects usually have a default range less than 0.3 nm.
You might get a pause at 6 nm, perhaps even a longer one, compared to a BGL-only scenery, but then you shouldn't have any more pauses.
If, by saying "you still get them while on the early approach phase", you mean just about this distance, then I'm afraid there's nothing much more to do, at least with the current Addon Manager version, you have to live with the pause at 6 nm, which is not even related to system speed because, since we use Simconnect calls to draw objects, the speed is not so much dependend on the system, but is more bottlenecked by the efficency of the Simconnect client-server system. Meaning, the response time might depend more on how *many* other addons are making Simconnect calls at the same time, because in order to handle all of them without losing anything, there must be some kind of scheduling and priority system happening in the FSX Simconnect server and there IS a lag from the moment a command is issued and it's actually executed.
Note that we used a different method in XPOI, which has a quite complex scheduling mechanism on its own, because it's able to load hundreds of objects in the background, without ever slowing down the sim or pausing it.
So, I guess you might be tempted to ask why we don't used the same method with the Addon Manager, and the reply it's quite obvious: XPOI objects spans around the user in a very large area so, we can slowly pre-load them while flying, without disrupting the flight. Nobody will notice that an object that is 20 nm away has taken 20 seconds to appear. We also use some tricks in XPOI, like the POI title being loaded at a different (later) time than the object itself. And, of course, XPOI objects are all of the same size and take all the same amount of memory/textures so, it's very easy to precisely fine tune and optimize loadings, something that doesn't happen with an airport, were objects are dramatically different in dimensions and memory used and visibility requirements.
The XPOI method wouldn't work too well with an airport, that should load almost immediately. If we used the same approach as with XPOI, we might be able to get rid of pauses altogether, but the airport might take 15-20 seconds to appear entirely, because in order to get rid of pauses, we should load objects one by one on the background. This wouldn't be acceptable as well: imagine if you had to wait 20 seconds to have, let's say, the main terminal appearing...
I'm afraid there's no true solution to this: the use of the Addon Manager method of loading objects, allows us to get USABLE frame rate across a wide range of systems because, in exchange for pause, we get finer control on visual range, that allows us to create sceneries that wouldn't simply run otherwise OR we would be forced to compromise on modeling detail and/or texture quality, and the result is much better fps with the systems most user have.
