#
最近因为在搞游戏地形的关系，又想起id Tech5的地形技术，以前就看过了一些视频，知道了大概，但一直不是很清楚其基本的实现原理，于是搜索一番，还是有些收获的
首先，来看看wikipedia上面对于MegaTexture的定义：
http://en.wikipedia.org/wiki/MegaTexture
MegaTexture refers to a texture allocation technique facilitating the use of a single extremely large texture rather than repeating multiple smaller textures. It is featured in Splash Damage's game, Enemy Territory: Quake Wars and was developed by id Software technical director John Carmack.[citation needed]
MegaTexture employs a single large texture space for static terrain. The texture is stored on removable mediaor the hard drive and streamed as needed, allowing large amounts of detail and variation over a large area with comparatively little RAM usage.[citation needed]
Then during rendering, required parts of the texture space are streamed inside dynamically (re-)allocated textures in video memory, scaled to the correct mipmap level(s) depending on the polygon size. This allows the engine to reduce the number of texels in VRAM/number of pixels on the screen ratio (the goal being getting closer to 1), saving memory.
The upcoming games Doom 4 and Rage, powered by the id Tech 5 engine, use textures that measure up to 128000×128000 pixels[1].
id Tech 6 will use a more advanced technique that virtualizes further both the geometry and the texels (texture points): Voxel Spare Octree (VSO). This works by not using geometries anymore (triangles and textures) but by instead storing colored 3d points in an octree. The goal being to be able to stream parts of the octree, going further down along the tree for nearby objects to give them more details, and to use higher level, larger voxels for further objects, which give an automatic level of detail system for both the geometry and the texture space at the same time. Despite most Voxel rendering tests end using very large amount of memory (up to several Gb), John Carmack claimed he's able to compress such VSO to 1 byte per voxel.
翻译的大意：
MegaTexture使用一张贴图来表现整个地表的像素外观，通过动态定位和载入所需的该贴图的局部的合适mipmap，来节约显存开支（这里说到选择mipmap level是基于polygon size的，不是很清楚实际的做法，估计可能是基于地形自身的polygon，但考虑上地形polygon可能会有的LOD，情况就比较复杂）
Doom4和Rage都将使用最大为128000x128000的MegaTexture（这说明Doom4可能会有大量的室外场景？）
id Tech6会使用一种叫做VSO的更为先进的技术，同时虚拟场景几何和图素（关于VSO，完全不懂鸟），这意味着将不再使用传统的场景几何（三角形+贴图），而是通过octree储存彩色化3D点（这句话我自己也无从了解，所以翻译仅供参考了），目标就是动态载入octree的局部，对近处的物体，沿着此树往下以获得更多细节，而对于远处的物体，则使用更高级别、更粗大的voxels(现查，voxels即volumetric pixels，可以理解为三维像素)，这样就给场景几何和贴图同时提供了LOD系统。尽管多数的Voxel渲染测试都反映需要很大量的显存（几个G），卡马克表示他已经能够把每个三维像素压缩到1字节
注：下面提到的姚勇的pdf里面，说到Doom3里已经有MegaTexture的实现了（没有另外去查询考证），尺寸最大32768x32768，不使用传统LOD和地形的Geometry Morphing，可见卡马克同学还是比较“激进”的，那么多年前就已经搞这个，和UE3（地形LOD+Morphing）果然是截然不同的思路阿
通过google搜索，发现了另一篇好文，作者是姚勇（很多人应该知道的八）：
http://blog.csdn.net/puzzy3d/archive/2007/08/16/1746589.aspx
点这个页面里的pdf连接
这个pdf写得很好啊，我这样的小白一看就基本明白MegaTexture背后的实现原理了，就是基于一种叫做clipmap的技术，clipmap顾名思义，就是把map的一部分clip下来用，每次更新需要的局部
关于clipmap，据说是SGI在1998年的时候最先发表的（我没去考证），这里有SGI关于此技术的文章一枚：
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=bks&srch=&fname=/SGI_Developer/Perf_PG/sgi_html/ch15.html
这文章前半段还可以看看，对于非图形程序员的普通群众来说，看起来恐怕都会和我一样累
如果不愿意看这篇文章，你还可以去下载SGI当年那篇文章的pdf：
The Clipmap：A Virtual Mipmap
另外，clipmap这类原理的技术，在3d虚拟和大规模地形系统上（比如google earth），好像也颇为有用，关于google earth，最近找到一篇很赞的文章，打算花点功夫翻译出来（希望还没人干过这件事情）
特地又重看了一下Tech 5的引擎演示， 这次的感觉就和以前不一样了，MegaTexture如果只是一个换了名字的clipmap，那其实也没啥好说的，Doom3里面也有，但没见id以前怎么力推过。之所以tech 5要主推MegaTexture，还是因为有了一套为其配合的高效制作工具。
其实clipmap技术和传统基于tiling的技术注定要在制作上走两条完全不同的路子。tiling技术的思路就是，我只做局部，然后让局部不断重复产生出整体，EPIC到UE3这一代为止，就是努力贯彻这种思路，所以不光是贴图可以tiling，连模型也强调模块化和拼接（当然模块化的涵盖比tiling要大一些）。这种思路的优点就是制作效率高、资源利用率高、资源存储节约，缺点么，就是视觉上容易重复，制作上需要考虑避免突兀和不均匀（尤其是贴图，tiling贴图往往会导致趋向于均匀和缺乏反差从而无从表现个性化细节），在动态载入和LOD上，只能用一些较土的手段，总体就是不适合做富有变化的大规模地形。而clipmap，说白了，就是每一个像素都可以特殊处理，都不会因此而影响运行效率，且天生对动态载入和LOD有很棒的支持，对内存和显存的消耗还好，对外存的需求就很大了，但毕竟外存的容量发展比较快。但clipmap的问题是，如果每一个像素都要制作，那么制作上的工作量就极大，所以使用此类技术的游戏，应该都会想办法开发一些减轻工作量的工具，据Porky同学说WIC是“先用地形系统根据高度坡度等生成自然贴图和lightmap, 公路和deco会往上投射公路和爆炸坑等贴图,然后导出到PS里手画其他一些东西,比如平地上的沙坑啥的”，用PS画是一种方式，但问题是毕竟导进导出麻烦且不直观，而tech 5的工具所提供的，就是一套内嵌的"PS"，让美工直接在场景里面绘制，那些stamp，其实很像PS里面的各种不同造型的笔刷，然后tech 5编辑器还提供这些“笔刷”绘制后的互相的叠加效果（这其实就是PS里面图层之间的混合模式），所以，tech 5的MegaTexture，好玩就好玩在这里，感觉在编辑器层面，那个“大贴图”就是一个巨大的PSD文件阿
所以id和EPIC的确是个性很不一样的公司，我特期待EPIC会把UE4设计成什么样子
http://lichong.blogbus.com/tag/clipmap/
Unity3D是一个跨平台的开发工具，支持的平台五花八门，常常开发一款游戏要发布到不同的平台，在不同的平台上会使用不同的代码，难道要我们各平台分别使用一套代码，单独编译一次吗？当然不用了。
Unity3D有一个功能叫平台依赖编译（Platform Dependent Compilation），它可以让我们简单地使用if...else...对不同平台的代码进行区分，当我们切换一个发布平台重新编译时，Unity3D使用自动编译相应代码，从而省去了繁琐的操作。
下边举一个例子：
function Awake() {
#if UNITY_ANDROID
Debug.Log("这里是安卓设备^_^");
#endif
#if UNITY_IPHONE
Debug.Log("这里是苹果设备>_<");
#endif
#if UNITY_STANDALONE_WIN
Debug.Log("我是从Windows的电脑上运行的T_T");
#endif
}
那么其它的平台怎么判断呢？请见官方手册。
要提醒一下的是，手册里还有对Unity3D版本的判断方法，和上边一样的方法哦！
另外Application.isEditor 和Application.isWebPlayer 也可以判断程序是否是在Unity3D IDE里运行，或者是否在WebPlayer里运行的。
原文链接：http://bbs.9ria.com/thread-173907-1-1.html
昨日gamelook曾就某投资人把移动团队失败原因之一归于选择Unity引擎进行了一番评论，工具本身无罪，但如何理解工具、正确使用Unity引擎确实需要讨论，在选择Unity之前你或许需要了解下这个引擎实际开发过程中的技术特点、以及适应的游戏产品类型，gamelook热心读者Fxcarl昨天就这个问题专门撰文一篇，来帮助大家了解Unity游戏开发、分享心得，推荐阅读。
文/FXCarl
代码驱动带来的技术题
游戏碎片化。U3D 引擎有个很有力的特色，就是实时编译运行。这意味着无论在任何时候，只要按下运行图标，当前的场景就会进入可执行状态。这导致了游戏在开发的过程中经常陷入一种不应当的自信状态。同时也导致了游戏内容长期处在碎片状态下，并低估游戏功能整合时可能遇到的困难。
资源管理是 U3D 引擎的一个难点。U3D 的资源管理系统因为跨平台的缘故和操作系统的文件系统是脱钩的，需要熟练的掌握 Resources 目录和 Assetbundle 的技术才能灵活的控制游戏中的资源使用情况。但这一工作时常会被简单的理解为将资源放置在游戏工程目录下，剩下的交给引擎自己搞定 ……
需要自己做数据系统。我们如今国内研发的作品，绝大多数是数据密集型(策略、经营、卡牌、KRPG)，这和 Temple Run 这样的游戏类型有些不同。数据密集型的游戏需要采用数据驱动的形式来进行游戏的设计和开发，但是 U3D 提供的框架是一个代码驱动型的结构(对于原型开发来说极为有力)很多时候会让研发团队陷入泥潭 —— 看起来功能开发出来了(只要在U3D的对象检查器里调调参数就能工作)，却迟迟无法进入大规模制作阶段(策划拿着数据表格却无法应用到游戏里)。U3D 引擎本身也没有提供任何在数据方面的支持，数据表要么需要自行处理，要么需要自己寻找嵌入式的数据库解决方案。
网络连接部分其实也是类似。U3D 本身集成的网络模块并不是为大规模 C/S 结构的游戏所设计，常需要自行开发一套客户端和服务器结构。当然也可以求助中间件来解决 …… 但是容易让人迷惑的地方在于，U3D 既可以使用 .net 的网络机制像端游一样工作，也退一步可以用加密的 www 机制，当一个简单的页游来处理。如何抉择是个难题，贸然贪多求全往往换来遥遥无期。
测试 U3D 开发的游戏亦一个很麻烦的过程。原因也是那个几乎不会崩溃，随时可运行的场景/逻辑混成编辑器 —— 它会让开发团队误算自己当前的游戏完成度，以及需要什么样的测试。
尖端技术带来的麻烦事
高精尖的动态光照和复杂材质系统。U3D 比起其他的移动平台或者网页游戏开发工具而言，往往最打动人的就是其无与伦比的画面渲染效果。但是在光鲜的官方演示背后，仿佛总有看不到的壁垒阻碍着其他开发者的步伐。实际上驾驭 U3D 所需要的能力是超乎一般想像的。U3D 的渲染架构的确够强大，完成 Unreal 甚至 CryEngine 级别的画面渲染质量都是可能的，但是它并没有包装这些系统而是将灵活性交给了开发者。我们的程序员是否已经控制住了渲染管线的复杂度?我们的技术美术是否可以指导我们的美术完成充分发挥 U3D 能力?美术制作人员是否有具有胜任所谓“次世代”精度要求的游戏内容制作?这些东西属于小团队吗?
全局光照烘培。这是一个非常非常非常实用的 U3D 功能。理应所有的 U3D 团队都灵活使用。但是想要用好就有了另外一番难度 —— 美术和场景制作人员的配合，而谁来负责就比较难说了。另外美术必须用非常精准的尺寸来制作场景中的物件，否则 U3D 将无法正确的处理全局 UV。
工具链带来的纷纷扰扰
GUI 系统的各种理论。所有人都在吐槽 U3D 自带的 GUI 系统太慢 —— 问题是真的有证据吗?一方面很多人说我做测试的时候做了一大堆的控件，的确很慢。另外一方面大家也会发觉 GUI 系统会带来一些不必要的渲染请求(Draw Call)。于是大家都在拼了命的做两件事情，一个是减少渲染请求，一个是想尽一切办法的避开 GUI。但其实情况没那么严重，无论是挑选替代中间件如 NGUI 还是直接使用 U3D 的 UI 系统都不会巨大的影响 —— 除了不当使用之外极少见到 GUI 成为性能焦点的时候。不过无论是 NGUI 还是 U3D 内置 UI 都没有很好的 UI 工具 —— 要么过于程序员导向，要么过于偏向布局而不方便增加代码功能。内部开发一些扩展工具或者工作流程都很有必要。
版本控制的难题。Asset Server 还是 SVN 其实多多稍稍都有不适应 U3D 的情况。但是更关键的地方在于整理好文件的内部结构以及经常备份。恰当的使用 U3D 的命令行模式可以实现 U3D 工程的自动编译发布。
扩展 U3D 本身功能的能力。因为 U3D 较为完整的功能而忽视对 U3D 本身的功能拓展是一种常见状态，随时保持专人不断的优化 U3D 本身的功能是非常重要的，譬如各种各样的批量化操作等等。但是这有个前提，扩展工具需要充分理解工具，U3D 相对来说功能过于强大，以至于很多团队中的成员会害怕学习，而将 U3D 作为少数团队成员或专属于程序员的工具 —— 这就很成问题了。
需要前瞻性的判断能力
每一个，每一个国内开发 U3D 游戏的团队都在抱怨 U3D 的中文字体支持问题等等。可是实际上真正用前瞻性的角度在使用 U3D 引擎的团队并不多 —— 以今天此时此刻为例，U3D 4.0 已经可以在任何平台上使用动态的字体，支持 Unicode 编码 —— 中文不在话下。从 U3D 3.5 迁移到 4.0 几乎不用对项目做任何的修改，而如果说之前并不知道 4.0 会支持动态字体的话，那么为什么不多去官方论坛关注一下每个版本的开发进度情况呢?每一个在 2013 才会发布的游戏都不应该担心字体问题才对嘛 ……
保持对每个版本 U3D 更新内容和未来 U3D 功能的关注可以大量减少重新发明轮子的问题，也能在遇到一些困境时保持更好的心态。直接邮件开发者也会是个很好的选择，请一定要多骚扰他们!一般提前3个月到6个月就能获知将来版本可能更新的内容的。
1 “Code-Driven”
State Management
Assets Management
Data Management
Networking
Testing
2 CuttingEdge Techs
Dynamic Lighting & Complex Materials (Textures)
Lightmapping
Nav mesh
Mecanim
DX11
3 Toolchain
GUI
VersionContorl
4 Vision
原文地址:http://game.zol.com.cn/354/3543149.html
当我们开发一个大型项目的时候-会遇到这样的问题(地形场景的切换）这个只是字面意思-并不是重场景1的100 100 100坐标一下切换到场景2的100 100 100坐标这样的方法--（如果您以为是这样的技术和代码）那就不用看了。这个技术的实质意义是为了解决--多地形场景带来的大量内存占用问题-举个我的例子-我的测试项目是1013张绘制地形--在不用上面的技术情况下-占用了我4.2G的内存。想想下-如果一个大型的游戏直接这么运行的话）一下就会带来5-8G的内存占用--这个游戏还能玩吗？
下面让我们来研究实现的方法和代码
涉及到几个U3D函数：（引用高人的文档介绍）
Application.LoadLevel(lv) 场景读取(记着用多场景前要现在File-Build Setting里登记下场景，才能在脚本里读取到) DontDestroyOnLoad(object) 保持物体在场景切换的时候不被卸载(能保持他的所有属性哦)
*AssetBundle 类 预读资源（主要用于web3d，运行时实时从服务器下载需要的场景资源）
涉及到几个基础知识：
static 静态类、静态变量：在整个游戏中都不会被重新加载，所以可以当全局全场景变量使用，主要用于记录场景数组。
Collider的Is Trigger属性：设置成True，他是可以穿越不会产生能量传递的，但是，他是可以接受碰撞侦测的。配合主角的OnTriggerEnter事件，就可以知道你是否正在穿越一个Trigger了。在这里，我们用在判断何时加载新场景上。
2.制作场景边界
使用Cube + IsTrigger=True属性是最好的办法。
1）如果是双场景切换，注意两个场景边界坐标别重在一起，不然你走到边界会发现两个边界不停的切换=.=，要让2个场景边界互相交错一起(做的时候你自然会明白)。有必要的话，边界可以往里面缩一点（甚至可以吧场景重叠1/3，但这样两个场景你要做很多重复的东西），避免用户看到边界。然后建议是把Cube
3.编写脚本
好了，现在可以开始写脚本了，我一如既往的很懒，所以不会吧全部代码粘帖出来 。（我会别看到这里不看了，这是以前高人写的）
先理清楚逻辑关系以及一些常识：
1.是主摄像机走到边界才会做场景加载或卸载动作。所以代码是放在主摄像机上或者主角上。
2.场景可以加载，但是没有卸载场景这个东西（也没必要卸载，因为同一时间只会有一个场景为当前场景），所以如果你用九宫格方式做无缝连接，你需要把场景读取，然后让场景里所有物体DontDestroyOnLoad（当然包括主角，也就是this）,然后其他场景也这么操作，当需要卸载场景时，只要把所有那个场景Object给Destroy掉就可以了。而做双场景连接则不需要这样，也简单的多。
3.如果是九宫格，你需要一个静态二维数组去记录每个位置场景的名字。这里也可以不需要这么做，有个技巧，你可以格式化场景名字规则来推算下一个需要加载的场景名字，比如M1N1表示(1,1)场景，那你就可以用字符串拆分的方法知道需要读取M0N0,M1N0,M2N0等等的场景。
4.接下来就是处理碰撞，获取下一个场景(双场景方式)或者当前场景(九宫格方式)的名字，这里你就可以看到一个被格式化过的场景名有多么重要。
function OnTriggerEnter(other:Collider){
Application.LoadLevel(other.name); //这是双场景方式直接把边界Cube名字设为了下一个场景名
}
上面的介绍是大概的描述-具体实现方法如下
我们在使用这个技术之前要将你的地形--在U3D里的File-Build Setting里登记下场景，才能在脚本里读取到-Add Current(这个是登记地形）
之后我们来制作一个简单的-2个地形的切换方法
如图：
这个图是做好了的2张地形--中间的Cube是用来接受角色的碰撞的--这样我们就知道在何时去载入我们的下张地形场景了（不包括其他-数据。。列入--坐骑这类的-这个需要另一段代码单独给坐骑-马或者车子这类的--还有很多）
Cube---把Inspector--Is Trigger--划勾--（这个作用是接受碰撞但不产生能量传递-也就是说他接受碰撞，但可以让同样具有 Is Trigger-划勾的属性物体通过--列入-我们的角色或坐骑）（补充--我们的角色也需要去勾选-Is Trigger-这些才可以通过，但官方自带的FPS--没有Is Trigger-这个勾选像-可以用如下方法解决-创建一个新的Cube为他重新命名-把他作为FPS-父物体--然后勾选-Cube的 Is Trigger-子物体就会有这项属性了）
这些工作建立好了以后-开始我们的脚本工作。
脚本如下：
function OnTriggerEnter(other:Collider)
{
if (other.gameObject.name=="Cube1")
Application.LoadLevel("Terrain 1");
};
复制代码
为了方便大家理解--我没有重新命名--Cube1--就是我们接受碰撞体，Terrain 1是我们的要载入的下张地形。（大家可以用很多方法去优化他--有优化的方法请发在这个帖子内-方便大家查看-非常感谢）
这段代码要放在角色上或角色摄像机上或FPS的父物体Cube上。
以上的操作就完成了-一个重地形0到地形1的切换--（可以解决100M或跟高的内存占用问题-这个要看你的地形场景而定了）
但这并不完整--我们也可能要重地形1回到地形0---这个要你们自己解决了-以上的内容已经把这个解决的方法说出来了--大家自己学习发挥下--这样才有进步。
下面我们来说明4张地形场景的载入--逻辑（这里只说明逻辑，具体代码和上方一样，需要大家自己发挥下）
如图
这个图中可以看到4张地形场景--我重点讲解--中间的2个大的Cube逻辑--那4个长方形的大家应该都清楚了。除非你没认真看。
中间最大的Cube是来判断--角色走的这个范围内的时候他要去载入那张地形场景-如果在这个大的Cube的范围内折载入其他的2张地形场景。（这个大的Cube可以根据自己的地形规格-做出调整这里给出的并不准确）
中间最小的Cube是来判断--角色走的这个范围内的时候他要去载入那张地形场景-如果角色走入小的Cube中后-载入其他3地形。
原文链接：http://keigoliye.blog.163.com/blog/static/146213359201081923658957/
用Unity3D制作基于web的网络游戏，不可避免的会用到一个技术-资源动态加载。比如想加载一个大场景的资源，不应该在游戏的开始让用户长时间等待全部资源的加载完毕。应该优先加载用户附近的场景资源，在游戏的过程中，不影响操作的情况下，后台加载剩余的资源，直到所有加载完毕。
本文包含一些代码片段讲述实现这个技术的一种方法。本方法不一定是最好的，希望能抛砖引玉。代码是C#写的，用到了Json，还有C#的事件机制。
在讲述代码之前，先想象这样一个网络游戏的开发流程。首先美工制作场景资源的3D建模，游戏设计人员把3D建模导进Unity3D，托托拽拽编辑场景，完成后把每个gameobject导出成XXX.unity3d格式的资源文件（参看BuildPipeline），并且把整个场景的信息生成一个配置文件，xml或者Json格式（本文使用Json）。最后还要把资源文件和场景配置文件上传到服务器，最好使用CMS管理。客户端运行游戏时，先读取服务器的场景配置文件，再根据玩家的位置从服务器下载相应的资源文件并加载，然后开始游戏，注意这里并不是下载所有的场景资源。在游戏的过程中，后台继续加载资源直到所有加载完毕。
一个简单的场景配置文件的例子：
MyDemoSence.txt
Json代码
{
"AssetList" : [{
"Name" : "Chair 1",
"Source" : "Prefabs/Chair001.unity3d",
"Position" : [2,0,-5],
"Rotation" : [0.0,60.0,0.0]
},
{
"Name" : "Chair 2",
"Source" : "Prefabs/Chair001.unity3d",
"Position" : [1,0,-5],
"Rotation" : [0.0,0.0,0.0]
},
{
"Name" : "Vanity",
"Source" : "Prefabs/vanity001.unity3d",
"Position" : [0,0,-4],
"Rotation" : [0.0,0.0,0.0]
},
{
"Name" : "Writing Table",
"Source" : "Prefabs/writingTable001.unity3d",
"Position" : [0,0,-7],
"Rotation" : [0.0,0.0,0.0],
"AssetList" : [{
"Name" : "Lamp",
"Source" : "Prefabs/lamp001.unity3d",
"Position" : [-0.5,0.7,-7],
"Rotation" : [0.0,0.0,0.0]
}]
}]
}
AssetList：场景中资源的列表，每一个资源都对应一个unity3D的gameobject
Name：gameobject的名字，一个场景中不应该重名
Source：资源的物理路径及文件名
Position：gameobject的坐标
Rotation：gameobject的旋转角度
你会注意到Writing Table里面包含了Lamp，这两个对象是父子的关系。配置文件应该是由程序生成的，手工也可以修改。另外在游戏上线后，客户端接收到的配置文件应该是加密并压缩过的。
主程序：
C#代码
。。。
public class MainMonoBehavior : MonoBehaviour {
public delegate void MainEventHandler(GameObject dispatcher);
public event MainEventHandler StartEvent;
public event MainEventHandler UpdateEvent;
public void Start() {
ResourceManager.getInstance().LoadSence("Scenes/MyDemoSence.txt");
if(StartEvent != null){
StartEvent(this.gameObject);
}
}
public void Update() {
if (UpdateEvent != null) {
UpdateEvent(this.gameObject);
}
}
}
。。。
}
这里面用到了C#的事件机制，大家可以看看我以前翻译过的国外一个牛人的文章。C# 事件和Unity3D
在start方法里调用ResourceManager，先加载配置文件。每一次调用update方法，MainMonoBehavior会把update事件分发给ResourceManager，因为ResourceManager注册了MainMonoBehavior的update事件。
ResourceManager.cs
C#代码
。。。
private MainMonoBehavior mainMonoBehavior;
private string mResourcePath;
private Scene mScene;
private Asset mSceneAsset;
private ResourceManager() {
mainMonoBehavior = GameObject.Find("Main Camera").GetComponent<MainMonoBehavior>();
mResourcePath = PathUtil.getResourcePath();
}
public void LoadSence(string fileName) {
mSceneAsset = new Asset();
mSceneAsset.Type = Asset.TYPE_JSON;
mSceneAsset.Source = fileName;
mainMonoBehavior.UpdateEvent += OnUpdate;
}
。。。
在LoadSence方法里先创建一个Asset的对象，这个对象是对应于配置文件的，设置type是Json，source是传进来的“Scenes/MyDemoSence.txt”。然后注册MainMonoBehavior的update事件。
C#代码
public void OnUpdate(GameObject dispatcher) {
if (mSceneAsset != null) {
LoadAsset(mSceneAsset);
if (!mSceneAsset.isLoadFinished) {
return;
}
//clear mScene and mSceneAsset for next LoadSence call
mScene = null;
mSceneAsset = null;
}
mainMonoBehavior.UpdateEvent -= OnUpdate;
}
OnUpdate方法里调用LoadAsset加载配置文件对象及所有资源对象。每一帧都要判断是否加载结束，如果结束清空mScene和mSceneAsset对象为下一次加载做准备，并且取消update事件的注册。
最核心的LoadAsset方法：
C#代码
private Asset LoadAsset(Asset asset) {
string fullFileName = mResourcePath + "/" + asset.Source;
//if www resource is new, set into www cache
if (!wwwCacheMap.ContainsKey(fullFileName)) {
if (asset.www == null) {
asset.www = new WWW(fullFileName);
return null;
}
if (!asset.www.isDone) {
return null;
}
wwwCacheMap.Add(fullFileName, asset.www);
}
。。。
传进来的是要加载的资源对象，先得到它的物理地址，mResourcePath是个全局变量保存资源服务器的网址，得到fullFileName类似http://www.mydemogame.com/asset/Prefabs/xxx.unity3d。然后通过wwwCacheMap判断资源是否已经加载完毕，如果加载完毕把加载好的www对象放到Map里缓存起来。看看前面Json配置文件，Chair 1和Chair 2用到了同一个资源Chair001.unity3d，加载Chair 2的时候就不需要下载了。如果当前帧没有加载完毕，返回null等到下一帧再做判断。这就是WWW类的特点，刚开始用WWW下载资源的时候是不能马上使用的，要等待诺干帧下载完成以后才可以使用。可以用yield返回www，这样代码简单，但是C#要求调用yield的方法返回IEnumerator类型，这样限制太多不灵活。
继续LoadAsset方法：
C#代码
。。。
if (asset.Type == Asset.TYPE_JSON) { //Json
if (mScene == null) {
string jsonTxt = mSceneAsset.www.text;
mScene = JsonMapper.ToObject<Scene>(jsonTxt);
}
//load scene
foreach (Asset sceneAsset in mScene.AssetList) {
if (sceneAsset.isLoadFinished) {
continue;
} else {
LoadAsset(sceneAsset);
if (!sceneAsset.isLoadFinished) {
return null;
}
}
}
}
。。。
代码能够运行到这里，说明资源都已经下载完毕了。现在开始加载处理资源了。第一次肯定是先加载配置文件，因为是Json格式，用JsonMapper类把它转换成C#对象，我用的是LitJson开源类库。然后循环递归处理场景中的每一个资源。如果没有完成，返回null，等待下一帧处理。
继续LoadAsset方法：
C#代码
。。。
else if (asset.Type == Asset.TYPE_GAMEOBJECT) { //Gameobject
if (asset.gameObject == null) {
wwwCacheMap[fullFileName].assetBundle.LoadAll();
GameObject go = (GameObject)GameObject.Instantiate(wwwCacheMap[fullFileName].assetBundle.mainAsset);
UpdateGameObject(go, asset);
asset.gameObject = go;
}
if (asset.AssetList != null) {
foreach (Asset assetChild in asset.AssetList) {
if (assetChild.isLoadFinished) {
continue;
} else {
Asset assetRet = LoadAsset(assetChild);
if (assetRet != null) {
assetRet.gameObject.transform.parent = asset.gameObject.transform;
} else {
return null;
}
}
}
}
}
asset.isLoadFinished = true;
return asset;
}
终于开始处理真正的资源了，从缓存中找到www对象，调用Instantiate方法实例化成Unity3D的gameobject。UpdateGameObject方法设置gameobject各个属性，如位置和旋转角度。然后又是一个循环递归为了加载子对象，处理gameobject的父子关系。注意如果LoadAsset返回null，说明www没有下载完毕，等到下一帧处理。最后设置加载完成标志返回asset对象。
UpdateGameObject方法：
C#代码
private void UpdateGameObject(GameObject go, Asset asset) {
//name
go.name = asset.Name;
//position
Vector3 vector3 = new Vector3((float)asset.Position[0], (float)asset.Position[1], (float)asset.Position[2]);
go.transform.position = vector3;
//rotation
vector3 = new Vector3((float)asset.Rotation[0], (float)asset.Rotation[1], (float)asset.Rotation[2]);
go.transform.eulerAngles = vector3;
}
这里只设置了gameobject的3个属性，眼力好的同学一定会发现这些对象都是“死的”，因为少了脚本属性，它们不会和玩家交互。设置脚本属性要复杂的多，编译好的脚本随着主程序下载到本地，它们也应该通过配置文件加载，再通过C#的反射创建脚本对象，赋给相应的gameobject。
最后是Scene和asset代码：
C#代码
public class Scene {
public List<Asset> AssetList {
get;
set;
}
}
public class Asset {
public const byte TYPE_JSON = 1;
public const byte TYPE_GAMEOBJECT = 2;
public Asset() {
//default type is gameobject for json load
Type = TYPE_GAMEOBJECT;
}
public byte Type {
get;
set;
}
public string Name {
get;
set;
}
public string Source {
get;
set;
}
public double[] Bounds {
get;
set;
}
public double[] Position {
get;
set;
}
public double[] Rotation {
get;
set;
}
public List<Asset> AssetList {
get;
set;
}
public bool isLoadFinished {
get;
set;
}
public WWW www {
get;
set;
}
public GameObject gameObject {
get;
set;
}
}
代码就讲完了，在我实际测试中，会看到gameobject一个个加载并显示在屏幕中，并不会影响到游戏操作。代码还需要进一步完善适合更多的资源类型，如动画资源，文本，字体，图片和声音资源。
动态加载资源除了网络游戏必需，对于大公司的游戏开发也是必须的。它可以让游戏策划（负责场景设计），美工和程序3个角色独立出来，极大提高开发效率。试想如果策划改变了什么NPC的位置，美工改变了某个动画，或者改变了某个程序，大家都要重新倒入一遍资源是多么低效和麻烦的一件事。
http://www.web3d.com.cn/new/teach/unity3d/2012/3/27/37137809.html