Finally, let's cover mesh and animation files. These file types are essentially large arrays of vertex and skinned bone data, and there are a variety of techniques we can apply to minimize file size, while keeping a similar, if not identical, appearance. There are also sometimes ways to lower the cost of rendering large groups of these objects through batching techniques. Let's look into a series of performance-enhancing techniques we can apply to such files.
This is the most obvious way to gain performance, but we should never disregard it. In fact, since we cannot batch objects using Skinned Mesh Renderers, it's one of the only good ways of reducing CPU and GPU runtime overhead for animated objects.
Reducing the polygon count is simple, straightforward, and provides both CPU and memory cost savings for the time required for artists to clean up the mesh. Much of an object's detail is provided almost entirely by detailed Texturing and complex Shading in this day and age, so we can often get away with stripping away a lot of vertices on modern meshes and most users would be unable to tell the difference.
Unity offers four different Mesh Compression settings for imported mesh files: Off, Low, Medium, and High. Increasing this setting will strip away more and more parts of the mesh that Unity thinks aren't needed in order to make a good estimate of the same mesh with the aim of reducing overall file size. This is essentially an automated version of having an artist manually reducing the polygon count.
However, automated mesh optimization is a very difficult problem to solve mathematically and even the best algorithms tend to generate a lot of artefacts and irregularities. Different levels of Mesh Compression can be attempted as a quick solution to reducing polygon count, but it will probably never compare to having an artist make appropriate polycount reductions by hand.
The Read-Write Enabled flag allows changes to be made to the mesh at runtime either via Scripting or automatically by Unity during runtime. Internally, this means it will keep the original mesh data in memory until we want to duplicate it and make changes dynamically. Disabling this option will allow Unity to discard the original mesh data from memory once it has determined the final mesh to use.
If we only ever use a uniformly scaled version of a mesh throughout the entire game, then disabling this option will save runtime memory since we will no longer need the original mesh data to make further rescaled duplicates of the mesh (incidentally, this is how Unity organizes objects by scale factor when it comes to Dynamic Batching). Unity can, therefore, discard this unwanted data early since we will never need it again until the next time the application is launched.
However, if the mesh often reappears at runtime with different scales, then Unity needs to keep this data in memory so that it can recalculate a new mesh more quickly, and so the Read-Write Enabled flag should be enabled. Disabling it will require Unity to not only reload the mesh data, but also make the rescaled duplicate at the same time, causing a potential performance hiccup.
Unity tries to detect the correct behavior for this setting at initialization time, but when meshes are instantiated and scaled in a dynamic fashion at runtime, then we must force the issue by enabling this setting. This will improve instantiation speed of the objects, but cost some memory overhead since the original mesh data is kept around until it's needed.
This appears to be another obvious suggestion, but meshes do not only contain vertex positional data. There could be unnecessary Normals and Tangents in our mesh that the Shaders won't need, or we could be autogenerating Normal and Tangent coordinates that we won't use, particularly when the Smoothing Angle is very low. In these cases, each vertex requires multiple normal vectors to create the faceted, flat-shading style that results from it.
Double-check your mesh import settings and examine the resultant file size and in-game appearance, by tinkering with the import settings to see if you can make any savings by stripping away unwanted and unnecessary data.
This will depend on the 3D rigging and animation tool that we are using, and the overall vertex count of our mesh; in some cases baking animations can result in much smaller file sizes and memory overhead than blended/skinned animations. Baked animations work by storing a keyframed position for each vertex for each frame that was sampled, and if the mesh's polygon count is low enough, then we may see some significant savings through this simple change.
In addition, how often the baked sample is taken can usually be customized by the exporting application. Different sample rates should be tested to find a good value where the key moments of the animation still shine-through what is essentially a simplified estimate.
The Optimize Meshes option in a mesh's import settings will reorganize the vertex data for quicker readability, and sometimes regenerate the low-level rendering style (down to the level of points versus tris versus strips) to optimize the rendering speed of the mesh. Simply put, this option should be enabled in almost all cases, as there is very little reason to not let Unity make these adjustments for us, unless we've done some profiling and we're positive that it's somehow generating bottlenecks.
If we're generating meshes procedurally, then we can tell Unity to invoke this process using the Optimize() method on a Mesh Filter Component. This process can take some time, so it should be used during initialization or other convenient stopping point.
Combining meshes into a large, single mesh can be convenient to reduce Draw Calls if the meshes are too large for Dynamic Batching and don't play well with other Statically Batched groups. This is essentially the equivalent of Static Batching, but performed manually, so sometimes it's wasted effort if Static Batching could take care of the process for us.
However, if we're using the Unity 4 Free Edition where Static Batching is not available to us or we wish the mesh to move around the Scene, then this is a good option to minimize our Draw Calls. Beware that it comes with the same risk as Static Batching. If any single vertex of the mesh is visible in the Scene, then the entire object will be rendered together as one whole. This can lead to a lot of wasted processing if the mesh is only partially visible most of the time.
This technique also comes with the drawback that it generates a whole new mesh asset file that we must deposit into our Scene, which means any changes we make to the original meshes will not be reflected in the combined one. This results in a lot of tedious workflow effort every time changes need to be made, so if Static Batching is an option, it should be used instead.
There are several tools available online, which can combine mesh files together for us in Unity. They are only an Asset Store search, or Google search away.