Scene started crashing computer in play mode (out of memory) - Why does removing animators help?

[evelili]

Suddenly this weekend, a scene that used to run fine in Play mode will now, when it is loaded from another scene or directly entered by pressing play:

1. Load for a suspiciously long time
2. Eat up all my computer’s RAM (16GB + 12GB GPU I think?)
3. Crash my computer in a variety of different ways (due to the aforementioned lack of RAM)

I am using hundreds of 8192 max size textures (4840 x 3160 px) to animate different characters in a visual novel-style game. That’s a me problem. BUT, by using sprite atlases, all the characters could fit into and run in a WebGL build before.

Until this weekend, I could also run this scene in Unity with Clip Studio Paint, Discord, VSCode, Chrome, and other applications open in the background with no memory issues whatsoever. Now, even with just Unity running, this scene will crash my entire computer. Here’s a piece from one of the crash logs:

Could not allocate memory: System out of memory!
Trying to allocate: 61177600B with 16 alignment. MemoryLabel: Texture
Allocation happened at: Line:69 in C:\build\output\unity\unity\Runtime\Utilities\dynamic_array.h
Memory overview

[ ALLOC_TEMP_TLS ] used: 42312B | peak: 0B | reserved: 28606464B 
[ ALLOC_MEMORYPROFILER ] used: 1674576B | peak: 1884304B | reserved: 3145728B 
[ ALLOC_DEFAULT ] used: 391095964B | peak: 0B | reserved: 572387328B 
[ ALLOC_TEMP_JOB_1_FRAME ] used: 0B | peak: 0B | reserved: 2097152B 
[ ALLOC_TEMP_JOB_2_FRAMES ] used: 0B | peak: 0B | reserved: 2097152B 
[ ALLOC_TEMP_JOB_4_FRAMES (JobTemp) ] used: 0B | peak: 0B | reserved: 62914560B 
[ ALLOC_TEMP_JOB_ASYNC (Background) ] used: 329164B | peak: 0B | reserved: 18874368B 
[ ALLOC_GFX ] used: 25365523096B | peak: 0B | reserved: 25380798464B 
[ ALLOC_CACHEOBJECTS ] used: 89929484B | peak: 0B | reserved: 237682688B 
[ ALLOC_TYPETREE ] used: 63804800B | peak: 0B | reserved: 71303168B 
[ ALLOC_PROFILER ] used: 496552B | peak: 503016B | reserved: 16777216B 
[ ALLOC_PROFILER_EDITOR ] used: 0B | peak: 0B | reserved: 0B 


d3d11: failed to create 2D texture id=2881 width=4840 height=3160 mips=1 dxgifmt=28 [D3D error was 8007000e]
d3d11: failed to create 2D texture shader resource view id=2881 [D3D error was 80070057]
d3d11: Failed to create 2D texture in GfxDeviceD3D11
Crash!!!

There is +25GB used in ALLOC_GFX… I don’t know what that means but that number seems too high!

Recently, I added a new system to the game that involved about 300 more images being added (these ones fit into an atlas only ~2.6MB). The session that I added these images, 2026-01-11, everything in the editor ran fine. But when I opened the project again on 2026-01-16, with no changes made to the scene, it now runs out of memory on play every time.

To troubleshoot, I tried:

1. Deleting the new system scripts / GameObjects from the scene
2. Checking Windows updates → none occurred between the two sessions
3. Updating my graphics card (RTX 3060)
4. Deleting the project library and reimporting (it’s still almost 80GB…)
5. Deleting unused assets from the project
6. Uninstalling and reinstalling my Unity editor
7. Running the Windows memory diagnostic tool (no issues found)

None of the above worked. Finally, after fiddling with the scene, the only thing that got it to run again was removing nearly all the character animators from the scene. This confuses me, since I haven’t touched the character animators in months.

So. Each character has their own animator / animator controller with unique animation clips + a corresponding sprite atlas for their images. Characters have 15+ layers of UI Images, to create a “sandwich” of the character (head, eyes, mouth, body, etc); they each have 100s of frames, but most of these frames are empty space.

Every frame is imported at the largest size with no compression, and then crunch compressed in the atlas (otherwise, I experienced colour variation flickers).

Each non-main character is a group of UI Images that lives in a shared GameObject (“sprite”) in a Canvas (“_prerender_sprite”) like this:

The main character lives on a different canvas, but follows the same structure. Up to 2 characters can display at a time (the main character + 1 other character), but the non-main characters frequently swap in and out. I also added up all the sizes of the character sprite atlases and got only 54.9 MB (but, maybe this is meaningless if the sprites get decompressed).

I tried to use the profiling tool, first with the main character animator + 1 non-main character animator, and then just the main character animator. If I’m reading the results right, it seems that the difference between having 2 characters vs 1 character in the scene is 1.34GB of textures?

But I have no idea what would be causing that number. The uncompressed images used in the removed animator’s animation clips total to 58.3MB texture * 94 = 5.48GB, which is too large. But those images also pack into 1 page of a sprite atlas and are < 4MB compressed.

My questions therefore are:

• Why did my scene run fine one day, and then the next day was completely broken, when nothing changed?
  • And why would it still be broken after removing the newest additions (that DID work at the time they were added)?
• Why did removing Animators make a difference in memory?
  • Does that mean an Animator is loading every texture associated with its animation clips into memory at the start of a scene?
  • But why would one character be a difference of 1.34GB, when the associated Sprite Atlas is only a few megabytes? Where did this number come from?
  • And if the atlases get decompressed in memory to be gigabytes large, why could my computer / WebGL handle 15 different characters before?
• Is there a better way to handle multiple animated characters that can swap out frequently?
  • Would instantiating / destroying a prefab every time a character appears / disappears be any better in terms of memory? Worse in terms of performance?
• Could there be something else causing the crashes that I’ve overlooked?

Thank you very much for reading all this yapping, and for any advice / help you can provide ^^

[Venkify]

@evelili

• Why did removing Animators make a difference in memory?
• Does that mean an Animator is loading every texture associated with its animation clips into memory at the start of a scene?
• But why would one character be a difference of 1.34GB, when the associated Sprite Atlas is only a few megabytes? Where did this number come from?
• And if the atlases get decompressed in memory to be gigabytes large, why could my computer / WebGL handle 15 different characters before?
• Is there a better way to handle multiple animated characters that can swap out frequently?
• Would instantiating / destroying a prefab every time a character appears / disappears be any better in terms of memory? Worse in terms of performance?

Using SpriteAtlas with Crunched DXT seems to be a good option for the Web.
The allocated memory does seem strange.

1. Are all the textures being packed into a single Atlas ?
2. Even though they are empty spaces, they still consume memory in terms of imported textures. In the Editor, there are cases where both the original textures and the Sprite Atlas texture are active at the same time (like during packing). Especially if all textures are part of a Single Atlas, this requires all textures to be loaded which may result in massive memory allocated both in System and GPU. Could you please try to split to multiple Atlases and see if this resolves the issue?

If the issue still persist, could you klndly submit a bug report with a repro project please? Will take a look asap. Sorry for the inconvenience caused.

[evelili]

hiya, thanks for the response ^^ all the characters are already in separate atlases, yes.

im going to be away from my pc for a bit, but ill try to submit a bug report when i get back!

[CodeSmile]

@evelili

all the characters could fit into and run in a WebGL build before.

I wonder how long it takes to load that game in a browser, through an “average” connection? Have you and are you frequently testing this with browser caches cleared so you feel the complete delay of the initial download? If you intend to support it: are you playtesting on mobile as well? The mobile browsers are much more restricted to the point where iOS Safari often crashes if a tab exceeds 500 MB memory usage.

Hundreds of 8k textures, 80 GB total project size on disk … that doesn’t sound like a project that would be well suited as a web build.

[evelili]

oh, hello again yeah those are valid concerns! but, ive run dozens of playtests at this point on a variety of computers, and even a decade old laptop without a dedicated graphics card could run the game (when it was in a far less optimized state too!), even if it took a bit longer to load at the start.

the webgl build is meant to be a demo for the full game anyways, im just waiting on background assets + working on other systems in the meantime. mobile is not supported, since it’s played purely with the keyboard, so i don’t need to worry about that.

my previous working build had a zip file of 101mb, and took 1.1GB in the browser tab, which is quite large but not unmanageable. im a bit surprised the library folder for the project is 80GB, given my original art assets are nowhere near that size, but im assuming it’s due to the imported textures taking 58MB in unity instead of their original size…?

but yeah, worst case scenario if i cant get the scene working, ill take this as an opportunity to clean up some old code and rebuild the scene again ^^

[CodeSmile]

@evelili

im a bit surprised the library folder for the project is 80GB, given my original art assets are nowhere near that size, but im assuming it’s due to the imported textures taking 58MB in unity instead of their original size…?

Yes, I believe for editing speed the texture is cached as uncompressed RGBA32.

Unity also keeps every already-processed version of an asset, meaning if you switch between PC, web, iOS and Android build platforms, you get the artifacts for each residing under the /Library folder. This improves platform switching time. It’s not unusual for the Library to contain upwards of 80% of the project’s overall size.

[evelili]

A brief update, because now I am even more confused.

My project is currently saved in the “animators removed” state. Somehow, I’ve discovered that if I enter and exit Play mode 3 times, on the third time, my memory usage goes back to normal. Like, literally do nothing in the project, just enter and exit play mode 3 times, and the memory fixes itself!

But then, if I close the project and reopen it, it returns to its glitched unidentifiable-massive-textures-take-all-your-memory state.

Here are some screenshots from the profiler to show you what I mean. First time entering play mode:

Second time entering play mode:

Third time entering play mode:

The textures suddenly drop from 4.06GB to 1.98GB for no apparent reason…

Furthermore, once it is in this state, I can add all the animators back in, and it only increases the textures up to 1.99GB:

But then, because the state doesn’t persist after closing and reopening the editor, the next time I open the file I have to remove all the animators, run 3 times, and add them back So this isn’t a feasible workaround unfortunately.

I also remembered that, in my last “normal” session (2026-01-11), I tried to use the Profiler window for the first time, but got a “The system is running out of memory” error in the console, so I just closed the profiler window and went on with my day. So now I am suspicious that incident is related to my scene suddenly running out of memory as well.

Any ideas on what could be causing this?

[CodeSmile]

Have you tried deleting the /Library folder yet?

Can you backtrack via source control what has changed between the last successful run and the start of the issues?

The out of memory aspect may be compounded by whatever the editor is doing. There’s always some “flux” in that, so perhaps you have been running close to the threshold and now you’re just within the threshold and under various situations run into those issues.

Worth noting: the initial log shows that dx11 (the GPU) ran out of memory. I’m curious if you change the resolution of the game view to something low (1366x768) whether that helps (smaller framebuffer size). And of course not having both scene and game view visible at the same time (2x rendering cost).

Note that even compressed textures may have to be decompressed into VRAM depending on the compression format and/or platform.

Lastly, 16 GB memory is pretty constraining for development so perhaps consider upgrading RAM to 32 GB.

[evelili]

I’ve redone the library twice, once by deleting the folder and once through “Reimport all”, but with no change.

There was no change in source control when this started happening, it is purely on Unity’s end → I’ve reverted to repository states before then and it still occurs.

I don’t think my memory could have been THAT close to the threshold? Because when it runs properly after entering play mode 3 times, task manager has it hovering around ~40-50% RAM, even during the “entering play mode” loading dialogue. But in the bugged state it immediately shoots up to 50%, 65%, 80%, 95%, etc, in a few seconds, and I know I have to end the task before it crashes my computer.

I also only ever run the game view or the scene view at one time (actually, I didn’t even know you could do both at once until now lol…)

More RAM would be nice, but unfortunately is out of my price range for the time being

In comparing the logs between the “going to crash” and “stripped down” versions, the “going to crash” ones always stop logging at the red line here (assuming this is where they hang and start eating memory, and then I have to kill the program). Apologies for the phone picture haha:

I also noticed the “stripped down” logs start using the Temp/__Backupscenes path sometimes, does that mean anything? Why does it seem like it loads the scene twice, and also has to unload unused files?

Thank you so much for your continued help, I really appreciate it

[CodeSmile]

@evelili

But in the bugged state it immediately shoots up to 50%, 65%, 80%, 95%, etc, in a few seconds

Sounds like a memory leak. This happens during playmode, right? You could check with the (Memory) Profiler when that happens while there is still time … exit playmode right thereafter and hope.

It might be your own scripts doing something nasty, it’s really easy to accidentally write code that consumes more and more memory.

Do you have any “editor” code in an OnValidate method? That quick 'n dirty hack to do things like accessing AssetDatabase can really badly bite back, given that OnValidate runs multiple times per editor update for the selected object’s scripts. Practically just moving the mouse over the Inspector has it run dozens to hundreds of times.

But just regular runtime code can do this in so many ways.

Oh and if you’re not on 2021.3.45f2 do update, not just on the slim chance this is an actual bug that’s already fixed but because of the high-risk security issue that has been fixed. Digital stores are blocking Unity builds without that fix.

[evelili]

Ah, I can’t even enter play mode in the crash case, it gets stuck on a “hang on…” dialog. It’s a little confusing what’s happening, so I’ll clarify:

1. Full project → can’t enter play mode at all, memory grows out of control until I either force quit or my PC crashes
2. Project with animators removed → can enter play mode with bad memory use. On the third time entering play mode, the memory use goes back to normal
3. Adding the animators to project 2 after running 3 times, turning it into project 1 → runs normally, BUT only until the editor is closed

So my “full project” can run fine if I do the whole remove animators → run 3 times → add animators back process. Which is so weird!!!

But I can’t profile play mode to see what’s causing the leak in case 1 because Unity hangs before entering play mode and I have to force quit.

I haven’t made any modifications to the editor I don’t think? But maybe a plugin I use could have done that, I’d have to check → though I haven’t modified these, so not sure why something would change.

And yeah I’m on the CVE fixed version

[evelili]

After banging my head against a wall for a week, I have finally found a solution

Basically, the first time that I would run this scene in the Editor, two things were happening:

1. I had some unused playables added to a playable director that I’d forgotten to remove. For some reason, even though the 5 images referenced in those playables were a) used in other playables, and b) compressed in sprite atlases, Unity was loading those 5 images uncompressed and at twice their size
2. Any animator on an inactive gameobject in the scene was loading in every single individual image referenced in its clips uncompressed (and also way larger than if the sprite sheets had been used).

Removing all my character animators actually wasn’t addressing the root problem, it was just reducing the initial memory bloat to a small enough amount that the game could actually run. Which looked like this:

The first 5 here are the ones in the unused playables, and the rest are images used in animation clips. And, since this image is without any of the character animators; once you factor in an additional 58.3MB x 100s of frames…

However, whatever excess memory use the Editor was doing on the first run wouldn’t happen on subsequent runs → on the second run, the “simple” summary would be large but the detailed summary would be small, and on the third run they would finally line up. Eg, in one of my sessions the profiler data looked like this:

RUN 1:
Graphics & Graphics Driver: 1.62GB / Objects stats - Textures: 2.84GB / Texture2D: 2.06GB
RUN 2:
Graphics & Graphics Driver: 1.66GB / Objects stats - Textures: 2.88GB / Texture2D: 49.0MB
RUN 3:
Graphics & Graphics Driver: 87.7MB / Objects stats - Textures: 0.84GB / Texture2D: 49.0MB

I am not sure if there is some kind of different loading process for the first time you enter play mode vs subsequent times, but it made it really tricky to pinpoint what was going on!

The solution I found is that instead of setting GameObjects with animators to inactive in the scene view, I need to leave them active, and then set them inactive through Start() in various scripts. This gives me a nice and normal memory profile that looks like this:

I have no idea if this behaviour was happening all along, or if it’s some kind of bug that randomly decided to strike me down, but I can at least rest easy now that my game runs without crashing my whole PC