❓ Help VRAM leak causing heavy stuttering after extended sessions (1 Viewer)

[0x017c41]

Hi dear Palworld enthusiasts!

I have a problem with the game for which I hope to get help with or have it get heard by the devs. Playing the game normally, after about 60-90 minutes of session time, my VRAM fills up, and the game starts to stutter heavily due to most likely paging to system RAM. The only solution I found to combat this issue is to closely monitor my VRAM usage and completely restart the game when I see it fill up to max (12GB in my case).

I tried to troubleshoot the issue using various LLMs, but to no avail. Some recommendations they gave are engine.ini edits, which are the following:

[SystemSettings]
r.Streaming.PoolSize=8192
r.Streaming.LimitPoolSizeToVRAM=1
r.Streaming.HLODStrategy=2
r.bForceCPUAccessToGPUSkinVerts=True
r.GTSyncType=1
s.AsyncLoadingThreadEnabled=1
s.AsyncPipelineCompilation=1
r.CreateShadersOnLoad=1
niagara.CreateShadersOnLoad=1
r.Streaming.DefragDynamicBounds=1
r.Streaming.AmortizeCPUWork=1
r.Streaming.MaxNumQueuedChunksPerBatch=2

[/Script/Engine.RendererSettings]
r.OneFrameThreadLag=1
r.Streaming.PoolSize=8192
r.Streaming.LimitPoolSizeToVRAM=1
r.DefaultFeature.MotionBlur=0
r.DepthOfFieldQuality=0
r.SceneColorFringeQuality=0
r.Tonemapper.Quality=1
r.Streaming.DefragDynamicBounds=1
r.Streaming.AmortizeCPUWork=1
r.Streaming.MaxNumQueuedChunksPerBatch=2

[/Script/Engine.Player]
ConfiguredInternetSpeed=104857600
ConfiguredLanSpeed=104857600

[/Script/OnlineSubsystemUtils.IpNetDriver]
MaxClientRate=104857600
MaxInternetClientRate=104857600
NetServerMaxTickRate=120

I tried playing with different r.Streaming.PoolSize values and found that with my system I get the longest stable session time with the set value above. I also have all ingame graphics settings set to high or lower and have frame generation turned off, as I experienced better 1% lows without it. I did reset my nvidia cache as well.

I'm thankful for any advice or solutions in advance.

My exact system specs: 7800x3d, 4070Ti, 32GB sys RAM, Windows 11 (game is installed on a gen 5 nvme SSD)

 

[0x017c41]

Important disclaimer: I'm not a game-dev by trade. I learned web development and am but a hobbyist when it comes to game development. A good portion of the insight from the data I gathered was done by LLMs, not by me alone, as I don't actually know fully how UE4 works and have near zero experience with it. In general, I have but little experience when it comes to how game engines work, as most of my experience and knowledge stems from enterprise web front and backend development. I make small Ren'Py games as a hobby.

After many hours of testing and troubleshooting, I came to a number of conclusions I would like to share with the community here, out of all places, as I don't know where best to turn to. (I don't like Reddit, and the Discord is not suited for such a lengthy analysis).

TLDR: I made a number of wrong assumptions starting off about the nature of this issue. I came to learn that there is actually a VRAM leak that is not caused by erroneous settings or UE4 but in actuality is caused by Palworld itself. Following the last couple of days, I used many LLMs and different sources to put together a debugging framework to see and test what is actually causing the memory leak without having to reverse-engineer the engine itself.

Symptom​

So, my original observation was that on long sessions (60-90 minutes), VRAM usage kept climbing steadily until it exceeded the GPU's budget and started paging into system RAM, causing heavy and persistent stutters in the game, even just moving the camera around.

What got ruled out​

Streaming pool misconfiguration. Setting r.Streaming.PoolSize/r.Streaming.LimitPoolSizeToVRAM to correct system-specific values did not prevent the growth of VRAM usage as it kept persistently spilling over bounded pool values.

A hard, unrecoverable leak. Returning to the main menu (full world teardown) reliably reclaims essentially all the accumulated VRAM and resets live object counts back to near-baseline. The engine can QED release everything. The failure is specifically that it doesn't during normal play. This points at an eviction/streaming policy issue, not orphaned references the garbage collector can never reach.

What was found out​

VRAM growth correlates with region transitions, not moment-to-moment play. Testing with an external VRAM monitor (HWiNFO64) alongside in-session live object-count snapshots (via UE4SS's FindAllOf that sampled Texture2D, StaticMesh, SkeletalMesh, NiagaraSystem/NiagaraComponent, MaterialInstanceDynamic, and related classes) showed the largest jumps in VRAM usage occurred immediately following fast travel or long-distance flight between regions (using high-speed mount Pals). Normal exploration within an already-loaded area caused a much slower, steady creep by comparison. None of these increases were recovered by moving away from the newly-loaded area, even after several minutes.

Object counts decouple from VRAM usage in extended sessions. In a clean test window (roughly 15 minutes late in a session), VRAM usage continued to climb while every tracked UObject class's count either fell or held flat over the same window. This means the tail-end growth is not explained by more objects existing. It's more consistent with either resident GPU byte size of existing objects (e.g. mip levels/streamed texture data) not being trimmed back down even as object counts stay flat or fall, or a GPU memory consumer outside the sampled UObject classes (render targets, physics/cloth buffers, shader/PSO cache growth, etc.) that mere .lua object counting cannot see.

Forcing a UObject garbage collection pass (obj gc) showed no clear, repeatable benefit. If the issue were objects lacking references, a forced GC pass should reliably shrink counts. It largely didn't. This further supports that resident GPU data is not getting evicted through the normal streaming path, rather than objects not getting dereferenced.

What Claude thinks​

Whatever normally triggers eviction of streamed-in texture/mesh data for regions the player has left isn't firing reliably during normal play - particularly not around fast travel transitions, where the destination's content is loaded but the origin's doesn't appear to be evicted on the same timescale. Only a full level/world teardown (main menu) reliably triggers the eviction path that should be happening continuously in a properly functioning open-world streaming setup.

What Claude suggested as areas to investigate​

• World partition/streaming source unload logic specifically around fast-travel and long-distance teleport functions, since growth clustered tightly around these events in testing.
• Any cache, pool, or manager class that might be retaining texture or mesh references across streaming cell boundaries longer than intended (a "keep loaded a bit longer for smoothness" grace period that never actually expires, for example).
• Whether r.Streaming.PoolSize enforcement is being bypassed or delayed somewhere in the pipeline, given that VRAM usage exceeded a correctly configured, VRAM-locked pool in testing.

What I cooked up as a temporary half-solution​

VRAM Leak Mitigator. Hopefully a very temporary and unfortunately only half-solution to this problem that during several tests showed roughly 20-25% decrease in VRAM growth compared to baseline. The mod actually got posted to the workshop with the built-in debugging tools untouched, so it will still print an object count snapshot to the UE4SS console log via pressing the F6 and F7 keys. (F6 - object-counts w/o GC, F7 - object-counts after GC)

What I hope to achieve with these findings​

As a best-case scenario, I hope this somehow gets seen by the devs and they learn to appreciate how serious this issue is and it gets patched timely. As a worst case, if the issue stays for a long time, hopefully someone who has the time and the know-how to reverse-engineer their streaming manager and create deep hooks via C++ modding to either further mitigate or, as maybe an overly optimistic scenario, completely eliminate the issue.

In either case,
peace