I'm currently trying to understand how Unity creates its builds because my teams is creating a texture heavy game and it's crucial that we have enough memory for the game to function in the various environments (specifically web and iOS).
To test out the memory, I created a scene with a 166MB Resources folder and a cube. If you want to try it you can download it here: http://www.mediafire.com/?a137tz6anatf6qi. The cube's for debugging purposes: When the scene is just loaded, it's green. It changes to blue and a second later starts to load all the textures in Resources. When it turns red it unloads all unused assets (which is basically everything because I didn't assign the textures to anything).
Now I've read about the disadvantages of Resources folder in various places, but my issue is: with an empty scene and one game object, when the scene just starts, the process already takes up more than 600MB in the task manager!! After loading all Resources, it goes up to 1.3GB. Why? What is the 600MB that is being loaded? And how come the Resources folder bloats up by ~6 times?? I read something about the compression actually increasing the file size of the images, is that true?
You do not specify if you are running a build or in editor mode. I'm guessing you are running in editor mode, and I think Unity loads all resources in editor mode in case you want to change something on the fly.
Make an actual build of your cube test project and re-check the memory usage. According to this, it will not even put your unused resources in the build (and as far as my experience goes, that is true).
Unity is already very efficient on doing what you want (outside the editor mode), so I think you shouldn't have to worry too much with it. Take a trial version of Unity IOs and build your cube project for actual device testing.
This page lists texture compression types you can use for each platform. You may want to check out:
"RGB Compressed PVRTC 2 bits Compressed RGB texture. Lower quality format suitable for diffuse textures. 2 bits per pixel (16 KB for a 256x256 texture)"
Related
I am planning to ship an app with at least 20 pictures that can be at big as 10mb each. They are pictures that the user is likely to zoom in quite a bit therefore it is a requirement to keep the resolution quite high. We are still trying to make them smaller, but even so, its unlikely that they are going to be less than 7mb each.
The images can be shipped with the app as well as additional pictures can also be downloaded. The requirement is for the pictures to be available offline once the user downloads them as the app is to be used in remote areas by researchers.
What is the best mechanism to store them and how should I store them in iOS Swift 3?
Thanks for your help in advance.
You can store your pictures in document directory of the app and store the path in SQLite DB.
There are not rules but a set of best practices.
To store them I suggest you to save them directly into your resources, not Xcode image asset, this is because "image asset" can only be called with the imageNamed: method of UIImage, that has the side effect of cache images.
Then you can create a plist file with an array of image names, and fetch your info from here. If you need something more complicated there is Core Data, but I can't see an application of it with your spec.
What is the size of an uncompressed image in memory? An approx
equation n_pixel_height * n_pixel_width * n_channels in bytes (supposing 8 bit for channel)
If your images are about 10Mb in jpg they are compressed, thus means that they will take a huge amount of memory. memory on this kind of devices is a precious and short resource.
If your app exceeds the memory limit, after a set of callback such as didReceiveMemoryWarning, if you don't free enough memory, you app will be killed.
Alway try on device in this case and not on simulator because the simulator use your mac resources.
Now how to handle big images?
You can use CATiledLayer, you can find a lot of tutorials online. CATiledLayer as the name suggest creates a tiles of layer, each tile should correspond at a piece of your image, and it draws them only when they are visible.
Unfortunately it draws asynchronously this means that your tiles can be shown not exactly at the same time, there some strategy to avoid that issue, one is explained in an apple sample code.
Of course there is a problem that needs to be solved, how can I cut my large images into tiles?
You can do programmatically or provide them already cut as resources of your application
I have an iOS opengl es 2.0 app that needs to use a TON of large textures. Ideally 4096x4096. I have a struct array that contains all the info about the texture, and as I need to use each one I glGenTextures a new texture id and load the image there, free up the uiimage, etc. That all works great.
My app uses a bunch of textures for UI, image processing, etc. About 4-5 of the 15 I'm using for all of that are 4k x 4k. Rest are smaller. And then these load-as-needed textures are also 4k.
On loading about the 4th-5th of those the app crashes HARD. No console or debug. Just quits to the springboard in the middle of trying to load the next texture.
I don't have a memory leak - I ran instruments. I'm using ARC. I can post the crash report from the Organizer but it doesn't have much info. Just that my app's rpages was 170504.
I could post the image load code but its the same code I've used on all my apps for years. The new thing is pushing the system that hard and trying to load that many large textures.
Q1: Anyone have experience with using a ton of large textures?
So I resolved to the fact that I'll have to do preview res stuff at 1024x1024 and then final res stuff at 4096. The 1k images are now loading as needed and staying loaded. The 4k images will all be loaded one at a time into the same texture to be used and then move on to the next.
I wrote into my image loader a preview parameter and when set it shrinks the image to fit in 1024 during the load. Now Instead of crashing on the 4th or 5th I can add textures 'all day'. My GUESS is that I could do 16x as many as before. But I only need like 20-30 at a time. (only!) So far I've tried 20 with no memory warnings or crashes.
However.. if the app keeps running, because my textures are loaded at unique texture ids, at some point I would hit that spot where I need to unload one that's no longer needed to load the next one. This is probably very simple, but....
Q2: How do I free up a texture that's at an texture id when I no longer need it?
Q3: Will a memory warning tell me that I need to free up an open gl texture?
Q4: Aren't textures loaded on the PVR chip? Are they or how are they even taking up the phone's memory?
Thanks!
Removing Texture:
You have to use this GL call from the main thread.
glDeleteTextures(1, &_texture);
Memory warning is a general call to the application. It will not give you specific information. It is always better to remove unwanted textures from the memory if they are not needed anymore. Eg: We usually remove textures used in menu when the user moves to the In-Game screens, they are reloaded again when the user navigates back. This is much easier to manage memory than waiting for the system to call memory warning.
When you load PNG image, the data is decompressed and stored raw as array of colors per pixel. A 1K texture will use 4 mb despite of content/colors in the image. PVR is a hardware decompression chip which will decompress realtime when the image is used by the GPU, and the image file size you see is what memory it uses.
I just recently talked to an app marketing agency and they are strongly recommending that I find a way to take my 153MB app and somehow get it under the 50MB mark that is the current standard for downloading over a wireless network (3G, 4G, etc.).
I have no idea where to go from here. As far as app size goes, my app is very UI intensive and I have a combination of (mostly) JPGs, PNG's, and a few small videos. I've already run all my jpg's through JPEGmini and as many png's as still looked alright through tinypng.org.
I'm curious if I could somehow "compress" or zip my resources and then unzip them in code to significantly reduce my app size (Before it's installed on the device...I don't care how big it expands to after it's downloaded and installed).
Host the video somewhere else and then downloading them after the app starts for the 1st time (or when they are actually played) maybe the biggest win. Other small wins would be drawing procedurally as oppose to using images. What is the combined size of your images, also the combined size of your videos?
I apologize upfront for the long question, with multiple subquestions, but the question is really as stated in the title. All that follows is a detailed breakup of different aspects of the question.
In my universal ios game built using cocos2d, I have four categories of images - I want to determine which of them should go into spritesheets and which are better off loaded as individual images. My current guess is that only character animations that run throughout the game provide value being loaded in memory as spritesheets:
Character animations that run throughout the game play (except
when user is in menus): for these, I assume that having the images
in a spritesheet will reduce runtime memory usage (due to the
padding of individual files to power of two byte boundaries), hence
they are candidates for a spritesheet. Is that correct?
Small images (about 200 of them) of which 0 to 4 are displayed at any
time, picked at random, during game play. For these, I am not sure
if it is worth having all 200 images loaded in memory when only at
most any 4 are used at a time. So it may be better to directly
access them as images. Is that correct?
A few (about 20) small menu elements like buttons that are used only in static menus: since the menu items are used only during menu display, I assume they are not of much value in improving memory access via spritesheets. Is that correct?
A few large images that are used as backgrounds for the menus, the game play scene, etc. Most of these images are as large as the screen resolution. Since the screen resolution is roughly equal to the maximum size of a single image (for example, for ipad retina, 4096 x 4096 image size versus screen size of 2048 x 1536), there isn't much gain in using spritesheets as at most 1 or 2 large images would fit in one spritesheet. Also, since each of these large files is used only in one scene, loading all these large images as spritesheets in memory upfront seems like an unnecessary overhead. Hence, directly access them as spritesheets. Is that correct?
A couple of common related questions:
a) Packing images used across different scenes into the same spritesheet makes us load them into memory even when only a subset of the images is used in that scene. I assume that is a bad idea. Correct?
b) There is a stutter in the game play only on older devices (iPad 1 and iPhone 3gs). Will spritesheets help reduce such stutter?
c) I assume that spritesheets are only going to benefit runtime memory footprint, and not so much the on disk size of the app archive. I noticed, for instance, that a set of files which are 11.8 MB in size, when put in a spritesheet are 11 Mb - not much of a compression benefit. Is that a valid assumption?
Please let me know your thoughts on my rationale above.
Thanks
Anand
Rule of thumb: everything goes in a spritesheet (texture atlas), unless there's a good reason not to.
Definitely texture atlas.
Cocos2d's caching mechanism will cause all individual images to be cached and remain in memory, so eventually they'll use more than if they were in a texture atlas. I would only use single images if they're rarely needed (ie menu icons) and I would also remove them from CCTextureCache just after they've been added to the scene, to make sure they will be removed from memory when leaving that menu screen.
Assumption may be wrong. A 320x480 image uses 512x512 as a texture in memory. If you have multiple of them, you may be better off having them all in a single texture atlas. Unless you enabled NPOT support in cocos2d. Again, don't forget that CCTextureCache is caching the textures.
Keep in mind that large textures benefit a lot from spritebatching. So even if there may only be 2-3 images in the texture atlas, it can make a difference in performance.
a) It really depends. If your app is running low on memory, you might want to have separate texture atlases. Otherwise it would be wasteful not to pack the images into a single texture atlas (if possible).
b) It depends on what's causing the stutter. Most common issue: loading resources (ie images) during gameplay, or creating and removing many nodes every frame instead of re-using existing ones.
c) Probably. It may depend on the texture atlas tool (I recommend TexturePacker). It definitely depends on the file format. If you can pack multiple PNG into a single .pvr.ccz texture atlas, you'll save a lot of memory (and gain loading speed).
For more info refer to my cocos2d memory optimization blog post.
I am creating a kind of 'map' in my app. This is basically only viewing an image with an imageView/scrollView. However, the image is huge. Like 20,000x15,000 px or something. How can I tile this image so that it fits? When the app tiles by itself, it uses way too much memory, and I want this to be done before the app I launched, and just include the tiled, not the original image. Can photoshop do this?
I have not done a complete search for this yet, as I am away, and typing on an iPhone with limited network connection..
Apple has a project called PhotoScroller. It supports panning and zooming of large images. However, it does this by pre-tiling the images - if you look in the project you will see hundreds of tiles for various zoom sizes. The project however does NOT come with any kind of tiling utility.
So what some people have done is create algorithms or code that anyone can use to create these tiles. I support an open source project PhotoScrollerNetwork that allows people to download huge jpegs from the network, tile them, then display them as PhotoScroller does, and while doing research for this I found several people who had posted tiling software.
I googled "PhotoScroller tiling utility" and got lots of hits, including one here on SO
CATiledLayer is one way to do it and of course the best if you can pre-tile the images downloading them from the internet (pay attention on how many connection you are going to open) or embedding them(increasing overall app size), the other is memory map the image on the file system (but an image with that res could take about 1GB), take a look at this question it could be an intersteing topic SO question about low memory scenario