您的位置：&
&Unity3D游戏开发之如何用脚本控制动画播放?
Unity3D游戏开发之如何用脚本控制动画播放?
&北京菜鸟在线教育科技有限公司
&北京市海淀区上地信息路甲28号
&日(距今530天)
　　Unity3D游戏开发中，如何用脚本控制动画播放的效果，下面菜鸟在线教育的李默涵就为大家简单的介绍一下操作方法及具体代码。
　　首先，你需要将FBX动画文件先导入到Unity3D游戏开发软件中，之后在inspector中选择Animations，并在Clips中添加和命名具体的剪辑，例如其中一个命名为walk。
　　将模型拖入场景，命名为myanim，控制脚本如下：
　　1.void Start () {
　　2.GameObject myanim = GameObject.Find (&myanim&);
　　3.myanim.transform.animation.wrapMode = WrapMode.L
　　4.myanim.transform.animation.Play (&walk&);
　　以上脚本加入后，可能会出现Animation must be marked as legacy这样的错误，那该怎么办&其实你只需要在Assets中选择模型，然后在inspector中选择Rig，在Animation Type中切换为Legacy，以上错误就可以解决了。
　　看完此篇你是否已经学会，如果还想了解什么Unity3D游戏开发(http://www. newbieol. com/)技术，可以给我留言，我会尽快请菜鸟在线教育的专业老师为大家解决，不过很多知识点已经才菜鸟在线官网有介绍，你可以先到官网上看看，还有很多免费的Unity3D游戏开发课程任你观看，这可都是很经典的课程，机会难得别错过了!
联系我时请说明来自志趣网，谢谢!
关键字：&&&&&&
给我留言，我会立即联系您，谢谢!
电话(格式：区号-号码（分机） 如 010-8))
邮箱(强烈建议填写，可跟踪信息！)
留言(1000字内)
免责申明：志趣网所展示的信息由用户自行提供，其真实性、合法性、准确性由信息发布人负责。使用本网站的所有用户须接受并遵守法律法规。志趣网不提供任何保证，并不承担任何法律责任。 志趣网建议您交易小心谨慎。
Copyright &
志趣网 版权所有博客访问： 44129
博文数量： 50
博客积分： 0
博客等级： 民兵
技术积分： 340
注册时间：
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： Android平台
& & &&对于开发来说，如此的代码虽然实现了我们要的功能，但却不干净，原因在于“请输入关键字”这样的文本仅仅是提示文字而已，而不是value，虽然技术上没有大问题，但很多时候还是显得麻烦，比如说我们可能像让提示文字显示的颜色是灰色，而用户键入的文本则显示黑色。
　　下面看看如何实现更好的方式：
　　前言：前段时间一直都好忙也就好久没有写些东西了，最近手上的事刚好告些段落了，把以前空写的写插件都拿出来分享下吧，希望对大家有些帮助，也希望有高手能帮忙指点下我的写不足和错误，一直以来自己写的东西都是在用，性能方面个人只能尽量靠近问题还很多……真心求指点;插件简介：执行渐隐等动画效果，可以这个插件为一个附加插件&可以配合前面我发的一个弹出层&等等之类的东西用增加js展示的趣味性
　　var&tex&:&T
　　DrawTexture(&Rect(&left,&top,&width,&height&),&tex&);
　　复制代码在屏幕的Rect位置绘制tex。但是官方文档在Graphics的DrawTexture()函数介绍中又这么一句话
　　It's&probably&better&to&use&GUI.DrawTexture&for&GUI&code.
　　这么说来Graphics更适合于绘制2D元素，而且，更适合于动画，一张纹理上多帧元素。这个函数不是很容易用，参数较多而且有点怪异，但是用了之后会觉得十分的合理。这个方法有4个重载，只讲最复杂的一个。其他的简单的一B了。
　　static&function&DrawTexture&(screenRect&:&Rect,&texture&:&Texture,&sourceRect&:&Rect,&leftBorder&:&int,&rightBorder&:&int,&topBorder&:&int,&bottomBorder&:&int,&color&:&Color,&mat&:&Material&=&null)&:&void
　　screenRect：这个参数就是在屏幕的以像素为单位。left，top为起始点，创建一个大小width，height的矩形。Rect(&left,&top,&width,&height&);
　　sourceRect：就是纹理对象。
　　sourceRect：在纹理上取一个矩形，缩放后放到screenRect内，所以通常这两个大小一定要一样，如果要缩放仅缩放screenRect就行了。但是有2个重要的是，第一、这个矩形的单位是相对大小，跟uv一样，是百分比的，大小在&0-1&之内。第二、起始点为left，button。也就是说以左下角为起始点。
　　border：后面4个border以像素为单位，缩放值，暂且不管，全给0，也就是原始大小。
　　color：颜色，类型为&Color，RGBA格式，0-1(0/255.0&-&255/255.0)，默认为&Color(&0.5,&0.5,&0.5,&0.5&);
　　mat&：&材质，暂时不管。
　　此代码不能放在任意位置，也就说必须有约束条件。
　　you&should&only&do&that&from&EventType.Repaint&events
　　更多有关unity3d&2d游戏的知识可以查询天地会。
阅读(548) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。总结使用Unity 3D优化游戏运行性能的经验
发布时间： 17:44:42
Tags：,,,,
作者：Amir Fasshihi
流畅的游戏玩法来自流畅的帧率，而我们即将推出的动作平台游戏《Shadow Blade》已经将在标准iPhone和iPad设备上实现每秒60帧视为一个重要目标。
以下是我们在紧凑的优化过程中提升游戏运行性能，并实现目标帧率时需要考虑的事项。
当基本游戏功能到位时，就要确保游戏运行表现能够达标。我们衡量游戏运行表现的一个基本工具是Unity内置分析器以及Xcode分析工具。使用Unity分析器来分析设备上的运行代码真是一项宝贵的功能。
我们总结了这种为将目标设备的帧率控制在60fps而进行衡量、调整、再衡量过程的中相关经验。
shadow blade()
一、遇到麻烦时要调用“垃圾回收器”（Garbage Collector，无用单元收集程序，以下简称GC）
由于具有C/C++游戏编程背景，我们并不习惯无用单元收集程序的特定行为。确保自动清理你不用的内存，这种做法在刚开始时很好，但很快你就公发现自己的分析器经常显示CPU负荷过大，原因是垃圾回收器正在收集垃圾内存。这对移动设备来说尤其是个大问题。要跟进内存分配，并尽量避免它们成为优先数，以下是我们应该采取的主要操作：
1.移除代码中的任何字符串连接，因为这会给GC留下大量垃圾。
2.用简单的“for”循环代替“foreach”循环。由于某些原因，每个“foreach”循环的每次迭代会生成24字节的垃圾内存。一个简单的循环迭代10次就可以留下240字节的垃圾内存。
3.更改我们检查游戏对象标签的方法。用“if (go.CompareTag (“Enemy”)”来代替“if (go.tag == “Enemy”)” 。在一个内部循环调用对象分配的标签属性以及拷贝额外内存，这是一个非常糟糕的做法。
4.对象库很棒，我们为所有动态游戏对象制作和使用库，这样在游戏运行时间内不会动态分配任何东西，不需要的时候所有东西反向循环到库中。
5.不使用LINQ命令，因为它们一般会分配中间缓器，而这很容易生成垃圾内存。
二、谨慎处理高级脚本和本地引擎C++代码之间的通信开销。
所有使用Unity3D编写的游戏玩法代码都是脚本代码，在我们的项目中是使用Mono执行时间处理的C#代码。任何与引擎数据的通信需求都要有一个进入高级脚本语言的本地引擎代码的调用。这当然会产生它自己的开销，而尽量减少游戏代码中的这些调用则要排在第二位。
1.在这一情景中四处移动对象要求来自脚本代码的调用进入引擎代码，这样我们就会在游戏玩法代码的一个帧中缓存某一对象的转换需求，并一次仅向引擎发送一个请求，以便减少调用开销。这种模式也适用于其他相似的地方，而不仅局限于移动和旋转对象。
2.将引用本地缓存到元件中会减少每次在一个游戏对象中使用 “GetComponent” 获取一个元件引用的需求，这是调用本地引擎代码的另一个例子。
三、物理效果
1.将物理模拟时间步设置到最小化状态。在我们的项目中就不可以将让它低于16毫秒。
2.减少角色控制器移动命令的调用。移动角色控制器会同步发生，每次调用都会耗损极大的性能。我们的做法是缓存每帧的移动请求，并且仅运用一次。
3.修改代码以免依赖“ControllerColliderHit” 回调函数。这证明这些回调函数处理得并不十分迅速。
4.面对性能更弱的设备，要用skinned mesh代替physics cloth。cloth参数在运行表现中发挥重要作用，如果你肯花些时间找到美学与运行表现之间的平衡点，就可以获得理想的结果。
5.在物理模拟过程中不要使用ragdolls，只有在必要时才让它生效。
6.要谨慎评估触发器的“onInside”回调函数，在我们的项目中，我们尽量在不依赖它们的情况下模拟逻辑。
7.使用层次而不是标签。我们可以轻松为对象分配层次和标签，并查询特定对象，但是涉及碰撞逻辑时，层次至少在运行表现上会更有明显优势。更快的物理计算和更少的无用分配内存是使用层次的基本原因。
8.千万不要使用Mesh对撞机。
9.最小化碰撞检测请求（例如ray casts和sphere checks），尽量从每次检查中获得更多信息。
四、让AI代码更迅速
我们使用AI敌人来阻拦忍者英雄，并同其过招。以下是与AI性能问题有关的一些建议：
1.AI逻辑（例如能见度检查等）会生成大量物理查询。可以让AI更新循环设置低于图像更新循环，以减少CPU负荷。
五、最佳性能表现根本就不是来自代码！
没有发生什么情况的时候，就说明性能良好。这是我们关闭一切不必要之物的基本原则。我们的项目是一个侧边横向卷轴动作游戏，所以如果不具有可视性时，就可以关闭许多动态关卡物体。
1.使用细节层次的定制关卡将远处的敌人AI关闭。
2.移动平台和障碍，当它们远去时其物理碰撞机也会关闭。
3.Unity内置的“动画挑选”系统可以用来关闭未被渲染对象的动画。
4.所有关卡内的粒子系统也可以使用同样的禁用机制。
六、回调函数！那么空白的回调函数呢？
要尽量减少Unity回调函数。即使敌人回调函数存在性能损失。没有必要将空白的回调函数留在代码库中（有时候介于大量代码重写和重构之间）。
七、让美术人员来救场
在程序员抓耳挠腮，绞尽脑汁去想该如何让每秒运行更多帧时，美术人员总能神奇地派上大用场。
1.共享游戏对象材料，令其在Unity中处于静止状态，可以让它们绑定在一起，由此产生的简化绘图调用是呈现良好移动运行性能的重要元素。
2.纹理地图集对UI元素来说尤其有用。
3.方形纹理以及两者功率的合理压缩是必不可少的步骤。
4.我们的美术人员移除了所有远处背景的网格，并将其转化为简单的2D位面。
5.光照图非常有价值。
6.我们的美术人员在一些关口移除了额外顶点。
7.使用合理的纹理mip标准是一个好主意（游戏邦注：要让不同分辨率的设备呈现良好的帧率时尤其如此）。
8.结合网格是美术人员可以发挥作用的另一个操作。
9.我们的动画师尽力让不同角色共享动画。
10.要找到美学/性能之间的平衡，就免不了许多粒子效果的迭代。减少发射器数量并尽量减少透明度需求也是一大挑战。
八、要减少内存使用
使用大内存当然会对性能产生负面影响，但在我们的项目中，我们的iPod由于超过内存上限而遭遇了多次崩溃事件。我们的游戏中最耗内存的是纹理。
1.不同设备要使用不同的纹理大小，尤其是UI和大型背景中的纹理。《Shadow Blade》使用的是通用型模板，但如果在启动时检测到设备大小和分辨率，就会载入不同资产。
2.我们要确保未使用的资产不会载入内存。我们必须迟一点在项目中找到仅被一个预制件实例引用，并且从未完全载入内存中实例化的资产。
3.去除网格中的额外多边形也能实现这一点。
4.我们应该重建一些资产的生周期管理。例如，调整主菜单资产的加载/卸载时间，或者关卡资产、游戏音乐的有效期限。
5.每个关卡都要有根据其动态对象需求而量身定制的特定对象库，并根据最小内存需求来优化。对象库可以灵活一点，在开发过程中包含大量对象，但知道游戏对象需求后就要具体一点。
6.保持声音文件在内存的压缩状态也是必要之举。
加强游戏运行性能是一个漫长而具有挑战性的过程，游戏开发社区所分享的大量知识，以及Unity提供的出色分析工具为《Shadow Blade》实现目标运行性能提供了极大帮助。（本文为游戏邦/编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）
“0 – 60 fps in 14 days!” What we learned trying to optimize our game using Unity3D.
by Amir Fassihi
The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
A smooth gameplay is built upon the foundations of a smooth frame rate and hitting the 60 frames per second target on the standard iPhone and iPad devices was a significant goal during the development of our upcoming action platformer game, Shadow Blade. ()
The following is a summary from the things we had to consider and change in the game in order to increase the performance and reach the targeted frame rate during the intense optimization sessions.
Once the basic game functionalities were in place, it was time to make sure the game performance would meet its target. Our main tool for measuring the performance was the built-in Unity profiler and the Xcode profiling tools. Being able to profile the running code on the device using the Unity profiler proved to be an invaluable feature.
So here goes our summary and what we learned about the results of this intense measuring, tweaking and re-measuring journey which paid out well at the end and resulted in a fixed 60fps for our target devices.
1 – Head to head with a ferocious monster called the Garbage Collector.
Coming from a C/C++ game programming background, we were not used to the specific behaviors of the garbage collector. Making sure your unused memory is cleaned up automatically for you is nice at first but soon the reality kicks in and you witness regular spikes in your profiler showing the CPU load caused by the garbage collector doing what it is supposed to do, collecting the garbage memory. This proved to be a huge issue specifically for the mobile devices. Chasing down memory allocations and trying to eliminate them became priority number one and here are some of the main actions we took:
Remove any string concatenation in code since this leaves a lot of garbage for the GC to collect.
Replace the “foreach” loops with simple “for” loops. For some reason, every iteration of every “foreach” loop generated 24 Bytes of garbage memory. A simple loop iterating 10 times left 240 Bytes of memory ready to be collected which was just unacceptable
Replace the way we checked for game object tags. Instead of “if (go.tag == “Enemy”)” we used “if (go.CompareTag (“Enemy”)”. Calling the tag property on an object allocates and copies additional memory and this is really bad if such a check resides in an inner loop.
Object pools are great, we made and used pools for all dynamic game objects so that nothing is ever allocated dynamically during the game runtime in the middle of the levels and everything is recycled back to the pool when not needed.
Not using LINQ commands since they tended to allocate intermediate buffers, food for the GC.
2 – Careful with the communication overhead between high level scripts and native engine C++ code.
All gameplay code written for a game using Unity3D is script code which in our case was C# that was handled using the Mono runtime. Any requirements to communicate with the engine data would require a call into the native engine code from the high level scripting language. This of course has its own overhead and trying to reduce such calls in game code was the second priority.
Moving objects around in the scene requires calls from the script code to the engine code and we ended up caching the transformation requirements for an object during a frame in the gameplay code and sending the request to the engine only once to reduce the call overhead. This pattern was used in other similar places other than the needs to move and rotate an object.
Caching references to components locally would eliminate the need to fetch a component reference using the “GetComponent” method on a game object every time which is another example for a call into the native engine code.
3 – Physics, Physics and more Physics.
Setting the physics simulation timestep to the minimum possible. For our case we could not set it lower than 16 milliseconds.
Reducing calls to character controller move commands. Moving the character controller happens synchronously and every call can have a significant performance cost. What we did was to cache the movement requests per frame and apply them only once.
Modifying code to not rely on the “ControllerColliderHit” callbacks. It proved that these callbacks are not handled very quickly.
Replacing the physics cloth with a skinned mesh for the weaker devices. The cloth parameters can play important roles in performance also and it pays off to spend some time to find the appropriate balance between aesthetics and performance.
Ragdolls were disabled so that they were not part of the physics simulation loop and only enabled when necessary.
“OnInside” callbacks of the triggers need to be assessed carefully and in our case we tried to model the logic without relying on them if possible.
Layers instead of tags! Layers and tags can be assigned to objects easily and used for querying specific objects, however, layers have a definite advantage at least performance wise when it comes to working with collision logic. Quicker physics calculations and less unwanted newly allocated memory are the basic reasons.
Mesh colliders are definitely a no-no.
Minimize collision detection requests like ray casts and sphere checks in general and try to get as much information from each check.
4 – Let’s make the AI code faster!
We use artificial intelligence for the enemies that try to block our main ninja hero and fight with him. The following topics needed to be covered regarding AI performance issues:
A lot of physical queries are generated from AI logic like visibility checks. The AI update loop could be set to something much lower than the graphics update loop to reduce CPU load.
5 – Best performance is achieved from no code at ALL!
When nothing happens, performance is good. This was the base philosophy for us to try and turn anything not necessary at the moment off. Our game is a side scroller action game and so a lot of the dynamic level objects can be turned off when they are not visible in the scene.
Enemy AI was turned off when far away using a custom level of detail scheme.
Moving platforms and hazards and their physics colliders were turned off when far away.
Built in Unity “animation culling” system was used to turn off animations on objects not being rendered.
Same disabling mechanism used for all in level particle systems.
6 – Callback! How about empty callbacks?
The Unity callbacks needed to be reduced as much as possible. Even the empty callbacks had performance penalties. There is no reason for having empty callbacks but they just get left in the code base sometimes in between a lot of code rewrite and refactoring.
7 – The mighty Artists to the rescue.
Artists can always magically help out the hair-pulling programmer trying to go for a few more frames per second.
Sharing materials for game objects and making them static in Unity causes them to be batched together and the resulting reduced draw calls are critical for good mobile performance.
Texture atlases helped a lot especially for the UI elements.
Square textures and power of two with proper compression was a must.
Being a side-scroller enabled our artists to remove all far background meshes and convert them to simple 2D planes instead.
Light maps were highly valuable.
Our artists removed extra vertices during a few passes.
Proper texture mip levels were a good decision especially for having a good frame rate on devices with different resolutions.
Combining meshes was another performance friendly action by the artists.
Our animator tried to share animations between different characters if it was possible.
A lot of iterations on the particles were necessary to find the aesthetic/performance balance. Reducing number of emitters and trying to reduce transparency requirements were among the major challenges.
8 – The memory usage needs to be reduced, now!
Using a lot of memory of course has negative performance related effects but in our case we experienced a lot of crashes on iPods due to exceeding memory limits which was a much more critical problem. The biggest memory consumers in our game were the textures.
Different texture sizes were used for different devices, especially textures used in UI and large backgrounds. Shadow Blade uses a universal build but different assets get loaded when the device size and resolution is detected upon startup.
We needed to make sure un-used assets were not loaded in memory. We had to find out a little late in the project that any asset that was only referenced by an instance of a prefab and never instantiated was fully loaded in memory.
Stripping out extra polygons from meshes helped.
We needed to re-architect the lifecycle management of some assets a few times. For example tweaking the load/unload time for the main menu assets or end of level assets or game music.
Each level needed to have its specific object pool tailored to its dynamic object requirements and optimized for the least memory needs. Object pools can be flexible and contain a lot of objects during development, however, they need to be specific once the game object requirements are known.
Keeping the sound files compressed in memory was necessary.
Game performance enhancement is a long and challenging journey and we had a fun time experiencing a small part of this voyage. The vast amount of knowledge shared by the game development community and very good profiling tools provided by Unity were what made us reach our performance targets for Shadow Blade.（source：）
CopyRight Since 2010 GamerBoom All rights reserved &&闽ICP备&号-10. 写在前面 #
动画在游戏开发中很重要, 缺乏动画的支持, 则难以建立完整的游戏和真正意义上的交互式体验. 如果游戏中的元素处于静止状态, 将缺乏生命力.
从最基本的层面上看, 动画表示为两个特定且独立的特征之间的关系, 即变化和时间. 从技术讲, 动画定义了一段时间内的变化, 通过动画以及一段时间内的特征变化, 可以有效地表达情绪,氛围,场景,以及理念等特征.
对动画基础知识的掌握需要理解的内容有 : 动画的概念(帧,关键帧) | 动画的类型(刚体动画,骨骼动画,精灵动画,物理动画,变形动画,视频动画,粒子动画,可编程动画) 以及编写代码实现动画.
1. 动画的概念 #
帧 : 将动画表达中的时间划分为变化过程中独立且离散的单位.
作为离散事物, 人们可以实时感受并产生更为明确的场景体验, 此类事物可发生在某一时刻或者位于某一帧内. 动画帧提供了属性变化的机会, 如游戏角色的移动行为或颜色的变化等. 在视频游戏中, 每秒必须维持或包含特定数量的帧. 每秒的帧数量称为 FPS 每秒帧数, 通常用作游戏性能的测算标准.
1.2 关键帧(或称重要帧)
如果每秒内传递了多个帧, 但并不是每一个帧都需要改变, 那么动画设计师可以在动画序列中定义关键帧, 随后计算机可以自动生成中间帧. 由于定义了动画中的关键时刻, 因此此类状态被称为关键帧.
在关键帧的基础上, Unity 自动生成中间帧, 即补间动画, 例如对房门定义两个关键状态 : 开启状态和闭合状态, 定义动画序列的起始点和结束点, 对应着起始帧和结束帧, 在这两帧之间的中间帧可以平滑的旋转门, 中间帧的数学处理过程称作插值计算.
2. 动画的类型 #
从技术的视角区分视频游戏中不同的动画类型. 不同的动画类型的实现方式也有所不同. 由于本质上的差别, 需采用不同的处理和工作方式, 包括特定的工作流以及所涉猎的技术.
2.1 刚体动画
刚体动画用于创建预制动画序列, 将对象视为整体实体, 与具有少量可运动部分的物体不同. 在刚体动画中, 虽然对象在关键帧之间有所变化, 但依然是作为独立的整体进行操作, 动画的过程中要始终保持物体的物理结构, 仅仅可以是位置,旋转和缩放产生变化.
因此, 刚体动画中, 关键帧之间的改变仅仅作用于整体物体及其高层属性中, 没有渗透到其子属性或内部组成中, 对象的本质内部形式一定保持不变.
这一类动画在 U3D 或 3D 动画软件中直接加以定义, 并于随后通过网格文件导入至 U3D 中.
2.2 骨骼动画
骨骼动画也称为搭建动画, 这一类动画并不改变对象的位置,旋转和缩放内容, 但是会在帧间对其内部组成进行移动或变形. 例如手臂,腿部,头部转动,嘴部运动以及舞动的树叶等等. 通常情况下, 各个动画需要在 3D 建模软件中作为完整的动画序列予以创建, 随后通过网格文件导入至 U3D 中.
2.3 精灵动画
有时候需要使用包含动画纹理,标准的四边形和平面网格, 比如 2D 动画,图形用户界面以及各种 3D 特效(Eg.水面波纹). 这个时候, 对象不需要像刚体动画一样产生运动, 也不需要内部结构产生任何变化, 因为纹理自身就处于动画状态. 这样的动画类型就叫做精灵动画.
精灵动画利用图像或帧序列以特定的帧速率播放, 进而呈现出一致的动画外观. 例如 2D 横向卷轴游戏中某一角色的行走动作循环过程.
2.4 物理动画
在玩家或其他各种场景因素无法预知的情况下, 动画需要呈现真实效果并采用动态方式与场景反馈, 比如, 采用了 U3D 的物理系统就可以有因重力作用下坠落到地面的物体. Component&Physics
2.5 变形动画
有些情况下, 刚体动画,骨骼动画,精灵动画或物理动画都无法满足要求, 例如用户可能需要呈现不同物体之间的变形效果(从人变成狼人,从青蛙变成王子,从巧克力棒变成一座城堡等等).
变形动画可以做形状混合, 将网格状态混合或者通过平滑的方式从一帧合并至另一帧的不同状态中去. 实际上, 该方法依赖于动画关键帧之间网格的对应顶点, 以及中间帧不同状态间的混合效果.
计算量大, 影响性能, 但是产生精美逼真的外观.
2.6 视频动画
U3D 可以播放视频文件, 接受 OGV(Ogg Theora) 格式的视频, 并将其作为资源文件. 将音视频作为场景网格对象上的动画纹理进行回放.
功能强大, 影响性能.
2.7 粒子动画
不同于精灵对象或网格对象有些物体无法被清晰地定义形状, 即不具备特定形状的非实体对象, 例如, 火焰,气泡,花火,烟雾,蜂群,焰火以及云朵等等.
粒子系统不可或缺. 粒子系统整体可表示为一类可配置的对象, 并用于模拟雨,雪和鸟群等效果.
2.8 可编程动画
大多数常见的动画类型都是可编程动画或者动态动画, 我们经常需要对一类行为进行编程设计(比如, 角色到达门口的时候门的开启行为, 玩家操作游戏角色在环境中移动等等), 开发人员针对特定的功能编写代码, 使得一段时间内对象属性的变化. 与其他形式不同, 编程行为无法通过设计师事先构建, 不过, 多数情况下, 动画的效果可通过设计师制作完成, 代码仅在运行期间简单地对动画行为进行触发和指引.
3. 编写代码实现动画 #
基于代码的动画效果是启动动画行为的主要方式, 可以通过 C# 脚本与运动对象实现绑定, 脚本内容一般默认包括两个函数 : Start() 和 Update()
Update 函数与动画行为密不可分, 并与帧和帧率相关, 对于 FPS = 70 的游戏, 基于脚本的各个对象, Update 函数每秒会被执行 70 次, 进而使该对象处于活动状态.
using UnityE
using System.C
public class Mover : MonoBehaviour {
void Start() {}
void Update() {
Transform thisTransform = GetComponent&Transform&();
thisTransform.position += new Vector3(1f, 0f, 0f);
由于帧速率在不同的计算机上有所不同, 甚至同一计算机的一段时间内也会发生变化. 在 FPS = 70 的系统上, 对象每秒将更新 70 个单位, 在 FPS = 90 的系统上则为 90 个, 如果这样用户将得不到一致的游戏体验, 也会导致多玩家的游戏全部玩家无法处于同步状态的情况. 这是绝对不可以的.
行进距离 = 速度 x 时间. 时间可以在不同的计算设备间保持一致, 所以应该直接将运动行为映射至时间.
thisTransform.position += new Vector3(1f * Time.deltaTime, 0f, 0f);
放在 Update 函数中的代码是以帧来执行的. 如果我们需要物体的移动以秒来执行, 就需要将物体移动的值乘以 Time.deltaTime. 在各帧中, Time.deltaTime 显示了距上一帧所经历了的时间值(秒). 使用这个变量和游戏帧速率无关. 实际表示的将是 : 每秒移动物体 1 米而不是每帧移动 1 米.
当从 MonoBehaviour 的 FixedUpdate 里调用时, 返回固定帧速率增量时间(fixedDeltaTime).
另外, OnGUI 里不应该依赖 Time.deltaTime, 因为 OnGUI 可以在每帧被多次调用并且每个调用 deltaTime 将持有相同的值, 直到下一帧再次更新.
3.3 某一方向上的运动
这里是向量的概念, 形如 (x, y, z) 的向量包含了 3 个分量, 并以此为某一方向. 三个轴同步运动.
using UnityE
using System.C
// 方向控制
public class Mover : MonoBehaviour {
public float speed = 1f;
public Vector3 direction = Vector3.
void Update() {
Transform thisTransform = GetComponent&Transform&();
thisTransform.position += direction.normalized * speed * Time.deltaT
3.4 动画曲线对中间帧进行编码
游戏对象还需要实现曲线运动, 仅仅直线路径想必是不足以的, 或者需要对象实现变速运动, 以上对此可以使用动画曲线这一特定的对象, 构建定义动画的中间帧的曲线, 进而控制对象在关键帧之间的变化方式.
using UnityE
using System.C
// 速度调整
public class Mover : MonoBehaviour {
public float speed = 1f;
public Vector3 direction = Vector3.
public AnimationCurve animC
void Update() {
Transform thisTransform = GetComponent&Transform&();
thisTransform.position += direction.normalized * speed * animCurve.Evaluate(Time.time) * Time.deltaT
在对象查看器中对其进行考察, 单击查看器中的曲线, 曲线编辑器可以作为一个单独的对话框显示, 可以通过速度值控制中间帧.
曲线编辑器的水平轴表示时间(秒), 垂直轴表示为速度值. 用户可以在左下角的预制图生成初始曲线, 并针对对象速度控制其插值计算, 还可以在曲线上双击插入新的控制点, 并对曲线加以控制, 如果最新控制点使曲线产生了边角失去平滑特征, 可以使用 Free Smooth
3.5 利用协同程序旋转对象
编写一个脚本, 缓慢平滑地旋转对象, 并使其一直朝向目标对象.
using UnityE
using System.C
[ExecuteInEditMode]
public class LookAt : MonoBehaviour {
private Transform thisTransform =
public Transform target =
public float rotateSpeed = 100f;
void Awake() {
thisTransform = GetComponent&Transform&();
void Start() {
StartCoroutine(TrackRotation(target));
IEnumerator TrackRotation(Transform target) {
while(true) {
if (thisTransform != null && target != null) {
Vector3 relativePos = target.position - thisTransform.
Quaternion newRotation = Quaternion.LookRotation(RelativePos);
thisTransform.rotation = Quaternion.RotateTowards(thisTransform.rotation, newRotation, rotateSpeed * Time.deltaTime);
void OnDrawGizmos(){
Gizmos.DrawLine(thisTransform.position, thisTransform.forward.normalized * 5f);
协同程序工作方式与常规函数不同, IEnumerator 返回类型可视为其特征, 并至少包含一条 yield 语句. 在程序重新执行后, 协同程序可与其调用处理过程并行运行, 这一点类似于线程或背景线程, 即多任务机制, 可与其他处理共同运行.
对动画而言, 当其他处理过程运行时, 可以实现动画效果并改变对象的属性.
3.6 材质和贴图动画
需要通过编程方式调整或修改一段时间内网格顶点间的 UV 坐标, 进而移动表面纹理. 过程中不改变纹理内的像素, 且映射至表面上的像素可实现动画效果. 水流,岩浆,云朵,魔幻隧道的效果等等.
学习自 : Book &&Unity Animation Essentials&&
阅读(...) 评论()