Unity3d 在 iPhone 上的性能

发布于 2024-11-28 10:16:08 字数 612 浏览 1 评论 0原文

我对使用 Unity3d 开发应用程序非常感兴趣。我喜欢这样一个事实：我可以开发一次并将应用程序移植到多个平台（Mac/Windows/iPhone/Android），而且在我的 Mac 上的性能似乎相当不错。

这是我第一次为 iPhone 编写应用程序，我对未来的性能问题感到好奇。我想我肯定会在 iPhone 上使用 Unity3d 作为原型，但我想知道构建 iPhone Unity3d 应用程序是否会像用 Objective-C 编写的本机应用程序一样有效地使用 iPhone 资源。

Unity3d 网站似乎暗示 Unity3d 算法已优化，我想如果我在 Unity3d 论坛中提出这个问题，我会得到这样的答复。理想情况下，我有兴趣听取使用 Unity3d 和 Objective-C 构建应用程序的人的意见，并且可以对两者进行比较。

让我思考这个问题的讨论是 Andrew 和 Peter Mortensen 对有关 iOS 开发成本的问题的回答，开头是“开发 iPhone 应用程序有比学习 Cocoa 更容易的方法”。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

丢了幸福的猪 2024-12-05 10:16:08

Unity 中有一些有助于移动开发的特定资源，包括专为移动设备设计的资源、着色器等。

您当然不会希望将“未优化”的 PC 质量资产放入 Unity 项目中，然后将其导出到 iOS 平台，因为这样会导致性能不佳/不可靠。您想要做的是开始使用与您想要的游戏质量相似的资源构建场景，然后查看真实设备上的性能。这将使您了解您的游戏在制作过程中可以达到什么水平的性能。

请记住，iPhone、iPad、iPad2 等的性能会根据您正在执行的操作以及所触摸的功能而有很大差异。虽然 Unity3D 已针对各种场景进行了大量优化，但您当然可以执行诸如雾化之类的操作，从而提高填充率（平台的已知限制）并最终导致可怕的性能。

纯粹用 Objective-C 构建应用程序是否可以获得更高的性能？如果您在发动机开发方面拥有适当的技能，可以根据您的特定要求设计特定的技术实施 - 当然可以。

您只需要决定是否要花时间编写技术或构建产品。大多数选择 Unity 的人这样做是因为您获得了一个非常出色的引擎，其性能是大多数人无法超越的（尝试构建自己的景观引擎），同时获得了极好的上市时间……而且确实是上市时间在大多数情况下这确实很重要。

回复收藏 0 原文

大姐，你呐 2024-12-05 10:16:08

这是一篇旧帖子，但我想我会回答它，因为这里没有人真正理解它。

请务必记住，Unity 的内部核心工作原理完全是原生的。物理引擎以及因此处理碰撞的所有内容。遮挡系统（本影）。整个渲染引擎的核心。所有这些都是用 C/C++ 编写的，并在任何平台上以全原生速度运行。 AmitApollo所说的完全不正确，虚幻引擎3与unity相比根本不是更直接的“原生”。 Unity和Unreal引擎3，以及任何其他3D引擎，如Ogre或cocos3d，它们的核心渲染系统都是用c/c++编写的。其中一些引擎可能比其他引擎具有更好的某些内部渲染算法，因此可能会产生更好的性能，但这与它们是否是“本机”无关，因为内部核心渲染系统对于所有引擎来说都是本机的。

物理引擎的内部工作原理也是用 c/c++ 编写的，因此 UE3 和 Unity 中的物理引擎都以“全原生速度”运行。

EpicCitadel 演示也没有表现出比 iOS 上的 Unity 更高的技术实力或性能。城堡演示的大部分“视觉冲击力”仅仅来自于它确实是优秀的艺术品。 citadel 演示并没有推动任何比 Unity 在 iOS 上可以处理的顶点数更高的顶点数，citadel 演示也没有演示比 Unity 在 iOS 上可以处理的任何更高级的着色器或光照技术。事实上，Unity 有更多的例子展示了比虚幻引擎 3 所展示的更先进的移动渲染技术。看看像 Shadowgun 或 BladeSlinger 这样用 Unity 制作的游戏，这两款游戏都展示了比虚幻引擎 3 更先进的移动渲染技术。光探针、具有半透明和法线贴图的移动 BRDF 着色器以及实现良好的动态移动阴影等等。应用商店中最成功的3D游戏绝大多数都是Unity游戏，Unity因此在Unity的移动渲染性能和能力上投入了大量的研发。

现在 Unity 是用 C# 和 Mono 编写的脚本。它的运行速度确实比本机代码慢，据大多数估计，在 iOS 上慢了大约 50%。但您必须记住，您在此代码中仅执行游戏逻辑。您不会在 Unity 中使用 C# 和 Mono 编写任何代码来处理其内部渲染系统的工作，也不会处理物理系统的内部工作。您只需用 C# 编写游戏逻辑，然后与渲染和物理核心交互，然后以全原生速度执行。 Mono C# 确实比原生 C++ 执行得慢，但如果你聪明地编程，我想你会发现这根本不是一个障碍，因为你只在 Mono C# 中执行游戏逻辑，而游戏逻辑不一定占用 CPU 资源。根据我的经验，仅靠 Mono C# 编写的游戏逻辑，让 iPad 2 的帧率降至 60 fps 以下确实相当困难。我实际上从未受到过任何阻碍。

如果我们要与虚幻引擎 3 进行比较，请记住，UE3 也被设置为使用非本地语言 UnrealScript 对其游戏逻辑进行编程。 Unrealscript 是一种非常类似于 Mono C# 或 Java 的语言，其中 UnrealScript 被编译为字节代码，然后在运行时进行解释。这意味着，就像 Unity 一样，游戏逻辑并不是 UE3 中的“原生”逻辑。

现在如果你看这里：
http://lua-users.org/wiki/LuaVersusUnrealScript
这是在使用整数的简单算术运算上比较 UnrealScript 和 C++ 的基准。它表明unreal script的速度是C++的1/4到1/20。

然后看看这里：
http://www.codeproject.com/Articles /212856/头对头基准-Csharp-vs-NET
如果您向下滚动到 C# vs C++ 简单算术基准测试。它表明 Mono C# 执行简单 int 运算的速度是 C++ 的 3/4。使用浮点进行简单算术时，Mono C# 的速度约为 1/2。 int64 和双基准对我们来说并没有多大意义，因为通常您永远不会在 iOS 游戏逻辑中的性能关键代码中使用它们。

现在，那里的其他基准确实显示 Mono C# 有时性能只有 C++ 的 1/20。但这些都是通过非常具体的测试进行的，实际上我能找到的最好的同类基准就是那些简单的算术测试。

确实如此，因为 Unity 的脚本在 Mono C# 上运行，而 UE3 在 UnrealScript 上运行。 Unity 实际上是一个可以为您提供更好的游戏逻辑代码性能的引擎。

认为 UE3 比 iOS 上的 Unity 更先进、提供更多性能或更强图形功能的想法根本不正确。事实恰恰相反。

现在，如果您使用像 cocos3d 这样的东西，您可能会获得更好的性能，因为您的游戏逻辑也可以用 C++ 原生编写，这是事实。但我认为使用 c# 这样的脚本语言来处理游戏逻辑的好处远远超过了性能损失，而性能损失通常不是问题。也就是说，为游戏逻辑使用脚本语言的好处是，它可以为您提供更快的设计迭代，这在制作游戏时非常重要，因为事情可能非常古怪，并且您必须重新编译和测试代码的频率。

然而，在Unity中，使用Pro版本编写本机代码插件确实很容易。因此，如果您确实有一段需要以本机速度运行的性能关键代码，您可以用 C++ 编写它，将其编译为本机库，然后从 Mono C# 调用它。

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#.

回复收藏 0 原文

濫情▎り 2024-12-05 10:16:08

另请记住，如果您的目标是所有 iOS 设备，则重型 GPU 图形的差异意味着 iPhone 3GS 到 4、然后从 4,4S 到 iPad2 等之间存在巨大的性能差异。 3 甚至新 iPhone5 或 iPad4 上的某些游戏也能以比前代产品更高的 FPS 运行。请记住保持多边形较低，当然在您的地形中保持较低的分辨率，甚至像像素误差这样微妙的东西也会产生巨大的影响。雾总是会产生压力。纹理> 512x512 可能会导致问题，对于多个光源也是如此。没有光照渲染并烘焙阴影和高光的速度要快得多。我还发现，以本机分辨率运行而不是最佳性能可能会降低性能（Unity 4）。广告牌、遮挡剔除也是您想要查找的主题。看起来不错和跑得慢之间只有一线之隔。

如果性能对您来说是个问题，您可能需要完全不同的引擎。像虚幻引擎 3 这样更直接的“原生”引擎的功能令人惊叹。而且它不需要太多开销就可以做到这一点。案例和要点，在 iPhone 4 或 3GS 上运行的 Epic Citadel 演示应用程序。 Unity 中类似的东西会很慢，而且看起来不太性感。

回复收藏 0 原文