Unity3D Mesh Collider vs. Box Collider

Logic tells us that a box collider in Unity3D will be more performant than a mesh collider simply because it is less complex. But I had an impulse a couple days ago to test it out myself. This doesn’t really scratch the surface of every use-case.

I went to the AssetStore and picked out a fairly simple free armchair model. I then made two different prefabs, one with a convex mesh collider, and the other with a box collider.

Chair collidersThen I made a script to spawn a 40×40 grid of a type and let them fall onto two planes. That means a total of 1600 armchairs were doing discrete physics updates, which will kill even the best of the PC master-race.


On the left side we have the mesh collider, and on the right is the box collider. Click the gif to goto a full-size version which has a bar to manually scrub through.

As expected, the summary is that the mesh collider is incredibly slower (sometimes even 20x slower) than the box collider. And in this case the mesh collider is actually pretty simple. Something worth pointing out is that although the graphs sort of line up, their scale is totally different, so take a proper look at the number on it.


Now for bonus points, here is a pretty scene of a stupid amount of spheres attacking the streets of New York.

Nuget: Your project.json doesn’t list ‘win10-x86’ as a targeted runtime

Recently I was working on a small UWP app on my SurfaceBook and everything was fine. But when I pulled the code from GitHub down to my main machine I got the following error:

Your project.json doesn’t list ‘win10-x86’ as a targeted runtime. You should add ‘”win10-x86″: { }’ inside your “runtimes” section in your project.json, and then re-run NuGet restore. 

After a while I figured out that this error is totally misleading, and the real problem is that your Nuget package source has been disabled. I have a feeling this was related to installing Visual Studio 15 preview.

Anyway, to fix it: Click Tools > Options > NuGet Package Manager > Package Sources, and then re-enable (or re-add) the sources.NuGet Package Manager

Full Netflix vs ShowMax South Africa Catalogues

A couple of years ago I wrote a guide for getting Netflix in South Africa, which still gets thousands of hits a month. A lot has changed since then – notably, Netflix has finally launched in South Africa, and a bunch of local VOD services have launched (ShowMax, Vidi, and some other small ones).

But even though Netflix is now in SA, the content is really limited. This isn’t Netflix’ fault, but comes down to licensing and what makes commercial sense. For this reason, the guide linked at the top is still 100% valid, and will open up tons of extra content.

Since the Netflix SA launch there has been lots of media comparing Netflix with ShowMax (and others), however none of them really go into any detail, and the actual data they have seems pretty inaccurate.

So I crunched the numbers!

Netflix vs. ShowMax January 2016 Continue reading

Simple network discovery to find Netduinos from Windows

With the advent of Internet-of-Things things, you’ll probably need a decent way to actually find all of the things on your network.

Fun fact: If you send a UDP packet to *.255 on your network, your router will then send that along to all the devices on your network. So if your local network is on 192.168.1.x, then send it to Or if you want to send it to everything, then you can send to

In my case, I’ve got this awesome little guy…

Netduino 3 WiFi

…setup with DHCP, so the IP occasionally changes. I’ve got a Windows 10 app that needs to connect to it, so we can use the way above to find the Netduino on the network.

Continue reading


Vox Telecom Windows App

We recently switched from Afrihost “Business” Uncapped to Vox Telecom capped so that we could do cool things like actually load websites and stuff. However monitoring cap from their website is quite a pain

So I made a Windows Universal app in a few evenings. It’s been in the store for a couple weeks now and it seems to be working well for people, so I’m posting here.
Continue reading

Varsity College

An interesting way to judge hackathons

A while back Taylor Gibb, Gordon Beeming, and I held a Windows Phone hackathon at Varsity College. Generally when we hold a hackathon the challenge is to build a Windows Phone (or Windows) app over the weekend, and then we award the “best” app with a phone etc. We walk around to each person and score their app against various criteria like quality, relevance, functionality, etc. The problem with this is that it is very formal. We aren’t in the business of rating code, and hackathons aren’t really about making the perfect app in a few hours. Hackathons are about learning and having fun.


We decided that it could be fun to let the attendees do the judging instead – but that was just as rigid and structured as us doing it. So Taylor came up with a rather interesting voting system to let attendees judge each others’ apps, which we then coded.

Continue reading


Unity3D Lightmapping on Azure in the clouds


The Oxford Dictionary defines “lightmapping” as “A process with takes an absolutely ludicrous amount of time“. And if you thought lightmapping in Unity 4 took long, then you’re in for a shock when you try 5.

If you’ve not used Unity before, lightmapping is basically a way to pre-render lighting and shadow data at design-time instead of wasting processing power at run-time. In games, you often get lights (and therefore shadows) that don’t ever move, which leads to the poor CPU having to constantly work out the lighting data every frame, even though it doesn’t need to. The answer is to bake the lighting into a lightmap. That lightmap is just a big image that essentially gets overlaid on your objects and makes it seem like there is lighting in the scene, even though there isn’t.

The problem is that this baking process can take anywhere from a few minutes (for a very small scene) to hours, depending on your scene/level and PC. So I decided to test out if I could do the processing on Azure instead. To do this I used a single reference level and baked it 8 times on each VM/PC I setup. All the settings were the same, and I created a new instance for each one (didn’t just reuse an older installation). Along with just baking, I ran some benchmarks with PassMark PerformanceTest.



I did all the tests on the following machines:

Azure A10: 8 Core Xeon E5-2670, 56 GB RAM.
Azure A11: 16 Core Xeon E5-2670, 112 GB RAM.
Azure G3: 8 Core Xeon E5-2698B v3, 112 GB RAM.
Azure G5: 32 Core Xeon E5-2698B v3, 448 GB RAM.
Surface Pro 3: i7 4650U, 8 GB RAM (256 GB storage model).
Other PC: i7 4770K, 16 GB RAM, 256 GB OCZ Vertex 4 SSD (this is my office machine).

All tests were done with Windows 8.1, Unity 5.0.1f1 and PassMark V8 build 1047.

This is what a 16 Core A11 looks like while lightmapping:A11

And a 32 Core G5:


Before showing some charts, let me summarize my observations (summaries go at the beginning right?). These Azure machines can be really, really powerful, but also really, really expensive. If you’re paying for this sort of hardware, you want to use it all. For the particular use of lightmapping it simply isn’t worth the cost. You’ve got tons of RAM and storage which Unity never touches, plus top-grade hardware at every point in the system.
If all you want to do is bake some lights, and time isn’t a major concern, just build a fast PC out of a bunch of dodgy parts – you simply don’t need the fancy stuff that Azure provides.
What I’d really like is for Azure to add a custom config where I can specify that I want lots of CPU power, but hardly any RAM or HDD space.



Don’t read too much into these values. Although I ran every test multiple times, ensured I was getting consistent results, and did everything I could to test properly, something might have gone wrong without me realizing it.

All of the standard benchmark scores (CPU, Memory, Disk) are higher is better.

Something that interested me with the CPU tests was that the G3 was “slower” than the A10. I did re-run the test a few times to make sure.



Once again, the G3 is slightly below even the A machines here. I’m not sure why, and I would have assumed that all the Azure results would roughly align (which they sort of do besides the G3).



For some reason, even though all these Azure machines have SSD’s, they seem to be pretty throttled. The G3 consistently scored WAY higher than anything else. Maybe it was just a glitch in the matrix, and Azure forgot to throttle my G3 instance. Or maybe they were throttling all my others too much. Either way, the slow HDD speed was noticeable. It took a long time to install and unzip stuff, and the CPUs definitely weren’t the issue.



The time difference between my PC and the G5 is roughly 15 minutes, which makes the G5 double the speed. 15 (or 30) minutes might not seem like a lot, but consider that this was a small reference level. Then also take into account that a game could easily have 30 levels. On my machine that is 15 hours, and doesn’t take into account that you’ll need to bake each level lots of times. And while it is baking the PC is often not useable at all.



This may or may not actually be a useful chart. Either way, it interested me because it portrays the scenario of buying/renting a dedicated machine that does nothing but bake lighting all day.
Fun fact: If you were buying all this hardware, you could buy about 18 of the CPUs in my machine for the same price as the ones in the G5, even though it only bakes double the speed. Obviously, this is just one very specific application which almost definitely doesn’t totally use the power of the G5.



Finally, cost. I couldn’t include my PC or SP3 because I have no “per hour” dollar value for them.
The A10 is clearly the best value per bake but assumes that time doesn’t matter.