Unity3D Performance : Quirks with Unity and Assets

Unity does not like non-uniform scale on unskinned meshes. Uniform scale is when the X, Y, and Z scale are all identical, if any of them are off, it is a non-uniform scale. Yes, this even includes “2D” elements, such as buttons and hud graphics, you still want to scale the depth on these even if there is not any visible depth. Skinned meshes, such as characters, handle non-uniform scale fine. Before Unity 4, even constant non-uniform scale was a performance concern. With Unity 4, Unity started caching these non-uniform scaled meshes in the background, so as long as the scale is not animated, you are only paying the high cost of non-uniform scale once, and after that Unity will reference the cached data.

Unity claims to support non-power of two textures for iOS, but this support comes at an extreme memory cost. Non-power of two textures are textures whose width or height do not fall on a power of two, values that are not: 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024. If either the width or the height of a texture is not a power of two, Unity will more than double the memory usage of the texture. For these textures, Unity will keep a copy of the original non-power of two texture in memory, and will also create a texture with the extents padded out to a power of two. This can lead to a lot of missing memory for UI and hud elements that are non-power of two.

There are many special rules for folder names. The most common folder name rule is for “Resources.” Anything in a folder, or subfolder of a Resources folder is considered by Unity necessary for the build, and will be packaged with the app. The immediate thing you will notice here, is if you have unused assets in your resources folder, they will be packaged with your app. The concern here falls on to total build side, if you are targetting under 50 MB of total size to get under the limit for over the air download, you will want to removed unused assets from any Resources folder.

Aside from the obvious problem there, the next thing to be aware of is a bug with Unity’s Resources system. Any files with dependencies in them, in the Resources folder, will cause a permanent hit to runtime memory. Unity is aware of this bug, and it will hopefully be fixed in a future version of Unity, but it is something to be aware of now, as it can stealthily eat large chunks of runtime memory, making you pull your hair out trying to figure out where it all went. The case this most often comes up with, is animations. Luckily there is a workaround here, and that is to put your animations into a folder not in a Resources folder. While everything in a Resources folder is automatically included in your build, Unity will still add files outside of the Resources folder to the build, if there is a dependency on them. In the case of animations, they will be added to the build as long as the base FBX model associated with them is in the build.


Joseph Stankowicz is a software engineer who has worked in the video games industry for over eight years. The last two years have had a heavy focus on Unity development, where he helped ship over eleven titles to iOS and Android platforms. He also is really excited about 3D printing, and keeps his Solidoodle 3 printing out stuff as often as possible. You can view his LinkedIn profile here http://www.linkedin.com/pub/joseph-stankowicz/60/294/420

Tagged with: ,
Posted in Unity3D, Unity3D Performance
One comment on “Unity3D Performance : Quirks with Unity and Assets
  1. Andy Megowan says:

    Ellen Beeman linked your blog on Facebook. I wanted to add my two cents on the Unity scaling issue.

    At my previous job, I worked on projects with just a few very high poly models, and on my most recent game, I worked with hundreds of very low poly models. One of the biggest performance improvements that I came across was that scaling operations on GameObjects with collision meshes was very expensive, perhaps because an octree or similar structure is being rebuilt under the hood. For things that resized, uniformly or non-uniformly, if I could disable the collision mesh component until the rescaling was complete, things ran much more smoothly.

    And I found that using a high polygon models’ rendermesh as its collision mesh was great for low-poly items, but I always wanted a low-poly hull for collisions on high-poly models, especially if scaling was ever planned. This one should be a no-brainer, though 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: