I took the liberty of downloading the video from your original post and went through it frame by frame. It shows exactly the phenomenon I’ve been scratching my head over for a very long time and that, in my opinion, has always existed in the engine to some degree, just with varying severity across different SUs and builds.
When vertically rotating the camera across the horizon, the engine appears to flood VRAM (and possibly system RAM acting as a fast cache) with a large chunk of assets coming from the rolling cache. In your video, VRAM starts at around 9201 MB and total allocated RAM at 17321 MB. During the camera pan, the peak reaches roughly 10165 MB VRAM and 18778 MB total allocated RAM.
So far, nothing too spectacular. But here’s the interesting part:
The rolling cache read-speed peak of ~470 MB/s only happens well after your initial downward camera pan is already over. It lags significantly behind the memory allocation.
That raises a few questions:
Is there some kind of ramp-up latency with the rolling cache? If so, you’d probably never notice it during normal cruise because assets are streamed steadily in smaller chunks into already allocated VRAM.
But what happens during a rapid camera pan, when the assets that should be rendered simply aren’t there yet? Does something fall out of sync and cause the stuttering? Or does the state machine actually block while waiting for assets to finish loading up to some timeout value?
That second would explain why the camera panning sometimes seems to “stick” and then suddenly jump forward again because it still has queued mouse/input event data it needs to catch up on once the timeout expires.
What’s also interesting is that you can manipulate the size of the chunks being pushed into VRAM and with that, the severity and rhythm of the stutters (I’m not saying improve, just change the cadence):
TLOD and OLOD obviously affect it, so I won’t go deeper into those.
ReBAR: When enabled, it removes the 256 MB transfer limit for CPU to VRAM flushes. In theory, that should improve performance. But for the specific issue we’re discussing here, it seems to make things worse. You can clearly see larger chunks being transferred during camera pans, and the stuttering becomes more pronounced.
Off Screen Terrain Pre Caching: In theory, higher settings should keep more assets resident in VRAM and reduce rolling cache access. But during these camera pan scenarios I’m seeing the exact opposite. Chunk sizes increase and so does the severity of the stutters.
Again: ReBAR enabled and Off Screen Terrain Pre Caching set to Ultra may work perfectly when the engine is fully “in sync” during cruise (camera fixed straight ahead, or slow camera rotation), but during rapid camera movement I consistently observe the opposite behavior.
Maybe it would help if the engine treated at least ground scenarios differently when the aircraft is stationary reducing how aggressively assets rotate between cache and VRAM compared to cruise, while also using a larger portion of available system RAM for caching than it currently does.
Or maybe the engine simply shouldn’t even try loading assets for areas the camera is going to skip over anyway during very high-speed camera movement.
On the other hand, after all the ups and downs I’ve seen with this phenomenon across multiple SUs and builds, I’m pretty sure the developers have already tried all kinds of approaches. What we currently have is probably the best compromise they’ve found so far without causing trade-offs somewhere else in the engine. And that’s why I’m not even sure it’ll ever officially get logged as a bug. Although of course I still really hope it eventually gets solved.
And yeah, sorry for all the details and the long post, but this issue has been haunting me for ages and I just had to get it off my chest. 