After months of VRAM overload, we suddenly see that VRAM is being cleared much more aggressively, and at the same time, people are complaining that freed-up VRAM has to be reloaded when you rotate the camera. To me, that’s no coincidence.
We are talking about several seconds up to a minute. Would like to see how people are complaining if it takes a minute till a new frame is rendered.
Well, maybe I’m ignorant, but I don’t understand why if I never stop during the complete rotation of the camera on each axis in virtual reality, everything is smooth, and if I stop for about 10 seconds, then stuttering occurs. What I don’t understand is that when I stutter, it doesn’t actually load anything new, because even during the stuttering, all the objects around me are still there and have never moved from there.
When an object is out of view for a period of X seconds, it is jettisoned from memory, to make room for new objects coming in to view.
So when you continue panning around, the same object has likely not been out of view long enough to be jettisoned.
But when you stop panning, and wait, then objects out of view are jettisoned. So then when you pan again, they need to reload.
It’s my suspicion that the reloading needs to be optimized / improved. I believe it is trying to load too many objects all at once - saturating the CPU, so that the GPU is just waiting, causing a stutter. If that’s correct (I could be wrong) then they can/should implement a queue for loading objects.
Example, instead of loading 100 objects all at once, load 20, then 20, then 20, then 20… or make it dynamic so that it loads what it can without saturating RAM, VRAM, CPU or GPU… currentlly the loading seems to be priority over framerate, I’m suggesting reversing that to maintain fluidity, but also a guardrail to prevent overloading either CPU or GPU resources.
I don’t understand why you see it, and why I don’t, as I demonstrated in my video.
This explains the problem and how to perform the correct test. I took the H125 in LIPZ default mode. The settings are set to ultra, but I can easily “drive” them, as shown by the FPS and the ease with which I can keep it off when stuttering appears. I thought that those who play with very low details might not have the problem, or won’t notice it. Anyway, even in your video you can see the problem in some places. Considering that you’re using a C172, if you were using a PMDG or a Fenix, the problem would be much more amplified.
This would lead to blurry textures and popping up objects while panning the first time after a pause.
Another curious thing that I still don’t understand…why when we open a menu in the game, for example the camera menu, the fps has a drop of about 10fps for about a second?
This is completely normal. Make yourself clear, what happens, if you open the menu. All the data has to be collected, it has to be rendered, objects have to be moved to the background and become invisible, alpha channels are added, … I’m surprised that it is only 10 FPS, I expected even more.
Sometimes I’m not sure people are aware of the complexity this simulator has and what it means for the hardware.
Do you have timestamps? I can review the footage.
Now grab that window, and whizz it about the screen? Do you see an FPS drop now. I dispute that this is normal, but it is normal for MSFS. Opening any of the top menu’s will also disrupt the flight model simulation of A2A planes, the only ones that exhibit that “fault”.
But this is rapidly moving away from the purpose of this thread, the stutters that some people get when keeping their view in one spot for >60 seconds, and then moving their view. I could not replicate that in testing.
No, no, wait, maybe you misread or I expressed myself poorly. I don’t mean when you exit to the game menu, I’m talking about when you open the camera window (for example) from the game bar, there’s a drop of about 10fps for no apparent reason.
Me too. And this is still normal.
For me, SU5.1 resolved the “60s idle issue”. Heavy stutters have gone, now I can’t reproduce it.
Some FPS drops on camera rotation still present, but, by my opinion, it isn’t related to previous 60s timeout, appears eventually and does not break everything as it was before.
Situation returned to “acceptable”, i hope this heading will give us to a completely smooth simulator in the future. 
Still have this issue with 5.1 release build and can reproduce it reliably every time
Same for me.
Still problem in su6 beta
The stutter problem is still present in version 5.1. Hopefully, they will fix this in SU6, but it seems they don’t know how to resolve it.
I watched your YT video again and it seems to me that you don’t have the typical stuttering issue. It looks more like you are dropping frames.
I also wonder why you are running MSFS 2024 with vsync off?