Very strange framerate bug when looking NNE from starting area.
hunnersaginger
United Kingdom Join Date: 2018-01-27 Member: 235939Members
United Kingdom Join Date: 2018-01-27 Member: 235939Members
I first noticed FPS drops when running around my base. At first I thought it was the windows causing more stuff to render, but then noticed it happened even when staring at a blank wall. Eventually realised it was direction based.
The readings above were taken from inside the starting lifepod (-142, 5.8, -385.7). I also got the same readings standing on top of the pod, and in the sea directly below it. Facing any direction between NNW and ENE tanks my FPS. My base is a short distance west of the lifepod. I edged the screen along pixel by pixel from the west and then from the east. This indicated that the issue was caused by something exactly NNE.
I also discovered this behaviour only occurs within a certain area, a square bound by -320 to -509 north/south and -191 to -2 west/east. The moment I leave this square my fps shoots back up to normal. There is a hard boundary between normal and low fps. Deleting my entire cellscache folder returned my FPS to normal. This is at 1920x1080 on high presets. GTX1060 6GB, 6600K, SSD, all latest drivers.
Someone on reddit had the same issue and said they'd noticed their GPU load dropping when the FPS dropped. I tested and found the same, my GPU load dropping from 100% to around 30%.
Bit more detail on my reddit thread here: https://reddit.com/r/subnautica/comments/7t5b2f/massive_fps_drop_when_looking_in_certain/?st=jd4zxeu6&sh=88a2c0b7
The readings above were taken from inside the starting lifepod (-142, 5.8, -385.7). I also got the same readings standing on top of the pod, and in the sea directly below it. Facing any direction between NNW and ENE tanks my FPS. My base is a short distance west of the lifepod. I edged the screen along pixel by pixel from the west and then from the east. This indicated that the issue was caused by something exactly NNE.
I also discovered this behaviour only occurs within a certain area, a square bound by -320 to -509 north/south and -191 to -2 west/east. The moment I leave this square my fps shoots back up to normal. There is a hard boundary between normal and low fps. Deleting my entire cellscache folder returned my FPS to normal. This is at 1920x1080 on high presets. GTX1060 6GB, 6600K, SSD, all latest drivers.
Someone on reddit had the same issue and said they'd noticed their GPU load dropping when the FPS dropped. I tested and found the same, my GPU load dropping from 100% to around 30%.
Bit more detail on my reddit thread here: https://reddit.com/r/subnautica/comments/7t5b2f/massive_fps_drop_when_looking_in_certain/?st=jd4zxeu6&sh=88a2c0b7
Comments
I had the exact same issue and setting the launch parameters to "-window-mode exclusive" fixed it for me
Ah fair enough.
The problem I had had similar symptoms: Crazy frame rate drops and low GPU usage when looking in specific directions. Alt + tab fixed mine though, albeit temporarily. I thought it could be some sort of memory issue to do with borderless window mode, like looking in certain directions was rendering too much or something? No idea, never did find out.
I've built my bases in completely different locations in every game but after having played for a few hours i get the same problem and the framerate always drops when looking in the direction of my base from any point on the map.
It's not the base itself that is the problem, but an area near it. I've built all bases at the edge of different kelp forests and while I've never been able to pin-point a specific spot, it's always somewhere in the kelp behind the base. My own conclusion is that the game actively tracks or renders something in the base cell/area when you look at it. If that's the case and you have Stalkers constantly piling metal salvage/dropping new teeth behind the base it would eventually bog down the system.
I assume you deleting your cell cache would remove all the stalker teeth if you have a kelp forest in the direction of your 'bad area' and fix the problem for a while so the question is if you have a kelp forest there or not.
Edit: So i tested a new game with a base away from the kelp but the problem still occurs and now it sems related to the scanner room. The framerate drops with the scanner room up and it's a GPU problem, my CPU is only at 50%.
What's weird is that if i remove the scanner room, the framerate still goes down when looking at the spot where it used to be but ONLY if i look at it from a certain direction; From the North. If i pass the point where the scanner room was, the framerate goes up again. Building something else in the same spot doesn't change anything.
The base was built in the irradiated part of the safe shallows within view distance of the grassy plateaus.
So it seems like the game keeps rendering 'invisible' objects but only one side of them? I don't know, this is just getting weirder. I get this in every new game though so i hope it gets fixed.
Some were saying GPU usage dropped when lag spikes occurred. What happens to CPU usage? Do they both drop, or does CPU usage max (meaning the game becomes CPU bound)?
@0x6A7232 Just tested this. CPU drops (75% -> 53%) at the same time. Just for the purposes of clarity, it's not a lag spike. If I'm in the affected area and looking NNE, my FPS is a steady 25-30, with associated GPU and CPU usage drops. It stays that way until I look away from NNE or leave the area.
https://imgur.com/a/iaRgt
Note the coordinates do not seem to correspond to yours.
But the first 2 images show the fps deadzone where I have 15fps.
It starts in-between SE and S ends in-between SW to W.
Outside this dead zone my fps goes back to 75fps+.
I did not move the seamoth.. I just rotated the camera.
Harder to see and capture at the exact moment, so bare with me here.. but you can see CPU usage on both core 6 and core 8 drop significantly while going into this FPS deadzone.
I noticed when im in the 75fps+ part that the threads from SN on these cores are the top 2 threads, according to the threads menu. (Which is as accurate as I can make it with only MS symbols set.)
I have no clue what those threads do, if its a world or graphics thread.
But if I stay in the 75fps+ part for a prolonged time, they both stay in good CPU usage. The moment I go into the 15fps part, both those cores drop in usage.
Im assuming (due to the preferred cores part) that those threads run on those cores.)
I did all testing in the same spot. (aka I saved my game in the bad spot I found.)
* No graphic setting in terms of quality does anything. So a GPU cap is unlikely. (It already was as im more CPU bound but meh)
* Using the F1 menu and cycling through every option does nothing. Hell, you can remove the entire world minus the entities and it doesn't change the fps.
* Lowering FOV to minimum reduces the area of the fps dead zone, it does not remove it. Increasing FOV increases the zone. The 'increase/decrease' is for camera rotating ONLY.
* The fps deadzone does not increase or decrease by any setting I can find in terms of moving coordinates. Aka, you move your actual self forward/backwards/up/down/whatever and the deadzone disappears. (Its still there if you go back to initial coordinates.)
* Rotating around the coordinates of the fps deadzone gives no issues with fps whatsoever. This counts for both rotating around it while having eyes towards it or your back towards it. That seems to help exclude rendering difficulty in terms of amount on screen. (Not that that seemed to be a issue anyway as the deadzone happens in a area which is really not that graphic intense from the looks of it.)
* Not having the ram to RAMdrive SN fully, I tried partial RAMdrive again. Putting both its temp data and its whole StreamingAssets on ramdrive does nothing for this fps deadzone. I had a look with procmon and pretty much put everything which was referred often from drive into the ramdrive.. No change.
* While I say CPU bound, its not doing much either.. Everything tanks on these deadzones.. Far less CPU usage, GPU usage, drive usage seems unchanged also.. (aka not a increase, and like I said.. ramdrive.)
Unless there are debug menus or debug commands im unaware of, im running out ideas to test and ways to gather data.
It doesnt seem to hit any limit in the system anywhere. I had high hopes that it was a nvidia driver bug with gsync, but their latest driver didnt help that much either.
Additional very weird thing.
In a rare moment during testing, the fps deadzone just disappeared. At first I thought a Stalker pushed me out of it, but it was gone. This happened after I used the reload settings options in the F1 menu. But reloading the save (and thus having my deadzone spot back) and trying again did not produce the same result.
It could have been something else, but I havent been able to find out what happened.
There are still people chipping in over on my reddit thread. One user, 'Wh00renzone' posted a screenshot showing massive drawcall spikes for 'xGeyser_Eruption(clone)' and 'xGeyser_Warning(clone)' which seemed to coincide with the slowdown.
I tested and found the same spikes, although Wh00renzone reported that clicking 'estimate terrain occluded' resolved the slowdown whereas it did not for me.
My goodness - so there was a way to enable exclusive fullscreen mode all that time!
Is this a common Windows command? Does it work on other Steam/Windows games?
Also, big thanks for the tip : )
And now I know again.
Im better at NS2 performance.
Anyway, back to information!
F3 menu settings did a whole lot of nothing in terms of performance. The framegraph showed exactly what the steam fps counter (and my monitor hz counter if I use gsync) shows.
Odd thing, at some reloads I had a sort of weird heartbeat lowfps spike when in normal fps, but I could not reproduce.
ShaderLOD is acting weird.. I see normal numbers like 400, and numbers going into utter massive counts like 2147483647. On some runs it was.. negative?
But no performance change regardless of this setting. Not in the good fps or the bad deadzone fps.
So was this test round a total bust? NO!
'Collect Est. Call Stats' was not my friend as pressing the shiny button did not seem to refresh. Many reloads were done.
But in the fps deadzone I also had the massive 16492 calls, 589 insts, 28 dc/inst for 'xGeyser_Eruption(Clone)'.
With a nice complementary 11780 calls, 589 insts, 20 dc/inst for 'xGeyser_Warning(Clone'. The post made previously by @hunnersaginger made me remember that this menu seems to be top top bottom in terms of ms used.
I know in that very very broad general direction is a geyser.. somewhere.. but come on.. thats such a long distance away. But thankfully this fps deadzone is right next to my base which is 'behind' me.. sitting next to... a geyser.
Lets turn around and go into it with my seamoth and take readouts of ya know, a actual SN geyser.
But where is it? Aaah, its not in the top.
26 calls, 1 insts, 26 dc/inst for 'xGeyser_Eruption(Clone)' and
20 calls, 1 insts, 20 dc/insts for 'xGeyser_Warning(Clone)'.
Now that looks more reasonable. So lets blame the geyser thing.
Also this made me realise another thing about this menu..
Its total calls, numbers of instance with 1 being one geyser, for 26 calls per geyser.
Lets continue that theory with the fps deadzone.
589 instances each worth 28 equals to 16492 calls.
And 589 instances each worth 20 equals to 11780 calls.
Which means the game is trying to process 589 geyser instances? Wait wut?
Either my theory has a big hole or something is wrong.. Its like 1 geyser in a real geyser spot vs 589? There are no 589 geysers in the safe shallows.
Is it trying to render every geyser in the game?
https://imgur.com/BrCGlpx
Regarding the 'Collect Est. Call Stats' button, I also found that after 3-4 clicks while testing, it no longer updates. Another bug perhaps!
Guess its time now to wait till UWE is back from vacation and see what they say about it.
I've noticed two potential fixes, although they come with their own side effects.
#1 F1 > Other > set [batch load rings] to 0
With this, the batches start being unloaded. Eventually the problem batch gets cleared and my framerate shoots up. If I set [batch load rings] back to 2 (the default), the batches come back. Unfortunately, the batches don't appear to come back in the same order so I'll often still have large parts of the game world near me not present.
#2: F1 > Other > "Hide All Ent Gfx"
This hides a number of effects (for example, the effects associated with a heat vent), but my framerate shoots back up again.
Hopefully this helps pinpoint the issue.
I've been reluctant to delete it since I don't want to ruin the experience for myself (searching for bug troubleshooting while avoiding spoilers has been quite the task), but I'm thinking an improved framerate may be a better experience than constant dips to the 20s.
I deleted it for testing purposes but reverted to my backup afterwards. My assumption is that even if I hadn't reverted, the problem would have reared its head again.
The severe (down to 7 or 8 fps) drop occurs when a distant occluded point comes on screen up and to the north east. My guess is that some distant area/object near the surface is being rendered erroneously.
It is very difficult to play in my base, but I do not want to delete the cache because I assume it will deactivate the arches I have activated. If anyone has a more surgical method for fixing this I could try, I would greatly appreciate it.
Interesting..... I have noticed that looking at geyser eruptions can cause massive frame rate drops. My base is also right next to geysers (jelly shroom cave). However my fps drops occur consistently when I look to the north east. Looking at a map, that would line up with a bunch of geysers in the mountains biome. Maybe there is some sort of geyser script problem?