I still do get "some" stuttering at specific points along the runway and I'm pretty sure it's related to the Hanger
The hangar is static and simple, if you close its doors, the interior is just a basic textured flat polygon when seen from the outside with the doors closed.
The complex animated interior (and all the related sounds) will be loaded only if you open the door. Everything will be thrown away if you close it again.
So, as a general performance trick, always close the door if you are not interested in the hangar anymore.
Is it possible to further optimize your release/instantiate logic such that it only happens when VAS is close to the limit (i.e. around 3.8GB or higher) or when the source view is much closer to the object?
I'm guessing your current logic is operating from a calculated "view distance" from view source to object?
Well...yes and no. We already did this in 2007. Sometimes we still use this for very simple things, but KMEM is way smarter.
Today is far more complex: we use our collision system to help us define precise areas within a place so, instead of colliding, some objects appear when you "collide" (not really, just logically) in an area with a custom size in every dimension. For example, we have a logical cylinder around the Control Tower, so nothing is loaded unless you are *very* close to it, in front of the door, basically.
We tie also other conditions to minimize stuttering, for example not creating some stuff if your speed is higher than a very low taxi speed or, of course, if you are flying (or landing)
This is done entirely in C++ code in Couatl.exe, outside the sim, so the processing for this is zero VAS and zero fps impact. The stutters are not because we spend time calculating all our stuff. Couatl being a separate .EXE means it gets its own CPU spare cycles from the OS, and if you check how much CPU it takes, it's usually around 1% and not taken away from the sim.
What causes the stutters, is the time the sim takes to reload an object, which depends on its size. So, if you are discarding a 10MB 3D object, the advantage is that you just recover 10MB of VAS (+ VRAM for its textures), but the side effect is that you will have to reload it these 10MB at some time, hence the small stutters.
The scenery would never, ever, fit in RAM, if we tried to fit all at the same time. Just the small scenes with some animated guys around every parking take about 4-5 MB each, and there are 200 of them! That would mean 1.0GB just for them, and this is just polygons without even considering the textures...instead, we can select to load only the 2-3 close to your plane, and take only 15-20 MB instead of 1.0GB.
So for those of use that are NOT on the "edge" of VAS don't have to be subject to the resource release CPU penalty.
Well, but there's also the fps issue. Even if you could afford more objects to be loaded before having a problem with VAS, you'll then start to have fps issues.
Again, keep up the innovation for VAS consumption ... hopefully come year end you'll not have to worry about that any more
I really hope that 64 bit will not be an excuse for lazy developers to "put everything in", just because it won't ever OOM, slowing down the fps to a crawl...
