在Unity引擎中没有刚体的情况下使用碰撞检测
这篇文章的主要目的是让你了解如何在Unity引擎中没有刚体的情况下使用碰撞检测。
第一步 介绍
我们实现了一个简单的例子，在这个例子里面，只有垂直运动会被检测，但是通过修改脚本以及在场景中添加物体（或者改变立方体的位置），其他方向的检测也是可以实现的。
Unity是一个3D游戏引擎，它里面内置了一个物理引擎PhysX，这是由Nvidia提供的一个物理引擎。
物理模拟会应用于那些附有刚体组件的游戏物体上。
大部分情况下它是被用于碰撞检测。
假设我们只需要从物理引擎里面得到碰撞检测仿真的信息，那么使用物理引擎只进行碰撞检测可能会减少整体的性能。这有两种解决方法:
第二步 解决方案
解决方案- 1
使刚体具有运动学特性并捕捉触发事件。
解决方案 - 2
不要使用刚体(这可能是最好的解决方案)! ! ! !
第三步 避免使用刚体
那使用什么来代替刚体呢？
射线投射就是一个非常好的选择。这是由Unity引擎提供的众多丰富功能中的一种。而且这个功能还不怎么耗费计算资源。你可以在每一帧中投射几百条射线出去还不会对游戏的性能带来太多的影响。这种方法会从起点（用户指定的）到终点（也是用户指定的）投射一条射线，然后确定这条射线是否与任意的碰撞体相交。
我们可以使用这种方法来处理碰撞检测，通过在x和y轴上投射射线来获知游戏物体周围的环境信息。
我们将遵循下面的步骤:
获取游戏对象的方向信息。
投射射线。
通过碰撞结果来确定碰撞信息。
简单的射线投射代码如下所示：
在上面的函数调用中，第一个参数是射线的起点，第二个参数是射线的方向，第三个参数是射线的长度。
在Unity引擎中可以得到的结果如下所示：
让我们举个简单的例子来说明下这段代码。当一个立方体与另外一个立方体发生碰撞的时候，我们让这个立方体退回去。
1.如下图这样摆放三个立方体。
2.给这三个立方体添加盒子碰撞体。
3.给位于两个立方体之间的那个立方体添加CollisionDetector脚本（也就是上图中选中的那个立方体）。
4.在CollisionDetector脚本中添加代码来让这个立方体再与上方或者下方的立方体发生碰撞的时候会反弹回去。
3.1 CollisionDetector.cs
3.2 对上面代码的解释
NoOfRays 和Moving force都是公有的变量，因此它可以在运行时根据需要来进行改变。确保立方体的移动速度不会超过上方的立方体和底部的立方体之间的距离。
DirectionFactor会乘以运动动力和射线的方向，这是因为它就是用于决定方向的。一开始的时候它的值是设为向上(y轴正方向)的方向。一旦移动的那个立方体与其他立方体发生碰撞的话，那么这个移动方向就会反过来。可以按照改变 direction vector来响应的改变立方体的移动方向。DirectionFactor只用于反转方向。
我希望当你在Unity引擎中不使用刚体来进行碰撞检测的时候，这篇文章能够对你有所帮助。如果你有任何关于Unity的问题，请在评论中让我知道。我将尽快给你答复。
【版权声明】
原文作者未做权利声明，视为共享知识产权进入公共领域，自动获得授权。
立即阅读相关好文章
责任编辑：
声明：本文由入驻搜狐号的作者撰写，除搜狐官方账号外，观点仅代表作者本人，不代表搜狐立场。
专业游戏开发社区
服务广大游戏开发者，为开发者们解决游戏开发中的难题
今日搜狐热点如题，只安装linux系统那种Unity3D在使用上有哪些优点？ ubuntu系统怎么玩unity3d游戏 - 小小知识站
Unity3D在使用上有哪些优点？ ubuntu系统怎么玩unity3d游戏
描述：1、打开自己的unity3d游戏项目，File--BuildSettings...2、文件导出为32位或者64位的，根据自己的ubuntu的版本决定。点击左边的PC，MacLinux...，右边的target platforn选择linux，architecture选择x86_64(因为我的ubuntu是64位的)，完成后点击下面的build。3、打开你要保存的文件夹，填写文件名，然后点击下面的保存。4、进入ubuntu把unity3d导出的linux版本游戏项目复制到linux的用户目录下，例如我这里...
Unity3d个人觉得网页游戏，手机游戏，对于各个平台支持都很好。并且支持flash，网页运行再也不用安装浏览器插件。这块做的不错。开发人员起点比较低。基本的资料文档都很丰富了。缺点就是画面不给力。灯光、画面各方面在这三个引擎里都是最差的，并且对于美术人员来说，做开发不是很好上手。很简单的一个材质。都要去写shader。。UNITY3D现在已经成为了众多团队的首选3D引擎。 并且，随着Unity3D &&&&4.3的发布，原生的2D支持也让人大开眼界。虽然Unity3d的原生2D功能还有很长的路要走，但也阻挡不了它称霸当下。2011年中，公司的引擎项目停止之后，我的目光便转到了U3D的身上，经过几番挣扎后，终于对基于组件式的对象模型有了新的认识。
而如今，这种模式，成为了我最推崇的模式。 因为它能解决我在设计引擎对象时的纠结。 而这些纠结，是我在先前的引擎开发中，一直不能优雅地解决的。首先，我们来说说U3D的好处。可能总结得不够完善，如果有不足的地方，就表示我自己没有体验到。一、可定制的IDE环境U3D这种ALL IN ONE的设计思路，我在一个叫神咒的代码中见到过。 集所有编辑器于一身。
虽然神咒的编辑器不能自由扩展，但由于是公司内部的引擎，所以，它的使用，也很方便。
比如，在场景中突然想要对一个模型的材质进行编辑，则选中此模型，右键，弹出材质编辑器即可。 U3D的组件式思路，将这种关系变得更加紧密。
你都感觉不到自己在使用一个材质编辑器。 你会觉得，你是在操作这个模型本身。 它的材质，它的碰撞器，它的对象结构等等。回想一开始进入游戏行业的时候，天天啃着代码。 当时觉得代码就是一切，各种认为很牛X的代码，都忍不住读上一番。
而随着时间的推移，特别是经过项目的洗礼后。 突然发现编辑器是多么的重要。
就我做的第一个页游来说，起手前两个星期，我们就做了动画编辑器，场景编辑器。而最终证明，因为这两个简陋的编辑器，使我们后面的工作变得更加容易。因此，一个好的引擎，必定得先有一个功能完备的编辑器。二、基于Mono的开发脚本C/C++无疑是图形界的宠儿，也没有人想过用另一种语言来替代它。即使是U3D，亦是如此。
但是，早期使用C/C++编写的引擎，都理所当然地使用C/C++来作为上层逻辑的开发。 又有一些，采用了纯脚本的模式。比如Python,LUA。
脚本的好处在于更低的编码成本(经过仔细研究，我发现，这是由于写脚本语言的心态和写C++的心态导致的。
写C++的时候，总是想着代码的复用度，而在脚本的时候，很多时间会认为，这个脚本，就是为这个对象服务的，那我就按照策划需求来写就可以了。
我想，这也是许多时候，脚本语言存在的意义。特别是早期引擎中，使用脚本来处理一些关键的事件响应)。
而大家熟知的虚幻引擎以及有一个名不见经转的Torque，则自己整了一套开发语言。 我想，它们的目的，就是为了使大家能够以一种更安全的方式来编程，
C++一不小心，则会带来内存和效率问题。 它的使用成本，人员成本其实是高于其它语言的。 Mono C#
JS,BOO的出现，再一次让大家的眼睛一亮，原来，引擎可以这样整。Mono的桥接，使得高效的C++图形引擎与带GC的内存安全语言进行结合。不仅减少了安全隐患，也使得大家编写跨平台代码时更佳容易。
同时，这类语言的反射机制，更适合做编辑器。而比起先前的一些DIY语言和像LUA这样的小巧型语言，Mono使脚本编程可以进行DEBUG，而不单纯的靠PRINT输出。这里就顺带说一下三个语言的区别C# 这是我见过的大型项目中使用得最多的语言，也是我比较喜欢的语言。 因为它和C++很像，同时严格的类型和语法检查。JS 在帮一些朋友做小东西的时候，使用过这个语言，由于mono自带的提示功能，写起来还是挺顺手。 但总给我一种摸不着头脑的感觉。
并且U3D给的JS，不是严格的JS，有些语法不支持，而有些语法又很特别。BOO 完全没有使用过，貌似也很少有人使用。三、基于组件的对象系统这是一个我最喜欢的系统，我也使用irrlicht引擎山寨过，山寨的过程中，几乎看完了它的组件参考手册，使我对U3D引擎的组件系统又有了新的认识。
同时，目前公司自主研发的引擎，也是这样的思想。 不管我是在工作中，还是业余捣鼓都受组件系统的影响。 慢慢的，喜欢上了这种对象模式。之前在做一个RTS游戏项目的时候，参考了著名开源项目 0.A.D的代码。 当时只是为了去寻找LOS和多单位协同寻路的方案。
但在参考其代码的时候，发现了它整个系统，都是基于组件式的。又一次，对组件式有了好感。 而经过仔细思索后。 回到了我一直坚持的子系统划分法的游戏框架。
当我不禁感叹，原来，自己也一直是在组件式。 只不过，我的组件式，是MANAGER方式，MANANGER内部进行对应的实体管理、。
比如，背包系统，则只负责玩家背包数据，背包使用，背包相关的功能。 不管是数据存储，还是与前端通信，都是背包系统自己在负责，其它模块完全不需要干涉。
而U3D中的组件系统，则将这个粒度划得更仔细了。 这对于早期的像OGRE的entity系统。仅仅是认为对象可以由子对象构成，可以说是一个质的变化。早期的引擎，基本上都是继承优先的设计方案，更多时候考虑的是编码的便利性，且引擎的走向都具有针对性。
而当面对一些复杂情况的时候，继承式的编码是十分麻烦的。 并且，对于JAVA,C#这样的语言，并没有提供多继承能力。
因此，继承式的编程，在面对越来越广泛的游戏需求的时候。显得无能为力。 组件式则是一种聚合优先的编码方式，它的复用度和伸缩度，都远远大于继承。
唯一让一些C++程序员觉得不太顺眼的，可能就是过多的变量和虚函数调用开销吧。 但这些，在当下来说，都不是问题。
影响大众步伐的，早已不是那种语言特性本身导致的开销。更多的，是如何使我们高效率，高质量地完成一个游戏。 因此组件模式已经成为必然。
从新版的UE4的变革，以及畅游的G3D，国外一个开源的godot引擎，就可以看出来，大家对组件模式，已经有了深深的好感和接受度。四、所见即所得这可以说是许多人最喜欢的特性，这也是G3D群里，问的人最多的特性，三天两头就有人问，G3D能不能像U3D一样在编辑器里预览游戏效果呀。U3D除了编辑后立即运行，还能在运行过程中时实编辑，查看效果。当然，运行过程中编辑对象的数据，会在停止后失效。(注意，对文件属性的修改，不会失效)五、代码驱动的开发模式这种模式，可以使我们快速地构建一个原型。 对于U3D中的MonoBehiour来说，它扮演的，就是如何驱动它的目标对象。
因此，你可以将你的对象的各种能力分配到不同的脚本组件中，然后根据对象的需求来挂接。六、多平台发布U3D支持的平台，无疑是当下较为流行的平台。 满足绝大部分项目需求。 早期的引擎，多以PC和CONSOLE为主。
支持WINDOWS,XBOX,PS2已经是很不错了。 U3D便利的多平台发布特性，也使得它成为了当前性价比最高的引擎的原因之一。也有许多公司正在自主研发引擎，或者是将先前的PC引擎修改为多平台(IOS+ANDROID居多)。 但这也档不了U3D的步伐。七、良好的生态圈在使用公司引擎的时候，我就发现，若我遇上一个问题，只能问公司的老员工们，或者找其它引擎TEAM寻求帮助。而U3D这种生态圈，不是一天两天能形成的。GOOGLE,百度，各种论坛，都能很容易找到自己想要解决的问题。
而对于一些经验上的问题，也有不少人总结。 这使得后来者，可以快速上手引擎。而AssetStore的出现，不仅使U3D的生态圈更加稳固，同时也提供了许多机会。
你可以制作插件放网上卖，赚取一些利益，也可以购买别人的插件，作为使用或者参考也好。 有时候，购买一些插件，可以让你快速脱离当前的困境。
一个是解决进度问题，一个是解决思路问题。 这是之前其它引擎不具备的。
分享给小伙伴们：
主题：ubuntu系统怎么玩unity3d游戏
描述：1、打开自己的unity3d游戏项目，File--BuildSettings...2、导出为32位或者64位的，根据自己的ubuntu的版本决定。点击左边的PC，MacLinux...，右边的target platforn选择linux，architecture选择x86_64(因为我的ubuntu是64位的)，完成后点击下面uild。3、打开你要保存的夹，填写名，然后点击下面的保存。4、进入ubuntu把unity3d导出的linux版本游戏项目到linux的目录下，例如我这里...
主题：用3DMAX建模型后导出3DS格式
描述：...max平面,可以在unity里转换成地形模式吗? unity2D如何动态改变物体的layer 怎么把max格式的转成FBX Unity3d安装 为什么用unity自带的树,放场景里不带碰撞,还有就是怎么设 unity3d中怎么关卡载入进度条 学unity3d好找么
问题：但是无法做到分辨率自适应， 所以求告知3.5以上NGUI如何分回答：那具体怎么使用UIWidget实现自适应？不要有拉伸感的效果？ 类似问题：NGUI之UIRoot屏幕分辨率自适应 NGUI做PC端的程序屏幕自适应是怎么做的 unity3d和NGUI自适应问题？ 请问一下NGUI自适应的问题 NGUI 移动端开发 实现 屏幕自适应的方法 有哪些？求大神... 问题：角色是俯视图,不同的面向绕Z轴旋转可以实现。我能懂求角度之回答：非常感谢!我先去看一下~~然后如果懂了就回来给你分~~~ 类似问题：为什么魔兽中不可以用鼠标控制角色移动????求解 JA中怎么用鼠标去控制一个角色的移动啊?. 用C#怎样在实现一个角色在窗体中随鼠标的移动而移动,如 器的Move函数移动时,怎么实现由鼠标左右移动控制运动朝 unity3d鼠标控制角色移动脚本... 主题：关于健康之路预约挂号的优点有哪些
描述：健康之路 预约挂号 在当今社会健康之路 预约挂号三大好处,健康问题越来越被人们所关注,不管男女老都有不同程度疾病,越来越多的健康问题摆在人们眼前,致使的政策一呼百应。 但如今看病难的情况日趋明显三大好处,越来越多的人有病不能得到及时的治疗。所以在这用情况下出来一种新的看病方法-------预约挂号。今天我将告诉大家的三大好处。 好处一:不用长时间排队 三...
主题：用压缩的方法处理生活垃圾有哪些优点和缺点
描述：减少环卫工人使用人数。各种造型轻松融入环境,减少了污水滴漏,消除了垃圾堆放产生的异味、蚊蝇等,环保效果特别明显。垃圾收集站与旁边的住宅、绿树、红花互相掩映外观精致小巧。环保型垃圾站建成后,将彻底解决垃圾收集难,转运难的问题 。 不仅占地面积小,管理也方便。由于清运垃圾全过程采取封闭式处理,垃圾在压缩、装卸和转运等作业过程中,全处于封闭状态,不再出...
01-2701-2701-2701-2701-27
09-1509-1509-1509-1509-15
也许你感兴趣努力加载中，稍等...
暂无新消息
努力加载中，稍等...
已无更多消息...
这些人最近关注了你
努力加载中，稍等...
已无更多消息
努力加载中，稍等...
已无更多消息
& 在Unity中提升2D移动游戏性能的46个提示和技巧
46 Tips & Tricks for 2D mobile Performance in Unity.
征集热心朋友翻译文章，奖励规则：每100汉字奖励10QB，30天内互动奖励0 - 50QB.
翻译请求：专家推荐
该文章来自用户转载
Unity’s a beast. I’m always impressed at how versatile and performant it can be. But like any beast it requires a little bit of taming (and in some cases some very counter intuitive trickery, but that’s where this metaphor falls apart). I’ve had a bit of a struggle getting Truck Toss to play smoothly on my 3GS, but here’s a nice big list of tips to help you on your way. If this is your first jump into the world of Unity, my first tip (this one’s a freebie) is to stop trying to use it like other languages and environments. You will be using GameObjects, you will be adding multiple script components, and you will have to think differently. When I first started, my approach was to largely ignore prefabs (or use them like Flash’s display list) and get a copy of Box2D running. Painful as it is to deviate, get ready to put in some work!Without further ado, let’s get started:Physics:-Use the built-in physics.It might seem like a waste of cycles to have a fully 3D physics engine running the show for a 2D game, but bear in mind that the Nvidia PhysX engine will be running in Unity’s native core. We’re talking about a hyper-optimised engine maintained by large professional teams, and not a hobbyist 2D engine. Freeze Z position and X/Y rotation for that 2D feel.
-Try to use a 1/1 scale. By this I mean, 1 unit = 1 meter.
You can use larger or smaller scales, but you’re likely to encounter some weirdness when it comes to collisions, and the speed at which objects fall. Remember, a grand piano without air resistance will fall as fast as a dead baby but if everything is large, it will seem slow. You can fiddle with gravity, but again, you’re running the risk of messing with collisions. I like to use a 1/32 scale compared to my sprites with a cam size of 160.-Get your object Mass right. Just like with scale, if you have a grand piano weighing 2gm or a dead baby weighing 500kg things are going to get unpredictable. Try to keep it realistic-ish. -Mesh colliders can be slow compared to primitive box/sphere colliders. While a sphere may have many more verts than say a cube, the uniform distance from the centre would make it massively easier to calculate than lots of individual triangles. -You can simulate more complex shapes by combining primitive colliders. If you have a parent object with say a Box Collider and Rigidbody component, you can add child objects with just a Box Collider. The entire object will collide like one solid multipart object. -Continuing from the above… Rather than having several of these linked together, you can add more child objects with RigidBodies and Colliders, and use Joints to connect them to the parent object. You could build a compound car for example with a parent body to move the entire thing. -Multiple basic joints are not supported on one game object… …but multiple configurable joints are. Rather than having a network of jointed objects you could for example have a spring and a slider from wheel to axle cutting down on a suspension object in between. -Objects with a collider but no RigidBody are considered static. Moving these is expensive, so if you’re creating them with code, add the collider and physics material (to the collider) after positioning.-While it’s considered good practice to keep your solver iterations constant……you might find it beneficial to use the full amount only every 2nd update. I.e.
8,4,8,4,8,4. If this alleviates some of the processor load the solver for example may not have to skip iterations, and will actually provide a more consistent simulation. I said it was going to be counter-intuitive.-While the use of Interpolation and Extrapolation on RigidBodies is discouraged en-masse..…in some cases you might find that turning these on, and reducing the overall solver iterations provides a better simulation. Fiddle. -Lower your timestep! If you’re aiming for an unrealistic 60FPS and the phone is constantly struggling, you’re best just to settle for a lower framerate and give it some breathing room. I like to use a 0.03 fixed timestep with a maximum of about 0.05. Again, it can be slightly counter intuitive decreasing timesteps to get higher framerates, but give it a shot.-Timescale scaling.This could help, depending on the feel your’e going for. It simply simulates more time passing between each iteration. Setting this too high will obviously mess with collisions, especially if an object has traveled say, a mile in one frame, it’s not going to hit a damn thing. Sprites & Textures My engine uses a hybrid system of Sprite Manager2/EZGUI and RageSpline for sprites, but I’ve used 2D Toolkit and much of the following still applies. -Easy on the fill rate! It might seem obvious but if you have a 64×64 image, with only the top left 32×32 filled, that’s still a 64×64 sprite. Trim your transparent images where possible. Lots of libraries will do this automatically.-Hide sprites you’re not using. Make a reference to them and set them active = They won’t be drawn when offscreen anyway, but something has to determine whether or not they’re visible and chances are you know best, especially when one sprite may be fully hidden behind another and is still drawn.-Batching is your friend. But not always. If you have 40 collectable coins in your level, all using the same sprite then batching will use the one texture source multiple times on a
giant mesh, saving on draw calls. Draw calls=time. In some very rare cases the batch calculations can be a hinderance, depending on how your game’s set up, but if that’s the case, chances are you’re doin’ it wrong. -Resize your sprite’s Quad (the sprite itself) rather than its transform. If you have say a sprite component on a GameObject, then resize the GameObject’s transform, you’re going to break batching on that sprite. Instead consider the next point. With SM2 for example, you’d just set the Sprite/PackedSprite’s “Width” and “Height” properties in the inspector.-If you have a 64×64 sprite, on a 6px wide cube… …then it’s going to look like a small version of your image, but upon zooming in, you’ll see that the full 64×64 sprite has been UV mapped to the cube in perfect detail. Remember what I said about fill rate. Unless your’e zooming in and out, you might not want to use such a large texture. -Use a Sprite Sheet/Atlas where possible. This one ought to go higher, but what the hell. A sprite sheet will allow you to use commonly grouped items like your character, coins, platforms, etc in a single image/texture. Why? Less draw calls! The same part of a texture can be UV mapped to different parts of a 3D shape multiple times. I.e. if you were modelling a red and white stripy candy cane, you’d draw one white and one red line, then apply them multiple times. This is a similar concept. -Use the right shaders! There’s no point using lit shaders if you’ve no lighting, and there’s no point using a transparent shader on a solid square sprite. You can find dedicated mobile shaders in the Unity Store, by googling and doing a little copy-pasta via MonoDevelop or using those that come with SM2/Unity. As of 3.5 I believe the default shaders do a pretty decent job. Coming from various other backgrounds it might be easy to underestimate the importance of these even in a 2D environment.-Do you really need antialiasing/filtering on your sprites? Be sure to check on your target device. Some things will look pretty horrific scaled up on your monitor, but absolutely fine on those tiny high-density screens. Give it a shot, and remember to apply changes to your Sprite Atlas where possible.-Easy on the compression! DXT (DirectX) compression will do a fantastic job on your PC, with hardware decoding, but mobile devices lack this hardware decoder and will have to do it in software. I.e. Slowly. Generally IOS devices will support hardware PVRTC compression and Androids ETC, and keep in mind what I said in the last point. DXT might be fine given that it offers better clarity during say level loads, but you certainly don’t want to be decompressing them during gameplay.-Do you need Mip Maps? Mip maps are scaled down versions of a texture stored within the compressed texture itself. So depending on how far away you are, a lower res copy can be used. Obviously this takes more memory and more decompression time. You probably don’t need ’em for a 2D game. -Conversely……rather than using giant sprites on a non retina display and tiny sprites on a
retina display, it might be worth your while making a small and large version of textures and using each accordingly. -Read/Write enabled textures generate a second copy. Second copy needs more memory. In most cases, you can just leave this turned off.-Tinting a sprite will break batching… …and create a new copy of the source texture in memory. Avoid where possible, or try to pre-make any colors you’ll need! E.g. if all your Numbers in a text sprite sheet are to be red.. do it in photoshop. Loading, Saving and Object Access: -Do you really need to recreate your GUI for each level? You can hide it and have it persist when loading different scenes, reducing loading time. -GameObject.Instantiate() is slow! One common technique (which proved absolutely vital in Truck Toss) is to create a pool of objects during loading. E.g. 4 of each enemy type. When an object’s no longer needed, disable it and shove it back in the pool instead of recreating it. So you’d have a function along the lines of MakePrefab(“path/to/prefab”); which will only only call Resources.Load() provided there are none in the pool.-Resources.Load() is even slower! This function does not cache, and involves reading from the device’s HD or equivalent. Ideally you want a hybrid pool system if you’re doing a lot of loading\unloading. I.e. your standard pool system which preloads objects,
but when the instantiate function is called, it keeps a different copy in a different list. Whenever instantiate’s called and there aren’t enough in the pool but there’s a copy in the spare list, Instantiate from that rather than doing a Resources.Load fresh again.
This is a balancing act of memory use and processor use, so target it for your device. -GameObject.Find() and GetCompoenent().. …are slow (You saw that one coming, right?). If you’re going to be using an object or component repeatedly, then it makes sense to create a reference to it in a local variable rather than looking it up repeatedly.-Reflective functions can be noticeably slower. Reflection is the ability for a language\code to look within itself and get method names\types\scope etc and potentially alter them. I.e. calling a function by string name, or using delegates. Try to avoid this kinda of behaviour for performance critical code. -The garbage collector is slower yet. It has to scan trees of objects looking for orphaned classes and objects, and ‘islands’ of objects with references only to each other, determine how long they’ve been that way, and then free up the memory. Sure you can call it manually, but that’s generally more of a hint to it than a command, and shouldn’t generally be used during gameplay. -Using too much memory……will cause IOS devices to crash\quit and your app won’t be accepted to the app store. That’s actually secondary to the point that when memory’s low, your game will slow down dramatically, especially during garbage collections and when you’re trying to instantiate new objects. Sounds: -Set your BG music to decompress on load. Anything you’ll be using a lot should probably be decompressed on load rather than streaming from the disk (which is slow and can be especially troublesome on Android.) This is another tradeoff situation however, given that decompression can take time and memory. Balance it!-Infrequently used clips… ..may be left compressed in memory, especially if there are lots of them. -Force to mono? Yes yes! Unless you really want stereo and you’ve got some bitchin’ music or sound effects, you’ll save yourself some space on this one. Remember the phone has a mono speaker-Hardware decoding is faster. Well, that’s a generalisation, but faster is better. UI: -Unity’s UI system is slow. Where possible try to use a plugin or sprite package that renders to meshes in 3D space.-OnGUI is slow! Even in a blank scene you can see it spike. Try to have no more than one of these in your code, and centralise branches out from it. It’s fairly easily done.-Try to keep your UI animations in FixedTimestep() functions.This way they’ll stay consistent across multiple devices and framerates. You might benefit from having all of your game logic for every class branch out form a single base call to FixedTimeStep();-Does your UI have to update *every* frame? You might gain a massive performance boost by deferring it to every 2nd or third frame. With truck toss, the game runs much smoother with the entirety of the game logic running on every second FixedUpdate. I know, right?-Moar Cameras! If your game does a lot of scaling\zooming, then why have to scale the UI and risk breaking batching? Add another camera for the UI, and set UI objects’ layers to that of the camera. Again, it sounds like a lot of extra blitting, but could potentially speed your game up with very little in the way of changes.Build Options: -Disable the accelerometer! In older Unities, that was done via #define kaccelerometer_frequency 0 in the AppControler class via XCode. Nowadays you can disable it from within Unity itself, and can free up 2-3 FPS.-In some cases OpenGL ES 1.0 or 2.0……will offer better performance on your device. This seems to vary between devices and Android\iOS. Try on as many devices as you can.-Strip things down! When your game’s running nice and stable, switch compatibility to the .NET 2.0 subset, Stripping Level to micro mscorlib and Script Call Optimisation to Fast but no Exceptions. This will generate a smaller binary with less redundant code and debug symbols. I successfully navigated that one without a stripper reference. Jugs.-Target iOS 5 where possible. There really is no discernible speed difference. However, make sure your XCode project’s settings match, or uploading to iTunes might fail. Perhaps it’s worth exporting another project. Bonus Content – Building Faster!:-Symlink Unity Libraries……from the build settings where possible, this will save copying more files over to xCode, by effectively creating a shortcut. Much love for symlinks.Set your “Debug Information Format”From within Xcode (Build Settings) to STABS, otherwise have fun watching DWARF taking ages. Stabs..dwarf… Lols…-Sometimes using “Build for “……within XCode will build and run faster. Delete the previous version on your device and give it a shot. I have no idea why this is so, but you’re welcome. Bonus Content 2 – Faster physics modelling: This is a fun little technique I use to convert edge chains to solid blocks!Create a fake edge chain, where each link between 2 points is actually a stretched out, rotated cube parented to something, forming the outline of shape of your choice (cloud\star\car\whatever). Hit play, and while the game is running, drag your chain back into the editor to make a prefab. You now have a group of parented objects you can fill in and make solid. This lets you use your own code to generate physics shapes. And finally, Break every rule. In the spirit of hacking away at things, you must fiddle and see what’s going on.If something seems like a silly idea at first, you might just not have thought about it from all angles. Let me know if you’ve anything interesting to add. Happy hacking!
This entry was posted in , , , , , . Bookmark the .
在Unity中提升2D移动游戏性能的46个提示和技巧
版权所有，禁止匿名转载；禁止商业使用；禁止个人使用。
译者：王磊(未来的未来) 审校：崔国军（星际迷航）Unity是一个怪兽。它总是能够用它的多才多艺和性能让我震惊。但是就像任何野兽都需要一点驯服一样(在某些情况下，一些技巧非常的与直觉不符合，但这就是一个比喻而已)。我花费了一点时间让Truck Toss能够流畅的在我的3GS 上运行起来，但是这是一个很棒的技巧列表来帮助你的开发。如果这是你第一次接触Unity的世界，我的第一个提示(这是免费的)是停止试图使用其他的语言和环境。你将使用GameObject，将添加多个脚本组件，并且你需要换一种思考方式。当我第一次开始使用Unity的时候，我的方法是尽可能的忽视预制件(或者像Flash的显示列表那样使用它们)并让一份Box2D的拷贝成功的运行起来。这个过程很痛苦，因为它是偏离标准流程的，让我们准备把其他一些工作放入进来!闲话少说，让我们开始吧:物理部分:-使用内置的物理部分。对于一个2D游戏来说，运行一个完全3D的物理引擎来负责游戏的表现似乎是非常浪费的一个事情。但是需要记住的是，Unity原生核心里面使用的是Nvidia的PhysX引擎。我们谈论的是一个高度优化过的引擎，并且由一个大型专业团队进行维护，而不是一个玩具般的2D引擎。如果想要得到2D的效果，可以不使用Z轴上的移动信息，也不使用X轴和Y轴的旋转信息。。 - 尽量使用1：1的比例。我的意思是，让一个单位= 1米。你可以使用更大或者更小的尺度，但是你可能会在碰撞或者物体下落的时候遇到一些不可思议的情况。记住，没有空气阻力的话，大钢琴会下落的速度跟一个小孩的速度一样快，但如果一切都很大的话，它会显得非常缓慢。你可以摆弄重力来让表现看上去很合理，但再一次提醒，这样做的话有可能会在碰撞的时候出现一些问题。相对我的精灵大小，我喜欢使用1/32作为单位大小，我的摄像机大小为160。 -给你的物体一个合适的质量。这个的道理就跟物体的大小是一样的，如果你让大钢琴的质量是2克或者让一个死婴重达500公斤，事情会变得不可预测。尽量让物体的质量和现实情况比较接近。
-网格碰撞体相比原生的盒子/球碰撞体计算起来更慢。虽然一个球体可能有比立方体更多的顶点，但是球体上的所有点到球心的距离都是一样的，这使得计算的时候相比较计算一堆独立的三角形要方便的多。 -你可以通过组合原始的碰撞体来生成更加复杂的形状。如果你有一个父对象比如说是立方体碰撞体，同时它上面有一个刚体组件，你可以给它添加子物体比如说还是一个立方体碰撞体。那么整个物体在碰撞的时候就会像是一个由多部分物体组成的刚体那样。 - 继续上面的话题。。。你也可以选择不让这么几个物体联系到一起，你可以通过RigidBodies和Colliders添加更多的子物体，然后使用Joint组件将它们与父物体相连。举个简单的例子来说，你可以使用一个父物体来构建一个比较复杂的轿车，然后让整个轿车进行移动。
-一个物体上不支持使用多个基本关节。。。。。。但多个可配置的关节就可以使用在同一个物体上。相比较使用一个网状的关节来连接物体，你可以使用其他的方法，举个简单的例子来说，你可以使用弹簧和一个滑块来将车轮连接到车轴从而减少悬挂对象。 -如果一个物体有碰撞体组件但是没有刚体组件，那么将被认为是static类型。移动这些物体是非常耗费资源的，所以如果你是用代码创建的它们，那么请在设定好这些物体的位置以后，再添加碰撞体和物理材质(给碰撞体添加的)。-有人说让solver的迭代次数尽量保持固定是一个良好的实践行为，但是我的看法则不然。。。。。。你可能会觉得每两次更新再做一个全量的迭代可能会对性能有好处。比如说8、4、8、4、8、4。但是这样的效果可能不如每次对固定的对象进行迭代，这可能是因为处理器可以在加载的时候减少一些负担，所以提供尽可能一致的迭代信息可能是有好处的。如果它（每两次进行一次完全迭代）可以减少处理器的负载，这样做会提供一个稳定的物理模拟。所以我说这个做法是违反直觉的。-有人说对刚体进行内插值和外插值是不鼓励的但是我的看法则不然。。。。。。 。。。在某些情况下，你会发现还不如每帧都更新全部刚体，然后对整体进行迭代更新可能会得到一个更好的结果，可见降低开销。- 降低你对物理单位时间段的要求如果你瞄准的是一个不切实际的60 fps的目标，而你的手机却在不断的挣扎，你最好是满足于一个较低的帧率，让手机有一些喘息的空间。我喜欢用一个固定的更新时间0.03秒，最高也就是0.05秒。再一次，可以把更新时间减少一点，反而能够得到更好的帧速率，这很违反直觉，但是值得试一试。-time scale的缩放。这可能会有帮助，这取决于你所希望得到的感觉。它只是模拟了每次迭代之间有更多时间流逝的感觉。把这个值设置过高显然会把碰撞弄得一团糟，特别是如果一个对象在一帧里面移动的特别快，举个简单的例子来说，一个物体一帧里面移动了1英里，那么它根本就不会发生碰撞。 精灵& 纹理我的引擎在精灵管理器方面使用了一个混合系统，既使用了EZGUI也使用了RageSpline来表示精灵，但我使用了2 d工具包，以下这些技巧仍然适用。
-别对填充率太苛刻!（其实作者的意思是要对填充率太苛刻）这个看上去可能挺明显的，但是如果你有一个64*64大小的图像，但是只有左上角的32*32的部分被填充了，但是它仍然是一个64*64大小的精灵。如果有可能的话修剪你的图像的透明部分。大量的库可以自动完成这个功能。- 隐藏那些你不使用的精灵。保留它们的引用，然后设置它们的active属性为false。这样的话，在离屏渲染的时候根本就不会绘制它们，但是有时候必须确定它们是否可见，而这些事情可能你知道的更加清楚，特别是一个精灵可能会完全被另外一个精灵遮挡住，但是它可能仍然被渲染了。-批次合并是你的朋友。但并非总是如此。如果在你的关卡中你有40个需要收集的硬币，它们都使用了相同的精灵，那么在这种情况下，批次合并会多次在一个巨大的三角形网格上使用同一个纹理图片，来节省对渲染的调用。对渲染的调用就等同于时间。在一些非常罕见的情况下，批次合并的计算可能会成为一个阻碍，这主要是依赖于你的游戏具体是如何设置的，但如果是这种情况的话，很有可能是你把什么事情给弄错了。 - 调整你的精灵所在的四边形（也就是精灵本身），而不是精灵的位移组件。假设你的一个游戏物体上有一个精灵组件，然后调整这个游戏物体的transform组件，那么这么做将打断对这个游戏物体上精灵组件的批次合并。让我们用SM2(渲染模型2)举个例子，你最好是在属性检视窗口设置精灵/打包精灵的“宽度”和“高度”属性。- 如果你有一个64*64大小的精灵，用于一个只有6个像素宽的立方体上。。。。。。然后它会看起来像是你的图片的一个缩小的版本，但是如果放大看的话，你会看到完整的64*64大小的精灵已经以完美的细节做了UV映射到立方体上。还记得我说过的填充率的问题么。除非你需要对立方体进行放大和缩小，否则你可能不需要使用这么大的纹理。 - 如果可能的话，使用纹理表或者打包图集。这一条提示应该放在文章更显著的位置，等到现在才提出来有点太晚了。一张精灵表将允许你将常用的精灵进行合并摆放，比如将你的角色、硬币、平台等等放在一张单独的图片或者纹理之中。为什么要这么做呢？主要是为了减少对渲染的调用！纹理的同一个部分可以通过UV多次映射到三维形状上的不同部分。让我们举个简单的例子，比如说你在建模一个有红色和白色条纹状的拐杖糖，你可能会画一条白线，然后画一条红线，然后多次应用这两条线。这是一个相似的概念。 - 使用正确的着色器！如果你的游戏中没有使用光照的话，那么就根本没有必要使用带有光照的着色器，对于一个不透明的方块精灵，也没有必要使用带有透明度通道信息的着色器。你可以在Unity商店找到各种专门用于手机的着色器，通过做一些搜索然后复制再在编辑器中做一点修改就能使用了，或者使用那些来自SM2或是Unity的着色器。我使用的是Unity3.5的版本，我相信默认的着色器已经非常棒了。即使是在2D环境下，从来自各方面的消息或者信息来看，这些（使用正确地着色器）的重要性很容易就被忽略了。- 你真的需要对你的精灵进行抗锯齿或是过滤操作么？一定要检查你的目标设备是什么。有些东西在显示器上放大以后看起来非常可怕，但是在那些细小的高密度屏幕上面就绝对是没问题的。尽量在你的目标设备上看效果，如果可能的话，要记得将修改应用到你的图集里面。-尽量少使用压缩！ DXT（DirectX）压缩在个人电脑上通过硬件解码做了非常出色的工作，但移动设备缺乏这种硬件解码器，将不得不通过软件进行解压缩。这会非常的慢。一般来说IOS设备将支持通过硬件压缩PVRTC，而安卓设备将支持通过硬件压缩ETC，而且要记住我在上一点里面说的内容。DXT压缩也许是可行的，考虑到在关卡读取的时候它可以执行解压缩的操作，但是如果在游戏运行中进行解压缩就是完全不可以接受的。-你需要mipmap么？mipmap是在压缩纹理自身内存储的缩小版本的一系列纹理。所以取决于你从多远看这个纹理，较低精度的纹理可以被使用。很显然，这需要更多的内存和更多的减压时间。可能对于一个2D游戏来说，可能这个功能并不需要。-反过来。。。。。。如果是在一个非retia显示器上显示一个巨大的精灵或者在一个retia显示器上显示一个很小的精灵，这就可能值的同时制作大小不一的各种版本的纹理，然后根据需要来选择合适的纹理进行显示。 -允许读取和写入的纹理会产生第二份拷贝。第二份拷贝需要更多的内存。在大多数情况下，你可以关闭这个选项。 - 给纹理一个不同的颜色将打断这个精灵的批次合并。。。。。。同时也会在内存中创建源纹理的一份新的拷贝。尽量避免可能的情况，或者提前准备好你需要的各种颜色！举个简单的例子来说，如果在文本精灵表中所有的数字都是红色的话，那么就提前在photoshop做这个事情。 加载、保存和物体访问： -你真的需要为每个关卡重新创建UI么？ 当加载不同的场景的时候，你可以隐藏这些关卡UI，并让它一直存在下去，这样可以减少加载时间。
-GameObject.Instantiate()函数是非常慢的! 一个通用的技巧（这在Truck Toss中已经证明过绝对有用了）是在加载的时候创建一个对象池。举个简单的例子来说，为每个敌人类型创建4个对象。当一个对象不再需要的时候，禁用它并把它放回到对象池而不是重新创建它。所以你应该有一个像MakePrefab（）这样的函数。这只会在对象池里面没有对应的空闲对象的时候才会调用Resources.Load()。 -Resources.Load() 甚至更慢! 这个函数根本就不会做任何的缓存，并且涉及从设备的硬盘或者其他存储空间里面进行读取。理想情况下，如果你需要处理很多有关加载或者卸载问题的话，你想要的是一个混合的对象池。举个简单的例子来说，你的标准对象池是用来预加载对象的，但是当实例化函数被调用的时候，它会让一个不同的拷贝保存在一个不同的列表里面。每当实例化函数被调用，并且对象池里面没有足够的空间，但是会有一个拷贝在备用列表里面，会从备用列表里面进行实例化而不是再次调用Resources.Load函数。这是使用内存和使用处理器之间的一个平衡，所以根据你的目标设备来进行调整。
-GameObject.Find()和GetCompoenent()。。 。。。这些函数很慢（你看到过这方面的例子，对吧？）。如果你打算对一个对象或组件反复调用这个函数的话，最好是创建用局部变量创建一个引用，而不是反复地进行查找。 -反射功能可能会非常非常的慢。反射是编程语言或者代码用来查找自身信息的一种能力，可以用来获取方法的名字、类型、作用域等等并有可能改变它们。举个简单的例子来说，可以通过字符串的名字来调用对应的函数，或者是使用委托进行对应的函数调用。尽量避免对性能敏感的代码来使用这种行为。
- 垃圾收集器也非常的慢。它必须扫描对象树来寻找孤立的类和对象，以及只有彼此引用形成孤岛的对象，确定它们已经处于这种状态有多久，然后释放内存。当然你可以进行手动的调用，但通常情况这不是一个指令，更像一个提示，垃圾收集在游戏中通常情况下不应该被使用。
-使用了太多的内存。。。。。。这将导致IOS设备崩溃或者闪退，这样你的应用程序就不会被苹果商店接纳。还有一个次要的影响就是如果内存只剩下很少的情况，你的游戏将会运行的非常非常慢，特别是在垃圾收集期间或者当你试图创建一个新的游戏物体的时候。 声音部分: -将你的背景音乐设置为在加载的时候解压。尽可能的使用“在加载的时候解压”而不是“从硬盘中进行流格式读取”（这种方法很慢，而且在安卓平台上可能会遇到很多问题）。但是这其实是另外一种权衡，因为解压会花费时间和占据内存。尽可能的平衡这两个! - 对于不频繁使用的音乐剪辑。。。。。。也许可以在内存以压缩格式保留，特别是如果它们很多的情况下。
-强制使用单一声道？是的是的!除非你真正想要的是立体声效果，或者你有一些非常特殊的音乐或者音效，通过这种设置，你可以为你的游戏节省一些空间。请记住，手机的播放器其实就是一个单一声道的播放器。 - 硬件解压缩更快。在通常意义上，确实如此。 UI部分: -Unity的UI系统非常的慢。在可能的情况下尽量使用插件或者精灵包来在三维空间里面渲染网格。 -OnGUI函数运行的很慢! 即使是在一个空白场景，你也可以看到它运行的很慢，尽量在你的代码不超过一个地方使用这个它，同时也尽量减少分支。这很容易做到。 -尽量在FixedTimestep()函数里面运行的你UI动画部分的代码。这样的话，UI动画部分可以在不同的设备和帧率上运行的一致。如果你的所有游戏逻辑代码都遵循对FixedTimeStep()的一个简单调用，你可能会因此而受益。 -你的UI部分的代码必须要每帧更新么？通过把每帧更新改为每两帧更新或者每三帧更新，你可能会获得巨大的性能提升。在truck toss，整个游戏逻辑只会在每2帧的FixedUpdate里面更新逻辑一次，这样整个游戏运行起来流畅的多。这会对你有帮助么？ - 使用更多的摄像机！如果你的游戏做了很多扩展\缩放，那么为什么要冒着风险对UI进行放缩呢？而这有可能会导致批次合并不能顺利的进行。给UI部分添加另外一个摄像机，并把UI物体的层级设为那个摄像机关注的层级。再一次，这听起来像是多做了一次绘制，但是这些非常微小的变化可能会极大的加速你们的游戏。 构建选项: -禁止整个加速器！ 在旧的Unity版本里面，这是通过在XCode里面的AppControler类使用使用定义宏来实现的。现在你可以在Unity引擎里面直接做这个事情，并且可以提高2 - 3帧/秒。 -到底是选择OpenGL ES 1.0还是2.0。。。。。。到底选择哪一个能够在你的设备上得到更好的性能。这看上去似乎会依据设备的不同以及平台的不同而有所变化。尽可能的在尽量多的设备上试验，然后做出你的选择。 - 尽量减少编译信息！在保证游戏运行稳定的前提下，可以切换到Net子集，将Stripping Level设为micro mscorlib，而将Script Call Optimisation设为Fast but noExceptions。这将生成一个更小的二进制包，没有冗余的代码和调试符号。我成功的生成过没有调试信息的安装包。 - 尽可能把目标设为iOS5。尽管这样做不会在运行速度上有明显的差异。但是，确保你的XCode工程设置上是匹配的，否则的话上传iTunes可能会失败。也许单独导出到另外一个工程是值得的。 奖励内容-构建的更快！-对Unity的库进行符号链接。。。。。。尽可能的在构建设置中这么做，这将通过有效的创建快捷方式来减少到xCode的文件拷贝。符号链接真的是太棒了。 -有些时候使用“Build for”。。。。。。在XCode下这样会构建和运行的更快一点。在你的设备上删除以前的版本，并仔细的看看这个的效果。我不知道为什么会这样，但是这样用也没关系。。。最后一部分，不要受到规则的约束。要有用于探索一切未知事物的精神，你必须通过实验来看看到底会发生什么。如果某个事情在一开始看上去似乎是一个愚蠢的想法，可能只是你没有从各个角度想过这个问题。如果你有什么有趣的规则需要添加，请让我知道。让我们一起快乐的尝试吧！ 【版权声明】原文作者未做权利声明，视为共享知识产权进入公共领域，自动获得授权。
分类：程序新手圈
请勿发表无意义的内容请勿发表重复内容请勿发表交易类内容禁止发表广告宣传贴请使用文明用语其它
淫秽色情政治倾向人身攻击抄袭剽窃广告刷屏恶意挖坟冒充他人其它
登录后参与讨论。点击