I’ve been working on a dynamic frame scaling system, basically polling fps for n frames, averaging the result, then deciding whether to change FSR2 scale to one of the recommended values. It’s as imple script and works very well as expected, as long as I don’t resize the window of the running game or go fullscreen. Then fps will behave totally erratically. Dropping to 1 in one frame, shooting up to 60 in the next, remaining at the expected value for 1 second, then nose-diving again…making the game unplayable.
I’ve tried all forms of logging, monitoring and console checking known to me and see the fps spikes, but no clue as to what’s the cause.
What’s more, the stuttering continued even after disabling the scaler script completely, saviong and re-loading the project - so now I had this issue even without the scaler script running. I have to go back to an earlier backup, which after a couple of sessions is starting to get wonky, too… I have really no idea what’s happening here.
I feel the issue migth be related to VoxelGI and/or SFDGI. It seems not to happen with no GI enabled, unless I run the project with GI first and get the above described weirdness. Then it will carry over to the next time I launch the scene, even if closing the editor in between, meaning I have to go back and use that backup again…
The project is pretty big, so I can’t share it, and I’m aware that diagnosing from afar is probably impossible, but at this point, I’d be grateful for any ideas how to approach this at all.
So, the fact that this persists after closing and reopening the project means that something gets stored somewhere inbetween. You should try and locate what that is.
I don’t know anything about 3D, but skimming over the VoxelGI intro in the Godot documentation gives me an impression that there is intermediary data being stored somewhere (“baking”?) and also there were some resolution-related settings. So this does seem in the right ballpark.
Another thing that I’ve picked up by osmosis is that modern GPU drivers tend to optimize stuff by caching. Compiled shaders, in particular, are cached in memory and/or disk. Perhaps other stuff too? If the resolution change also forces these resources to change, that could lead to expensive cache misses.
Lastly, pehaps is it possible to do some kind of profiling and narrow down the list of possible suspects?
Thanks for the suggestion! I’ve already tried deleting the bake files, but you’re right that some data must be saved for the issue to persist between sessions. I’ll try clearing the shader cache next. Is there anywhere else that Godot writes a cache to which could be cleared?
As for profiling: I tried the in-editor profiling tools and found nothing, but the process (not the physics process) frame time shoots up to an extremely high amount during the FPS dips. However, memory, rendering and scripts all show nothing out of the ordinary. RenderDoc might help, but I have little experience with it and no idea where to start.
The frame rate can suddenly sink really low with accumulating effect if the physics engine is overworked. The effect is related to the number of physics ticks per frame and the problem of larger deltas with high frame times caused by heavy graphics or anything else somehow causes the physics engine to work overtime - and thats the accumulating effect.
I see. But wouldn’t that be visible in the physics_process monitor or profilers?
And while that might explain what’s happening when switching to fullscreen and thereby taxing the hardware, it doesn’t explain why it also continues to happen in windowed mode, where everything used to run smoothly even without FSR2, and even after resetting/disabling everything to do with frame scaling. Besides, there isn’t that much going on in terms of physics based interaction, no more than two CharacterBody3ds and a handful of RigidBody3ds that hardly seem to make the hardware sweat according to the profilers. The only thing in the scene that’s somewhat demanding on the hardware according to the onboard monitors is VoxelGI.
I would expect the issue to go away if I exit the game, restart in windowed mode and play without resizing the game window and without using my frame scaling script or indeed FSR2 at all. But now I seem to be stuck with the sudden drops no matter what. Clearing the shader cache also didn’t help.
Weirdly, disabling and removing the addon halyard (3d rope simulation) made everything work fine, but only for a couple of runs, now everything is back to weird without having changed anything else in the project. Same with disabling / removing VoxelGI. All good afterwards, until…it isn’t any more ¯_(ツ)_/¯
This is really frustrating. I guess I’ll just have to start a new project and reimport and arrange everything piece by piece…
This reminds me of one last method, which you already seem to be doing, but I’d suggest doing it more.
And that’s the method of “disable/remove/comment everything, and then keep adding stuff back in until it breaks”. Or you can go the other way round - remove stuff piece by piece until it starts working.
This is, of course, complicated by the fact that the issue can’t be always reproduced - but with enough patience I think it would work.
Oh, and a final thought - have you ruled out the possibility that it’s some other software on your computer, and the slowdowns are just a coincidence? Like, keep Task Manager open and check for CPU/disk/memory usage of all running apps.
Which makes me also think about software like Discord/Steam/whatever which likes to try and detect running games and inject their overlays or something. Also a potential external source of lag.
Consider this a PSA, as I’m not sure its going to help you directly @Kalamster! I didn’t know about this for years, so wanted to mention it in the hopes of saving anyone reading this a lot of time!
If you are using git for version control, you can use git bisect to do this for you in a very efficient way.
Basically you mark a commit as “bad”, then checkout an older working version you can mark as “good”. Then git bisect will basically checkout a commit half way between for you. You test that commit and mark it as either “good” or “bad”. This process continues until the broken commit is found!
Tips:
If you’re not sure exactly what commit is “good” you can checkout a fairly old commit, as git bisect does a binary search meaning you’ll still narrow down the issue quickly.
Keep commits small and focused on a specific change. Otherwise even once you find the commit you’ll still have figure out the specific change.
What kind of hardware are you using? If the render requires more data than the VRAM capacity then the system will have to keep copying data every frame between RAM and VRAM and that would slow everything. As you are getting spikes im not sure what might be going on without more information including the scene setup etc.
Ive got a couple of projects where the frame rate is weird at first but it always settles down after a couple of seconds when all the scripts have finished loading assets, etc.
