This week we want to talk about performance. We managed to get somewhere with the graphical presentation of our game, but that comes at a cost. The game is meant to run smoothly on a lower range laptop, but still look decent. We took a few screenshots on our mid-range test laptop with MSI afterburner showing the fps in the corner of the screen. This is shot on low graphic quality on a Dell Studio 1555 with a Core2Duo P8700 @ 2.53 GHz, Mobility Radeon HD4500 and 4 GB of RAM.
Image 1: Dell Studio 1555. Low settings, 1280x720
As you can see, there is plenty of fps to go around and the game should run smoothly enough on low detail on a low-end machine. On this laptop, which we could consider a mid-range machine nowadays, the game runs smooth on highest detail.
Image 2: Dell Studio 1555. High settings, 1920x1080
On our relatively decent desktop, a core2quad Q6600 @ 2.4 GHz with an NVidia GeForce 460gtx and 4 GB of RAM the game runs flawlessly.
Image 3: Poly count, Draw calls, VRAM, High settings, free aspect.
However we really want this to run smoothly on a low-end laptop, like my old AMD Turion x2 @ 1.8 GHz with an NVidia GeForce go 7300. We had some issues with testing as it turned out there was something wrong with the GPU, but whatever it was, we managed to keep it running constantly over 30 fps on low detail. Not too shabby for an old dust collector. We could add additional meshes, details and the like to improve the presentation, but then we might not get the game to run well on our target devices. Nothing is set in stone yet, but we hope to keep the performance at least at the current level.
The game is being developed in Unity indie, which lacks certain performance features, like static batching, adjustable level of detail (LOD) and occlusion culling. There is also the profiler, which would help us pinpoint the hungrier parts of the game. In spite of these limitations we manage somehow. Our current policy for performance is to keep meshes under 1500 polygons and to keep draw calls at a minimum (around 200 for now) by combining meshes, avoiding particle systems, real-time shadows and managing the rendering distance as well as culling layers (allowing us to manage what is rendered at what distances).
We will continue to polish the game so we can deliver the best performance for the graphics, maybe we will even launch a fundraising campaign, to raise just enough for Unity pro. Then you can look forward to better performance and better graphics in a nice mind-baffling feline package.
Oh and check out the screenshotsaturday pic in case you missed it.
Image 4: Screen Shot Saturday
Thanks for staying with us and don't forget to follow us on our social hubs.
For the Catmouth Island I spent months preparing for the island building process to make sure that we could render a whole island in full detail on a mobile device. The trick was to use very low-poly meshes and use the textures to show the detail, and use as few atlases as possible. There are only four big atlases that give texture to everything you see on the screen with the exception of the skybox and the infinitely tall house. Some meshes are combined using static batching and we use dynamic batching for the rest. Thanks to this the draw calls are below 20 and we get over 1200 fps on our test system, and even the older test version runs great on mobiles. :3 (However, with dynamic shadows there are over 8k tris on the screen at the same time, but without it goes as low as 2.5k. Most mobiles cannot use dynamic shadow casting so we are looking at omitting it for mobile platforms.)
That is a good setup you have there and the game looks really good too!
We are aiming for PCs so we can afford more draw calls. We would, however, like to reduce them as much as possible. In our case what makes a lot of draw calls is free camera which can render really far. We are also using lightmaps for shadows so many objects remain static and can't use dynamic batching. Unity terrain also accounts for many draw calls. Lots of our objects that are interactive change material so they can't be combined easily.
The terrain in Catmoufs is made externally in Blender before imported into Unity. I found that the best way as I have more control. It did take a lot longer to plan and prepare but it was worth it, compared to what I tried to achieve using Unity terrain.
If you use individual meshes instead of combined objects you could have draw distance culling so that objects far away aren't drawn until you are close enough for them to be visible. I have yet to try the occlusion culling in Unity but I guess it would help out too?
We are searching for balance between combined objects and cull distances. Combined objects reduce draw calls since we have no static batching(unity pro only) while sometimes making bigger calls when they should be culled. Occlusion culling is a unity pro feature:<.
I am using Unity Pro, but I have made prefabs externally already for larger patches of natural detail like bushes and rocks. That also helped reduce draw calls by 70%, but at the same time the tris shoot through the roof.