Unity: the “real” version 5 just released (#Unity3d 5.2 fixes many severe issues!)

A new version of Unity is now out – – and it’s a doozy.

I don’t normally blog a blow-by-blow account, but this set is particularly interesting.

It suggests the tech team has been focussed on fixing many “critical but un-sexy” problems. That is a noticeable change in direction from the past few years. Possibly this is a one-off to get Unity 5 working properly.

If you’re still using Unity 4.x, it is finally safe to move to Unity 5.

Unity 5 is not a complete replacement for Unity 4 – there are still major featuers of 4.x that have been removed from Unity 5 and have no upgrade-path – but it’s finally production-ready (or very nearly). That … is big news!

Hilighted improvements / fixes / changes

Please note: there will be a lot of negative comments here; that is inevitable, considering most of the change-list is “things that were broken, or wrongly implemented, or poorly designed – and are now not”.

To be clear: I’m pleased and excited by the overall shape of these changes.

Graphics: Added CullingGroup API, which allows you to specify a large set of bounding spheres that are integrated into the culling pipeline and subjected to frustum and occlusion culling

Unity has (amazingly) never had built-in culling accessible by developers, which is almost unheard-of in game-engines. This suggests we’re getting towards it (although spheres are only a first-approximation for culling, and I wonder how deep the interaction is with Unity’s pipeline here. I’d assumed we’d get access to something more like BSP)

Application.UnloadLevel. Unloading scenes is now possible while the game is running. References to lightmaps are cleared but you have to call Resources.UnloadUnusedAssets() to actually unload them.

Scenes in Unity are very much FUBAR as a concept – they were created by people who had very little understanding of computer-game design and development. Ideally, we’ll see Unity remove the whole “Scene” concept in a future major release, but in the meantime this is a significant step towards reducing their weaknesses, which is good to see.

Layout elements under a ScrollRect component may not work properly

No s***, Sherlock! Yeah, most people using Unity’s “new GUI” have found it’s fundamentally broken in a bunch of places. Good to see Unity working on this, and hilighting some of the issues – but really they need to create an entire webpage listing “the following parts are broken, don’t use them – or beware if you do”.

Right now, you tend to waste hours, half-days at a time … re-discovering known bugs in Unity’s GUI.

Scene view picking in linear color space does not work for DX11 when MSAA is used (quality: fantastic)

If you’re on Windows and have the highest quality settings, this is lethal: Unity simply doesn’t work. But it’s coming in an emergency patch very soon.

Mecanim: Playable API.

If this does what I think it does, then it was essential back when Mecanim was released (3 years ago); glad to see it’s finally here.

between 5% and 30% lower CPU cost for rendering

That’s an enormous speed-up for an engine as old as Unity – this is big news. Reading between the lines, the speed up is partly a side-effect of them making it a bit more multi-threaded (which became normal for game engines many years ago).

If we thought that was a lot, wait till you see:…

Particle rendering optimizations (especially for VR), with speed improvements varying from 15% to 50%

… 50% performance improvement! Wow. Name-checking VR here is probably the key item. We keep seeing VR’s extreme performance-requirements forcing engine-makers to up their game, and dig deep to find perf boosts. The “minimum” hardware reqs for basic VR rigs are very high even now, several years after Oculus Rift launched.

UI now uses multithreaded batching & geometry generation backend

This was the minimum we expected from the “new GUI” when it launched in Unity 4.6 almost a year ago. This fix brings the GUI most of the way towards being “production ready” … ironically, 6 months after Unity changed their website to hide the existence of the “old (but works) GUI” and pretend it didn’t exist.

Added parameter QueryTriggerInteraction to all physics queries (raycast, spherecast, overlap) to allow any query to override whether or not the query should hit Triggers

This is patching a MAJOR design bug in core Unity that has plagued Unity for many years. I want to play with this some more, and see how much we can un-**** Unity’s ****ed ray-casting system using it.

(I don’t believe any experienced game-developer would have accepted Unity’s original design here – it was clearly a terrible approach that would cause never-ending head-aches when making games. It mixed concepts that were very obviously unrelated and distinct)

Fixed Function shaders work on all platforms now (including consoles)

This one has been blogged about extensively by some of the graphics team, IIRC.

In my experience, Unity’s shaders have been OK, with a few that were terrible (e.g. all the Mobile ones), but the framework which holds them has generally been excellent: it’s isolated us from the pain and suffering of GPU-specific shader bugs. This house-cleaning doesn’t make much (if any) difference to most of us, but apparently keeps Unity’s internal code clean in a way that will facilitate rapid changes and improvements going forwards.

2D Rect Mask

TL, DR: “we finally implemented masking properly in the new GUI”.

See previous comments on the new GUI, and how it’s getting much closer to production-ready.

UI: Dropdown control

Yes, really – Unity has finally added the “dropdown”, which has been a global expectation in UI design for 20+ years (it was made compulsory in web-browsers back in the 1990’s).

Editor: Remove legacy Mac OS X corner window resize behaviour

Apple told devs to remove this … um … about 3 or 4 years ago? At first, it was broken (couldn’t resize windows), then it was annoying (Unity added optional resizing on all edges, but put an illegal resize-hot-corner in bottom right that broke all EditorWindow code, because they made it a private API).

Working around that on Mac … forced you to mildly break things on Windows.

TL, DR: custom editors (as found in many/most of the best Asset Store plugins) will now be a little less-broken across the board.

Substance … All crashes and hangs at build time, level load/change time, playmode entry/exit should be gone

Yay! I’ve not been using Substance, but I’ve met several developers who’ll be breaking over the champagne over this, given how miserable they’ve been about crashes and hangs with this in the past.

CanvasRenderer now takes a Mesh instead of List this allows for the use of imported meshs as part of the UI

Without this feature, the new GUI was not usable in most non-trivial games. It’s hard to over-estimate the importance of this for declaring the new GUI production-ready.

Allow sprites to be dragged into scene view in 3d mode

Small but sweet. It’s a little thing, but makes a big difference to the frustration level of the user; in my experience, these things are often the real reason why you sacrifice the cost-savings and benefits of your own engine and use something like Unity instead.

i.e.: with your own engine, you can’t afford the time/money to polish every small interaction; 3rd-party game-engines can shine here, and should take more advantage of it.

I sometimes mention stuff like this as suggesting that Unity’s senior management team are out-of-touch with their product. Unity’s early community loved it largely because of small things, but as Unity grew, the company stopped sweating them. I suspect time will eventually tell that was a huge strategic mistake.

Improved Export Package window (now uses a proper tree view)

This window hasn’t correctly worked for at least three years; converting it to a “proper tree view” might – finally! – make the “Export Package” function do what it’s defined to, instead of exporting the wrong things, breaking keyboard and mouse interactions, etc.

(most of the bugs appeared to be a side-effect of the non-maintained, half-implemented, custom tree view code)

Make sure ObjectField and Object Selector shows icons for game objects and prefabs

Co-incidentally, I tweeted about this recently: Unity could make their engine noticeably faster to develop with if they provided visual feedback on these fields.

It’s embarassing, almost shameful, how poor the UX is on these fields today. By the sounds of things, this patch merely makes them “less crap”, rather than fixing them – but the last 5 years has been so awful that any improvement is welcome!

Selection.selectionChange callback triggered when selection changes

To call this “important” is somewhat of an understatement.

Substantial areas of the Editor API’s are surprisingly poorly maintained by Unity. The bugs undermine people each time they try to use one of Unity’s overwhelmingly greatest features: its extensibility.

Graphics: Added a quality setting ‘Shadow near plane offset’ to allow working around shadow pancaking artifacts

If this does what I suspect, it will make it trivial to fix a lot of common, frustrating “why do my shadows suck? OMG! UNITY SUXXS!!!!” situations.

Mecanim Improvements


I don’t use Mecanim: it’s been slow, clunky, buggy – and it solved the wrong problems at launch. It felt more like a marketing excuse rather than a developer feature. For me, working x-platform and often on mobile: not very useful.

However, looking at how long the list of fixes is … it might finally be worth using it. In context of all the other changes we’re seeing – maybe production-ready for general use now?

(modulo: the performance. Last time I checked, it was still way too slow for cross-platform games unless you were happy to have a relatively small number of animated objects)

Go check it out! If you’re a long-time Mecanim user, let us know what you think of this list of changes!

Now a TerrainData object embedded into a scene (created by script) allows scene objects being selected as tree prefabs

Unity’s Terrain system was implemented using a nasty, ugly hack that should never have been used.

As I understand it, that was in itself an attempt to workaround some problems with the fundamentally broken – and allegedly “unfixable” – Serialization system that is core to Unity, but is too much code for anyone to fix (and will be thrown out / fixed / replaced around Unity v6 or v7. Maybe).

This change reeks of a “workaround to a workaround”: you can’t create TerrainData in the scene (which should be the ONLY option!), but you can artifically create one if you write a script to do it for you. Either way, it’s good news – TerrainData Assets are a common source of project-corruption, because they’re abusing a feature that wasn’t intended for this.

Stacktrace logging: Allow to log full (native/managed) stack trace when log is printed, the option is available in the console window in top right corner popup menu.


I frequently discover major bugs in Unity core; there is never anything I can do about it because Unity strips / deletes all stack traces (in most cases) before outputting anything.

If this fix does what it says on the tin … WOOOHHHOOOO! … we can finally workaround Unity crashes (by debugging them!) and give Unity much more detailed and accurate bug-reports (leading to greatly increased chances of them fixing bugs).

Cross those fingers…

Fix Cursor

As I recently tweeted, Unity’s support for custom mouse-cursors was recently broken. That’s a huge pain given most games today use custom cursors. Several fixes here, looks like they’ve cleaned them all up (I hope).

Fix possible data loss on Windows when renaming folder with locked files


Fix occasional recycle bin bypassing when deleting assets on Windows


Serialization: Fixed not being able to serialize a field called “Base”


UI: Stop disabled graphics from blocking raycasts

If this is what I think it is, it’s another example of “should have been fixed before 5.0 was released” – but I’ve had so many problems with the bad system of Unity raycasts that I go out of my way to avoid them anyway.

Core: Fixed hang when passing large arrays to the Undo system

Sounds unexciting, but … I think I’ve encountered this on some of my projects: unexplained hangs that came out of nowhere and destroyed my ability to keep working on one particular game, related to Undo.

Note: I keep saying this in public: Unity’s Undo system simply Does Not Work, it’s appallingly buggy. As far as I can tell, the person who originally wrote it had little or no experience of what they were doing, and didn’t consult the literature to find out how to implement Undo systems correctly.

Some days, I genuinely feel it would be better for everyone if Unity removed the “ctrl-z” keyboard combo, because so often when you press those letters you corrupt your game project. A lot of the time, you don’t notice that Unity has just corrupted your project – not until much later, and then you don’t realise that it was Unity’s broken Undo that caused the corruption. Instead, you blame yourself, or your co-workers. Seriously, it’s that bad.

(I’ve stopped bothering logging bugs against it)

Importing: Changes to scripts are now correctly processed synchronously, fixing a range of issues with scripts relating to asset processing at import time

Subtle, but … I suspect this fixes a LOT of bugs we see on larger Unity projects, where you’re frequently hot-loading complex sets of scripts, assets, inter-related dependencies, custom asset-processors, etc.

…the end

So that’s it. What do you think? Any other major items you notice in the release notes that will make your life significantly better?

What’s still broken?

3 replies on “Unity: the “real” version 5 just released (#Unity3d 5.2 fixes many severe issues!)”

It’s a step in the right direction, but has a bunch of silly bugs that should not get through QA.

If you turn on ‘alphabetical sorting’, the editor hangs or crashes exiting play mode. #sigh

i get a ton of random crashes and in general 5.2 is still far from ‘production-ready’, even factoring in the fact that we don’t use the new UI.

Have projects from 5.1.x that have complete API breakages from 5.1 to 5.2 (whole classes / systems deprecated in the UI system between point releases). This just reeks of half-baked sytems to me.

They need to spend quite a while focusing on stability imho. 4.6.x is so rock solid in comparison – maybe by 5.3 or 5.5, things will be stable enough for me to consider risking it on a ‘real’ project, but in the meantime, 5.x is for prototyping and tests and a serious risk for anything larger scale.

I do like the native visual studio integration now though – that’s pretty slick ;}


I only downloaded it last night, didn’t get to play with it much.

It seemed to be working fine with an existing project I opened – there was a long import delay (going from 5.1 to 5.2 needed a conversion!! that was a surprise).

But I only checked project was running, and a few minor tweaks to some existing code.

Some good news maybe: first patch sounds like it’ll be out very soon


I only downloaded it last night, didn’t get to play with it much.

It seemed to be working fine with an existing project I opened – there was a long import delay (going from 5.1 to 5.2 needed a conversion!! that was a surprise).

But I only checked project was running, and a few minor tweaks to some existing code.

Some good news maybe: first patch sounds like it’ll be out very soon

Comments are closed.