During the last project I did I have constantly be running into troubles and pitfalls while trying to push Unity to its boundaries concerning level sizes, textures used and triangles rendered. It was especially hard to keep down the draw calls and thereby ensure a acceptable fps count. There are a few useful tipps to keep draw calls down, like atlas textures, mesh merging, and implementing a simple LOD system. I will talk about all those in the future. Today I want to focus on another important aspect when it comes to rendering performance: Shaders!

Once all the above mentioned is done and only a couple of hundred draw calls are left for your level environment to be rendered you still can increase the performance dramatically by optimizing shaders and not using builtin-shaders. For a city scene as shown here I went from around 2000 draw calls to around 350 just by restructuring the texures and meshs used in the scene, which went along with a great performance increase. After optimizing the shaders used in the scene I managed to increase performance a little more and get twice the fps rate out of the same scene.

Unity’s builtin VertexLit Shader Collection assumes that pixel lighting and dynamic shadows might be used in any scene in your project and therefore it might become neccessary for objects that are rendered with the standard VertexLit shader to cast and/or receive dynamic shadows. The shaders use a second pass to enable shadow casting and shadow receiving.

Depending on the structure of your game world this might very well be a redundancy. It certainly was for me as I did not plan for pixel lighting or dynamic shadows to be used for the game world itself, i.e. buildings, props, vegetation, AI traffic and NPCs.

To ensure this I used two directional lights to simulate sun light instead of only one:

• a pixel light affecting the player objects (the player vehicle and player driver) and casting dynamic shadows
• a vertex light for all other objects: buildings, props, plants, AI vehicles, etc.

I used the culling masks of the lights to make sure that only the objects I need to are affected by the respective light. The missing ability of VertexLit objects to cast shadows was supplemented by a pre-rendered shadow map that was projected onto the level’s floor.

Once this preparation is done creating optimized shaders is easy. You just take the builtin VertexLit shaders and take out the second pass.

You can do this for all sorts of shaders. For the city scene as shown in the last post I used the following set of optimized shaders: VertexLit, Transparent Cutout VertexLit, Transparent VertexLit, VertexLit Detail (a vertex lit version of the Diffuse Detail shader).

I put together a basic shader package to get you started. Twitter me about your results if you have done some performance tests yourself - I am curious to know whether anybody can reproduce my drastic performance boost.

Download [SimpleLit_v100.zip]

fixed the Download link

I consider localisation and release management for a game a major pain when releasing a new product. My last few games all got released in almost a dozen different territories where the respective publishers would not be satiesfied with an english-language version but rather wanted a translated game version. After doing the first few locs completely “by hand” (which took up to 2-3 days for complex games) I decided it was time to come up with an automated, easy-to-use system that will drastically reduce hands-on time neccessary to complete the loc for a new territory.

Here is a first look at my Localisation Module

This is the Master Loc Editor.

Considerations

The idea is to create one master loc referencing all strings, gfx and sound assets that need to be localised. When I need a new language version I simple duplicate the Master Loc and translate all strings and assets (I call the duplicate a language-specific loc). Here of course I have run into the first problem: assets like gfx and sounds need to be handled differently than strings - especially with the way Unity manages assets: an asset is not only a file. An assets has been imported, has been assigned a GUID and meta data (like import settings) is being stored in the library of the unity project. So the original assets used during development need to remain the same and keep their GUID.

Localising Assets (gfx, sounds)

Assets like gfx and sounds are listed in the master loc as well. I assign replacement assets in the language-specific loc. The replacements will - well, as the name says - replace the original files when building the game (simple file copy process so the meta information on the assets within Unity will remain as it was). And that’s it. I can localise all sorts of assets this way, replace ui gfx, textures, sounds, even meshs if I wanted to.

Localising Strings

Strings are much easier to localise. I use a simple key-value list. The Master Loc as seen in the editor in the image above consists of strings grouped into classes (to make it easier to keep track). Each string has an ID and content (that is displayed in the GUI for example). I can export the strings to XML files and pass them along to the translators. Instead of using GUI.Button(“HelloWorld”) I use GUI.Button(LocManager.GetString(“helloWorldButton”)). The LocManager will then get the string for the ID “helloWorldButton” from the loc-XML-file.

Additional Localisation Efforts

There a few things I do in addition to localising assets and strings. Most territories/languages have an own style of formatting dates, numbers, times, currencies, etc. For most of this .Net comes in handy as I can specify a CultureInfo for the game’s thread. This also works very well with Unity and takes care of the most basic formatting needs I have (date and time). For ease of use I just take the Windows locale identifiers to name my locs (e.g. de-DE, en-US, en-UK, es-ES). For currency and some other formats I use own format functions because the culture-based functions of .Net are a pain there.

Development

I am nearly done with this module, after it is complete I need to tie it in with my Release Management Module and Build Versioning System.

Collection of four basic c# Visual Studio 2008 Templates: MonoBehavior, ScriptableObject, ScriptableWizard, EditorExtension. I use this templates whenever I create a new Class or whatever. It is much easier to do it this way than to fill a blank file with the neccessary imports, events, etc.

To import the templates just copy them to your My Documents/Visual Studio 2008/Templates/ItemTemplates folder and restart VS.

I don’t know because I have not tried it, but I reckon the templates also should work for VS 2005.

Download [VSUnityTemplates_v100.zip]

I am currently looking to extend my team of beta testers. If you are located in Germany and are interested in games - maybe even have some product testing expertise - please do not hesitate to contact me at azeitler@dopanic.com.