Unity Tip: Agree on Scale

The first thing you need to do on a new project with modelers is to agree on a scale. This is especially important if there are multiple modelers on the project, you don’t want them all producing content at different scales! The best way to determine scale is to ask each modeler to produce a one unit cube as they see it. Bring the cube into Unity and compare it to the primitive Unity uses (Menu > GameObject > Create Other > Cube). The Unity cube is one unit squared and one unit is one meter.
Why is it important that we stick to Unity unit = 1 meter? For starters, it just makes sense right? When you code anything in your game, it’s easy to move something 1m/s.
Also, if there is any physics in your game, you’re going to need to stick to this concept. The physics simulation is based on 1 unit = 1 meter and any other scale is going to give you a physically weird world. Things will fall too quick or slow.

Unity Tip: Where are the Editor Logs?

There’s going to be a point when you crash Unity or your built game. It might just be an instability issue, it might be a loop in your code that can go awry. Sometimes you have no idea and that’s when you need to dig through the log files.
All the information you need is on this page to find them.
The quickest way to the editor log is to use the button located top right in the Unity console window. You can also find things like build size breakdowns after you have built your project. It makes tracking down inappropriately massive assets in your build easy.
Log files also contain all your Debug.Log outputs which can be very useful if you’ve compiled and built your game and it’s now crashing on another machine.

Unity Tip: Frame Skip Button

2014-03-31 20_06_10-Unity - level1.unity - TestB - PC, Mac & Linux Standalone_

It’s the last one of these happy little fellows and it can come in quite useful. I must admit I don’t think I ever used it for the first year using Unity but it came in handy when I needed to pinpoint a frame and what was actually happening in it. All it does is advance your game, frame by frame, in pause mode. So keep an eye out for when it will come in handy…

Unity Tip: Use Empty GameObjects as Hierarchy Folders

It’s very easy for a scene to become very cluttered, especially in the hierarchy where you can end up with thousands of GameObjects. The simple way to control this though is to create empty GameObjects that just hold the children. It can keep a large bulky project clean and hide a lot of assets and GameObjects.
Remember to make sure they have their origin set to world zero so things make sense though. Do this before nesting objects so their position isn’t affected by moving the parent to world zero. Unity will place newly created GameObjects where to scene editor camera is so they end up being in arbitrary places. After nesting three or four times, the local position of the children could be anything. It might not matter at first, but it could trip you up later on.

Track BuildR 1.1 Released


I have recently released the latest version of Track BuildR which has been christened the “Stunt Update“. This version comes with support to create circuits with loops, jumps and twists after rebuilding the track cant implementation.
It also includes Substance texture support, FBX, OBJ and XML export, track extrusion and some minor bug fixes. I’m very proud of the fact that Track BuildR since release has had only one bug!
The update did come at a slight cost – 1.0 tracks are not supported… With the new undo system that Unity 4.3 implemented along with the hell that is using ScriptableObjects, I needed to change the base implementation of Track BuildR to Monobehaviour. The problem is it breaks backward compatibility… I do have a plan for users needing the upgrade. It involves exporting the 1.0 track to XML (with some re) and importing it into a fresh 1.1 track. This method was used to bring the Spa Francorchamps track to 1.1 and it’s pretty easy.
I hope it’s well received! You can check out videos, demos and further information.

Unity Tip: Hold Alt to Mass Collapse/Expand GUI Hierarchies

2014-03-29 18_51_31-Unity - On Rails Shooter.unity - Camera Path 3 - PC, Mac & Linux Standalone

You have a complex scene with many nested GameObjects and then you accidentally click on that small pebble in your scene making your hierarchy explode to reveal that pebble. Fear not! You can alt click the top level parent arrow to collapse every collapsible child GameObject and return your hierarchy to normality.
It also works the other way around, allowing you to expand every nested GameObject instead of only the current selected one.

Unity Tip: Don’t Use Public to Show Fields in the Unity Editor

If you want to see a variable appear in the Unity editor, you don’t need to make it public. You can use [SerializeField] / @SerializeField to do this and keep your variable private.

private var _myPrivateString = "You can see this in the Unity Editor";
private string _myPrivateString = "You can also see this in the Unity Editor";

SerializeField is also important if you’re encapsulating properties in scripts… Properties don’t appear in the Unity editor by default, but if you’re using custom editors, you’ll soon slip on this problem…

private bool _hiddenValueA = false;
private bool _hiddenValueB = false;

//_hiddenValueA IS NOT serialised so when you press play it resets!
public bool valueA
    get{return _hiddenValueA;}
    set{_hiddenValueA = value;}

//_hiddenValueB IS serialised so when you press play it is saved.
public bool valueB
    get{return _hiddenValueB;}
    set{_hiddenValueB = value;}

Generating Low Detail Models in BuildR


I’ll admit that I just had a really geeky weekend. I spent most of it coding away and I thought I should share what I’ve learnt. My mini weekend project was rebuilding the low detail model generator in BuildR. It was working fine but for what it does, however it was a little too slow and I felt I should spend some time working out why.

The output needed to be a low poly, single textured version of the high poly model that BuildR outputs. Generating the simplified mesh is super simple. Turning facades into planes and stripping some detail from the roof brought the polycount from 3813 down to 875 in the Paris example above. It was transforming the facade details and textures into a single atlased image that proved time-consuming.

The whole generation process clocked in at about 8000 milliseconds on Saturday morning. This was a little too long, even for doing things in the Unity3D editor. Right now I’ve got it down to 600 without cutting the quality significantly. There is definitely some more research I can do in this area (use RenderTextures maybe?) to reduce it further and 600ms is still far too high for this to be used at runtime.

The key to the problem lay in the powerful function in Texture2D called PackTextures. For most things, this is an awesome, magic function – you just throw your textures in and a single packed texture comes out. Simple right? To do this, PackTextures requires a set of Texture2Ds. That means that BuildR needed to create a new Texture2D object and call Apply for each facade. However, with the large textures that BuildR deals with, these are not only very expensive operations but take up a massive memory footprint.

I figured one way to avoid this would be to use a single Color32 array throughout the whole procedure and use one Texture2D object and Apply call at the end. To do that I needed to build a custom texture packer and texture resize function which I previously allowed Texture2D to handle.

The process I ended up with felt a little backwards at first, but it seemed like the best way. The first thing BuildR now does is build the roof mesh. From this mesh generation, BuildR extracts which textures are used and the world dimensions they occupy so it can atlas an appropriately sized version. The data goes straight into the custom texture packer along with basic facade data.


The texture packer actually only generates bounding rectangles for all the textures and does no actual image manipulation  It sorts the textures by width, stacking texture bounds on top of one another. If they don’t fit, they are added to the right creating a new column. There is also no limit at this stage to the size, but the overall dimensions are kept within a square shape as the output would be a power of two.

Once all the rectangle bounds are generated, the whole thing is scaled down to the nearest power of two size and BuildR begins generating facade textures. This involves filling the main colour array with values based on the texture bounds that the texture packer generates.

BuildR needs to resize textures so that they fit the output image size. I ended up implementing a nearest neighbour algorithm to tackle this. This simple algorithm down samples the image into a smaller size giving BuildR reasonable results. I feel there is a lot more research that could be done here, but this ends up being a fairly expensive operation.


At this point it’s worth mentioning a problem with using Texture2D.PackTextures padding. You can specify an amount of padding in this function, but the colour of the background is black. The buildings end up with some nasty black lines along some of the facade edges (as above) and it is only worse with lower mipmaps. To solve this, facades need to have their own padding that reflects the edges of the textures.

I’ve attached the RectanglePack.cs class but I’ll do a separate blog post on texture resizing algorithms.

TL:DR – By dumping multiple instances of Texture2D, calls to Apply, performance is dramatically improved. This necessitated dumping a couple of useful Texture2D functions Resize and PackTextures.

BuildR Building Generator is available on the Unity3D Asset Store

Unity3D and Visual Studio

Code Screen

I got tired of MonoDevelop. It was totally adequate, but I thought there must be better IDEs to develop on in Unity3d than ‘adequate‘. I turned to Reddit to poll the Unity3D community on what they use and what they recommend. Some of it was unhelpful, but people took the time to answer the question and to them, I’m thankful.

At the moment I develop on my Mac Book Pro but I tend to use my wife’s 27″ iMac as a second (more like main) screen using target display mode. It works fine, except when I leave that mode and the iMac looses the mouse pointer – OSX doesn’t ‘just work’, and for what it is, it’s bloody unstable (but that’s a separate blog post). So that means bootcamp is a secondary option as I can’t use that nice big screen. I need to stay in OSX somehow.

I had a bash at Sublime Text 2 but it just wasn’t what I was looking for. It’s more just a text editor and I need something with some oomph!

Jdonavan suggested Parallels and Visual Studio 11. Why didn’t I bloody think of using Parallels! It should be perfect for the task and I used it once in an old job. I tested it out and sure enough I could fullscreen it on both monitors. The only bug I’ve found with it so far is that the Unity editor will not pick up the mouse sharing. Everything else works fine. When I test my scenes I have to switch the mouse to the Win7 inside Parallels and so lose it in OSX temporarily.

Next up was getting Visual Studio 11 to work with Unity. Not as straightforward as I hoped, but it didn’t take long. The first hurdle is that Unity doesn’t even recognise 2012! You have to manually add it as your external editor. Go into options > external editor > browse. then you need to find your copy of VS. If you browse to something along the lines of Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe it will work. Unity then displayed the correct name in the drop down which was a positive sign. So now I could click on script stuff in the Editor, it whisks you off to happy Visual Studio land.

The next problem was that VS11 didn’t have references to the Unity DLLs. Again with a little forum searching and playing around, I found the right place to link them up. Under Project > Add Reference > Browse > [Unity Directory]/Data/Managed/ UnityEditor.dll and UnityEngine.dll. Looks like you have to add this on every project though.

And it’s all set up. The other thing I invested in was Resharper. Having heard from many sources that it was just all kinds of awesome, I added it in and it’s been absolutely amazing. The one big thing I’ve been missing since leaving Flash/FDT behind was templates and they’re here in all their glory. It’s a good plugin and extends VS really nicely.

So far I’ve been on this setup for a month and I’ve not looked back. If you do extensive coding in Unity3D and C#, this is something you really need to look into. The time I’m saving now is pretty great and it’ll only get better as I learn the million shortcut keys that VS has to offer and as I build my template empire.

Soon, I’ll try out UnityVS. They’re promising shader editing in VS which would be well worth my money. They already have full debugging to – which I really need. I’ll update that as and when I get round to buying it and trying it out.