Search Unity

3.2 Mobile EnhancementsLast week, we started talking about Unity 3.2 by giving you a look at one of the updated Standard Assets. We’ll have more to show soon, but in the meantime we wanted to tell you about some of the optimizations that have been made to deliver great looking high-performance graphics on iOS and Android.

Precision of Shader Computations
Unity 3.2 makes much better use of different precision shader computations in OpenGL ES 2.0 shaders. This alone results in a 50%-150% speed increase on more complex shaders. Our GLSL Translator & Optimizer has been extended so that float/half/fixed types in Cg map to highp/mediump/lowp precision in GLSL, and we’ve updated all built-in shaders to use appropriate precision.

Normal Mapping
We’ve made several tweaks to make normal mapping faster. On desktops, we use “DXT5nm” compression for normal maps, where two normal components are stored and third is computed in the shader – this works great because it allows using DXT5 on the normalmaps. However, the extra computation is not very good for mobile platforms, so we’ve changed the normal map compression scheme there. We’ve also implement assembly optimized skinning for normal mapped meshes — this is now 4x faster than before.

Built-In Shaders
Unity 3.2 will ship with new shaders that are optimized variants of existing built-in shaders. You’ll be able to find them under the “Mobile” category (but they work on other platforms as well!). These new shaders have a few limitations, but the upside is increased performance — the Mobile/Bumped Specular, for example, is 5.2x faster than the Bumped Specular currently shipping in Unity 3.1 (tested on iOS).

Other Optimizations
There are a number of other improvements that make Unity-created mobile content run faster in 3.2. For example, we’ve optimized the internals of the OpenGL ES 2.0 renderer for lower CPU overhead. We’ve also changed how Unity handles alpha-testing so that those objects are rendered after all fully opaque ones. These and other tweaks and adjustments are all designed to help you get the most out of your mobile game.

36 replies on “Coming in 3.2: mobile graphics optimizations”

@Matt: yes, of course skipping some mesh components (like normals or tangents) saves size (game size, reduces loading times, reduces memory consumption).

We have mesh compression for a long time already (choose it in mesh import settings). This only saves game data size currently though (mesh data components are quantized over their range to some number of bits, depending on the chosen compression level). But it does increase loading time a bit, and does not affect runtime memory consumption.

what about mesh sizes?
in teh FBX importer settings of a mesh asset in Unity, if we turn off Normals do we save on mesh size?

Perhaps having more control with mesh imports? eg) being able to compress UV and positions to 16bit we could significantly reduce the memory footprint of meshes.Of course the artists on a project doing this would need to be aware… but operating within 16bit ranges for UV’s and vertex positions shouldn’t be a problem for most mobile mesh assets.

We did this at one place I was at and it really does help in mesh size… had something similar been considered with Unity?

Any update on a release date? I was going to submit my game to the app store any day now and I’m wondering if I should wait for the update

@Jorsalsa: Yes.

@BATMAN: I’m not sure which problem you’re talking about. In 3.1 we do have a bug with OpenGL ES 2.0 + semitransparent fixed function shaders + Fog (the problem does not exist on other platforms or OpenGL ES 1.1). That problem will be fixed in Unity 3.2. If you’re talking about something else… bug report number or it did not happen! ;)

Very exciting news. Question on importing assets: Will this version support the Blender 2.5 .blend file import into Unity?

Which game is that on the iPhone there? I see it a lot, and it looks pretty cool, but I can never find it.

And Unity is already working in NaCL.

See previous blog posts. We will release it as soon as NaCL hits live browsers. We’ve been doing a lot of close work with google on this tech.

@Joachim: It would seem there is a misunderstanding. Here is a communication I received from Unity support on 12/7/2010:

>”I checked up on the progress of this bug today using the
> bug number that was given in the forum thread. It has been
> investigated by our QA team and as of today has now been
> issued to our development team with the highest priority for
> fixing.
> Sorry that there is no good news regarding this at the
> moment. When the fix for this comes I would expect that it
> would be identified in the release notes as it is a show
> stopping bug.”

To me that indicates that the problem was reproduced. I spent two weeks tracking that issue down and developing a barebones testcase that demonstrated the issue quite simply so that support would be able to reproduce it.

Today I received an e-mail stating that the problem is not reproducible on iOS 4.2.1 specifically. That, however, is not especially helpful since I don’t want to limit my app to just that version of iOS.

I’d really like to get some clarity on what is happening with this bug.


> Can you say if the Graphics.Blit() bug that causes iOS devices to reboot (more details here and reported case #383751) will be fixed in this release?

The bug was replied to as not reproducable. You have not responded to the mail so far. Might want to do that if you want to get it fixed. Which requires that you send a simple project folder that reproduces the issue.

I know that this post is not about it but (:p)
Any news about bluetooth support for iOS ?

How about Linux support and quad-buffer stereo? There’s a significant professional market out there that would benefit from both features.

We are actually using Unity3d for some internal visualization apps but, as it stands, it won’t cut it as our VR frontend. Which is too bad, since Unity3d is a otherwise perfect fit for our requirements.

Could we have a list of optimizations / new features for the web player too?

I haven’t looked but I’m guessing from this post that in e current version alpha test is done via discard in the shader I stead of sort and blend? That would point to some pretty big performance improvements as all the depth buffer optimizations would be on when not using discard.

We are entering RC1 this week. So hopefully it will be shipping this month. No promises though…

Comments are closed.