Unity3d performance on iPhone

Question

I am really interested in using Unity3d to develop an app. I like the fact that I can develop once and port the app to multiple platforms (Mac/Windows/iPhone/Android), and the performance on my Mac seems to be quite good.

This will be the first time I write an app for iPhone, and I am curious about performance issues down the road. I think I will definitely use Unity3d on iPhone for a prototype, but am wondering if building an iPhone Unity3d app will use the iPhone resources as efficiently as a native app written in Objective-C.

The Unity3d site seems to suggest that Unity3d algorithms are optimized, and I thought that if I asked that question in the Unity3d forums, that would be the kind of response I would get. Ideally, I'd be interested in hearing from someone who has built an app in Unity3d and Objective-C and can compare the two.

The discussion that got me thinking about this was Andrew and Peter Mortensen's response to a question about iOS development cost, which begins "There is a much easier way to develop iPhone apps than learning Cocoa."

Answer 1

There are specific resources in Unity that will help with mobile development including resources, shaders, etc. that are specifically designed with mobile in mind.

You certainly won't want to take 'unoptimized' PC-quality assets and drop them into a Unity project and export that for the iOS platform as you will ensure poor/unreliable performance. What you want to do is start building out a scene using assets of similar quality to those you want for your game and then seeing what the performance is on a real device. This will give you a feel for what level of performance you can expect from your game in production.

Remember that the performance of a iPhone, iPad, iPad2, etc will vary wildly depending on what you're doing and which features you're touching. While Unity3D has been heavily optimized to deal with a variety of the scenarios, you can certainly do things like fogging which push the fill rate (a known limitation of the platform) and end up with horrendous performance.

Could you possibly get more performance out of building your application purely in Objective-C? If you have the right skillset in engine development to design a specific implementation of technology for your specific requirements - Certainly.

You just need to decide if you want to spend your time writing technology or building product. Most people who choose Unity do so because you get an exceptionally good engine which most people cannot beat the performance of (try building your own landscape engine), while at the same time getting exceptional time to market... and really its time to market that really matters in most cases.

Answer 2

This is an old post, but I figured I'd answer it because no one here has really got it quite right.

It's important to keep in mind that the internal core workings of Unity is entirely native. The physics engine and resultantly everything dealing with collision. The occlusion system (umbra). The entire rendering engine core. All of that is written in C/C++ and runs at full native speed on any platform. What AmitApollo says is not correct at all, the unreal engine 3 is not more direct 'native' at all when compared to unity. Both Unity and Unreal engine 3, as well as any other 3D engine like Ogre or cocos3d, their core rendering system is all written in c/c++. Some of these engines may have certain internal rendering algorithms implemented better than others, and may thus produce better performance, but this has nothing to do with whether or not they are 'native', because the internal core rendering system is native for all of them.

The internal workings of the physics engine is written in c/c++ as well, and thus the physics engine in UE3 and Unity both run at 'full native speed'.

The epicCitadel demo also does not show greater technical prowess or performance than Unity on iOS. Much of the 'visual impact' of the citadel demo comes simply from the fact that it is really good artwork. The citadel demo is not pushing any higher vertex count than what Unity could handle on iOS, the citadel demo is not demonstrating any more advanced shader or lighting techniques than what Unity can do on iOS. In fact there are more examples of Unity showing off more advanced mobile rendering techniques than what Unreal Engine 3 has demonstrated. Look at games like Shadowgun or BladeSlinger made in Unity, both these games demonstrate more advanced mobile rendering techniques than what Unreal Engine 3 has shown. Light Probes, Mobile BRDF shaders with translucency and normal mapping and well implemented dynamic mobile shadows to name a few. The vast majority of the most successful 3D games in the App store are Unity games, and Unity has thus put alot of R&D into Unity's mobile rendering performance and capabilities.

Now Unity is scripted in C# and Mono. Which does run slower than native code, about 50% slower on iOS by most estimates. But you must keep in mind that you are only doing game logic in this code. You are not writing any code in C# and Mono in Unity that deals with the working of it's internal rendering system, nor the internal workings of the physics system. You only write game logic in C#, that then interfaces with the rendering and physics core, which then executes at full native speed. Mono C# does execute slower than native C++, but if you program intelligently, I think you will find this is hardly a hindrance at all because you only do game logic in Mono C# and game logic is not necessarily CPU heavy. In my experience, it is really quite difficult to make an iPad 2 drop below 60 fps on purely game logic written in Mono C#. I have never actually been hindered by this at all.

If we are to compare to Unreal Engine 3, keep in mind that UE3 also is set up to have it's game logic programmed in a non-native language, UnrealScript. Unrealscript is a language much like Mono C# or Java, where UnrealScript is compiled down to byte code then interpreted at runtime. Meaning, just like Unity, game logic is not 'native' in UE3.

Now if you look here: http://lua-users.org/wiki/LuaVersusUnrealScript That is a benchmark comparing UnrealScript to C++ on a simple arithmetic operation using ints. It shows that unreal script is 1/4 to 1/20th the speed of C++.

Then have a look here: http://www.codeproject.com/Articles/212856/Head-to-head-benchmark-Csharp-vs-NET If you scroll down to the C# vs C++ Simple arithmetic benchmark. It shows Mono C# is 3/4 the speed of C++ doing simple int arithmetic. Mono C# is about 1/2 the speed when doing simple arithmetic with floats. The int64 and double benchmarks don't really mean much to us because typically you'll never use those in performance critical code in iOS game logic.

Now other benchmarks on there do show Mono C# at times having as bad as 1/20th the performance of C++. But these are through very specific tests, really the best apples to apples benchmark I could find are those simple arithmetic tests.

So really, since Unity's scripting runs on Mono C# and UE3 runs on UnrealScript. Unity is actually the engine that will offer you radically better performance in game logic code.

The notion that UE3 is any more advanced, or offers any more performance, or any greater graphical capability than Unity on iOS is simply not true. Quite the contrary is true.

Now it is true that if you used something like cocos3d you could potentially get better performance because your game logic could be written natively in C++ as well. But the benefits of working with a scripting language like c# to do game logic I think far outweighs the performance loss that is generally never an issue. Namely the benefits of using a scripting language for game logic is that it offers you faster iterations of design, which when doing games is really critical due to how quirky things can be and how frequently you have to recompile and test code.

However, in Unity, it is really easy to write native code plugins with the Pro version. So if you ever do have a piece of performance critical code that needs to run at native speed, you can write it in C++, compile it to a native library, then call that from Mono C#.