Lightmap Baking Out of Memory

Unity Engine
1

Unity has been incredibly unstable for me the last few weeks. This is on three different machines (all running Mavericks) - a Mid-2012 Retina MacBook Pro, a Mid-2010 Mac Pro, and a Late-2013 Mac Pro with 16, 32, and 64 gigs of RAM respectively. The first has Intel discrete graphics and an Nvidia mobile GPU, the latter two both have ATI GPUs (ATI Radeon 5870 in the Mid-2010, and dual ATI FirePro D700s in the late 2013).

Switching platforms or pulling a new version from repo triggers an import that takes a long time. It’s a relatively large project, but not large enough to justify the sheer length of this (often 45 minutes or an hour even on the new Mac Pro, even longer on the other two). That was a limitation I could live with, but for the last few weeks, the projects have been crashing a lot during this process and when they crash, the project then usually continues to crash on open.

I am able to get around this problem with a fresh repository pull and reducing all textures to half size (4k maps became 2k, 2k became 1k, etc.) That’s not a long term solution, but at least it allowed me to open the project. Even once the project is open, Unity has been very prone to crashing, but I’m at least able to work.

But now, I’m really stuck because I can’t do a light bake without getting a fatal out of memory error. The error happens in Unity when it goes to import the light maps, not in Beast.

The error I get, both with the texture import and with

1/25/14 12:48:20.292 PM Unity[54389]: Unity(54389,0xa0fc91a8) malloc: *** mach_vm_map(size=218103808) failed (error code=3)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug

Despite the errors, Unity’s heap never goes above 2.7Gb and the machine hasn’t used a single byte of swap. Activity Monitor shows no memory pressure at all.

I’m pulling my hair out. I’ve got a presentation involving this project next week and I’ve spent the last week and a half at an absolute standstill. I’m staring down a presentation I can’t prepare for. Since this is an iOS project, it relies heavily on light maps, so going with realtime lighting isn’t an option, and I haven’t gotten any response yet from my bug reports.

If anyone has any idea how I might be able to work around this and get my light maps baked, I’d be tremendously appreciative. I’m quite literally almost ready to ditch Unity and throw away months of work because of just how horrible the last few weeks have been.

2

http://forum.unity3d.com/threads/200861-resources-assets-gt-2GB

3

That’s interesting and there’s a lot of good information there, but I don’t think it’s the same problem. My assets are not over 2GB, and I’m on a Mac using 64-bit application, so I should have access to the full physical memory.

4

Maybe try checking “Compress textures when importing” in the preferences menu.

5

It is checked. :frowning:

6

Just another update. I applied the 10.9.2 update from Apple, which supposedly has some graphic driver fixes. The problems are not gone. Before, I could export to beast and it ran out of memory trying to import the light maps. Now, it gets a fatal memory error just trying to export to Beast.

7

And another update - I tried to bake again, and this time it exported successfully but crashed on import back into Unity. I’m no longer seeing the VM_ALLOC line in the crash logs, and when I crash, I get

1497054--84030--$fpEFxu94.png
1497054--84030--$fpEFxu94.png534Ă—564 45.3 KB

I don’t know if it’s related, but I am seeing something new:
1/25/14 3:03:14.715 PM spindump[33650]: Unity [32993] didn’t gather any samples due to audio running

and

1/25/14 4:16:19.000 PM kernel[0]: process Unity[37427] thread 453648 caught burning CPU!; EXC_RESOURCE supressed due to audio playback

1 Like
8

I am having the exact same problem with the same computer.

Let me know if anyone finds a workaround.

9

I have a workaround, but it’s horrible. For some reason, texture imports get memory allocation errors once the Unity heap gets up to about 2.7Gb. In theory, a 32-bit app should get 4 Gbs, so I don’t know why 2.7Gb is the magic number rather than 4Gb (or, for that matter, why in 2014 Unity is still 32-bit!), but there it is. It might have something to do with cross-platform compatibility with Windows, but for whatever reason, I have to keep my application heap around half a gig below that 2.7 GB limit in order to do a light bake.

The textures seem to take up considerable (inordinate) amount of memory even if you reduce the size of the textures in the import properties. So, the solution for me is to reduce my textures in the source files. I have two shell scripts. One shell script uses ImageMagick’s mogrify to reduce all the texture maps to 50% size. The other copies the full size images back to the project from the art source directory.

I run the first one, then go into Unity, let it import the reduced textures, which reduces the heap size (sometimes, I restart Unity after the import is complete, but I’m not sure that’s necessary). Then I burn the light maps. When it’s done and has re-imported the lighmaps, I then run the other script to copy the full-size textures back into the project from the art source directory.

It’s a horrible, hacky solution, but it’s letting me get my work done. The lightmaps don’t seem to suffer for using the reduced size images while the lightmaps bake.