So we’ve made a demo for a game idea and the project and resulting build were about 500mb. Then we added a movie texture that was about 4mb to the project and made another build. But now the project is over 2GB and the build is almost 1GB.
Now, granted, we’re new to Unity and 3d gaming. So we’re not using any optimized files or anything. But still none of our file sizes seem to warrant this enormous project/build size. (The only large assets are one 12mb and one 4mb movie textures.) And i’m not sure what happened between the first build and the second one. Wondering if some imported but later discarded textures are still lingering around somewhere…?
Noticing that the largest culprits in the project are a folder called ‘Temp’ (1.3GB) inside the project folder, and a folder called ‘cache’ (1.1GB) inside the ‘Library’ folder. Temp has a bunch of files called ‘tempFile’, some other files, and a folder called ‘BuildingPlayer’ The ‘cache’ folder has a billion (ok 217) subfolders that each contain several files with cryptic names like ‘3c203950ad115faad0002a99a5a9c239’.
So my questions are:
-
What are these files? And why are they so huge?
-
Are they necessary? Can I get rid of some or all of them?
-
Or is there a way to purge things that are no longer used but may be lingering in these temp or cache folders. (Something along the lines of Director’s ‘Save and Compact’)?
-
Any general tips for optimizing games and keeping them to a manageable size would be most appreciated.
Thanx!
d
The problem isn’t really the Temp folder as such, it’s the way you’re handling movies.
Importing movies results in one separate texture for each frame. The frames are uncompressed from the movie and presumably stored either decompressed or in DXT format. In either case, the result will be a lot bigger than the original movies.
The short answer is that you really don’t want to use large movies as textures right now. Short clips are probably OK (for animated particles, for example), but anything much larger will fill your VRAM and hard drive far too quickly.
I imagine it’s possible that proper movie texture support might be added later, but you’d have to ask the OTEE guys about that. 
Like Neil said and I’d like to add:
If you need compressed movie playback you have two options at the moment:
a) Use very small movies so that the file size doesn’t explode
b) Write a plugin that uses quicktime to decompress the movie on the fly. If you know C this is not very hard and can be done in around 100 lines of C code.
Ok, that explains a lot! I didn’t realize that’s what happened to movies textures when they’re imported. I made the movies much smaller and that made a huge difference. The build is now down to a much more manageable 114mb, but we’ll keep playing around with it.
Sadly, I don’t know C (I’m a Director/Flash programmer) so writing a plug-in is not an option. Anyone else out there working on one? We’ll probably just get by with the smaller movies (we only need 2) or maybe try cycling a plain image sequence as textures…
thanx!
d