In development, we are limited by the hardware of the end user. Optimization of each model is key to making sure a project will run on more hardware types, but the sacrifice is sometimes difficult. Recently, I decided to model a dungeon scene, and an integral part of that scene was to create chains that hung from the ceiling of the cell with shackles attached. Of course, each link of a chain is rounded, as apparently many things are in a dungeon. Once modeled, the chains consisted of thousands of polygons which would seriously tax the video hardware if the scene was to launch on a mobile device, web-player or even a computer with sub-par gaming peripherals. To demonstrate, I will actually embed the dungeon scene into this post so you can see the lagginess.
Luckily, Unity's editor will break down the statistics that can give you an idea of how something will run on some devices, and the manual has a section for video optimization, which we will discuss in this article. One of the best parts of designing within the Unity environment is the knowledge that you can build your game onto whichever platform you like, but just because your game works perfectly within the editor does not mean your target device will handle it correctly.
While every Unity developer will be able to access the statistics window (the button is at the top of the "game" window within the program), if you have access to Unity Pro, you will also be able to use the Profiler, which can really break things down for you. If you have access to such a useful tool, you'd be a fool not to utilize it. In this article I won't be going into the Profiler (not all readers have access to it) so much as the statistics.
Before the breakdown, let's take a look at the complete dungeon scene attempting to run in a web environment. Once loaded, click on the Unity window and you should have standard FPS controls and mouse look. When you're finished, follow me onto page 2 and we'll get into optimization ideas.
The Unity Support Docs do a great job of breaking everything down, but I'll cover the how-to end of things for ease of understanding. One addition I will make that doesn't seem to be said is this: Test your game, early and often, on your chosen platform. If you are aiming for multiple platforms, test your game on the one with the weakest hardware if you can't constantly test all of them. Yes, building and switching platforms can take some time, but in the long run, you will save yourself hours from having to recover from unpleasant surprises.
Regardless of platform, the less things you have going on (scripts, polygons to render, physics, particles, etc.) the better your framerate will be. This is the root of the issue, and the struggle to maintain a balance. While you may envision a potted garden for your game with hundreds of rounded pots that can be affected by physics and perhaps smashed or otherwise changed, this might not be possible for a mobile or web-based game although you have the ability to build/publish it. The picture on the right shows one of my models for such a thing, and while it looks good, it has far too many drawbacks for a less powerful hardware set.
When we use Unity to take a look at the wireframe version of the pot, we can immediately see some of the issues. The crumpled dirt on top which looks lifelike, consists of a great many triangles that need to be rendered every frame.
With only this pot in the scene, the statistics window shows a count of 5,900 triangles to be exact. This simply will not do on something like a mobile platform. In order to optimize it, it will need to be less rounded and more simplified. We can keep the textures more complex to maintain a sense of realism, but our focus should be to eliminate as many of those extra triangles as we can to make things easier for the graphics processor.
In addition, this model is made of 2 separate meshes - one for the pot and one for the dirt itself. When we optimize it, we should also combine those meshes into a single mesh and eliminate complications.
While your own 3d model program may vary (blender, Maya, 3ds Max, etc.), I will be using Cheetah3d (which I used to design the model in the first place) to make my edits.
For the first step, I have eliminated the dirt mesh completely so we can focus on the pot itself. We're going to eliminate some of the roundness in the process, but in doing we will also be cutting the triangle count of the pot mesh in half. Originally the pot consisted of 210 polygons, but after some editing the count is down to 105.
Next, we're going to simply raise the interior base of the pot and texturize it as the dirt itself. In doing, we will accomplish 2 things: create the dirt we want while also eliminating more polygons that would have gone unseen anyway. If we put our effort into the realism texture instead of the realism of the model, our video card will love us.
Once re-textured, we'll bring the model into Unity.
As you can see, we've seriously uncomplicated the model and made it much easier for hardware to handle.
According to the statistics window, we're now down to only 366 triangles, which is only 6% of the original model. Further focus into the bump maps / normal maps of the model can make it look better, but this model is now readied for a more universal range of platforms.
That said, if you have no intent on publishing your work onto a "weaker" platform, you can utilize more complicated and realistic models. Again, be sure to read into the Unity official optimization documents and judge for yourself.
As an added bonus to this article, I will set up the two versions of this pot for immediate download into your own projects if you like. Just download via the links below, and import the package into your own game to use however you like :)