您还未登陆，请登录后操作！
监控矩阵是什么意思?
简单是说是 多元一次方程组的系数排列的有行有列的数表。
我们用主要用它来解方程或者是判断方程解的情况。
实际上，矩阵理论是代数理论的一个重要的内容，在自然学科各分支和经济管理等领域，它也是数学有力的工具之一。
例如在不同的条件下，不同的农作物的产量可以用它来表示。
经济领域内，相似的商品由不同的厂家生产出来的也可以用它表示
矩阵是大学里 数学的一门课程
您的举报已经提交成功，我们将尽快处理，谢谢！
大家还关注
<a href="/b/90IXzt39v.html" target="_blank" title="<中学数学教学研究》怎样投稿矩阵-灵魂的格子
《矩阵-灵魂的格子》说的是什么？&&
11:04:11|&&分类：&|举报|字号&订阅
作者尝试着解释涉及未来的两个技术：①涉及“概念处理系统”是怎样工作。（不是物质的处理系统）②怎样使用不断产生的最强有力的“处理系统”接入界面。
作者描述的是一个科技前景——视觉界面，也就是视觉计算机。他使用大量的矩阵（几何），一步步来阐述，这个视觉界面的运作。
这个视觉界面，不是用手操作，而是使用意识操作。
这个视觉界面背后的处理系统，是建立在几何的概念上。本书介绍了应用到视觉界面的全部格式功能、以及颜色代码、字母、浮雕等等。
矩阵，即几何。意识利用几何来表达和处理规则。
这本书是作者对生活的新发现，有完整的理论支撑，使用大量的矩阵几何来说明一切，是实践性和实验性的结果。这些矩阵几何是意识的处理系统，是意识对概念和规则的表达。
本书引用一些宗教术语，只是为了揭开一些认知上的迷团。就如同作者所说：“虽然，我经常提及哲学和神学，但是提到任何的宗教或哲学，不是我希望做的事情。在与一些人沟通的时候，我经常被他们劝告，查阅哲学和神学的资料，或许会发现一些真相……我所查阅的宗教著作，它们唯一提供幸存的、有关我提及矩阵知识的证据。”
书中所提到的“上帝”“男孩”“灵魂”“天使”，代表几何结构和内容，仅仅是“标识”的需要和代号，与人类所称呼的没有关系。
&“上帝”这个词是“程序”，也就是几何符号GOD，那是一个几何结构。上帝，即GOD是来自希腊字母这三个希腊字母，构成一个标识。
摘自第三章：
——所以，这就是为什么说“上帝创造一切”，因为上帝在ZION（在中文的翻译中，是锡安山）的结构里。GOD与ZION一起，生成各种字母和符号，这个结构包含一切规则和原理。在古代，人们把GOD与ZION合在一起的图像，称为ZIONic&。
上面说到，希腊字母来自ZIONic，不仅如此，希腊字母表中的24个字母，都可以在这标识中找到。
“男孩”存在于意识两端之间，起到交流作用。
摘自第十一章第一节：
——男孩“阅读”意识一端的信息，通过90°旋转编辑那信息。然后，继续另一个90°的旋转，将信息提交给意识另一端。这就是为什么，男孩被认为是一个“传递者”……分离意识两端的“旋转”是180°。区别两个功能的“旋转”是45°。这两个功能是处理系和图书馆。
“灵魂”是一个机构或结构。
摘自第十四章第一节
——灵魂是什么？
它是一种“现存的计算机”系统，是供给意识在“阅读”和“解码”书本的时候使用。这些书本包含在“主结构”，即一个巨大灵魂的“永久性”图书馆中。所有灵魂是它的一部分或包含在里面。
在灵魂里的书本，容纳所有的数据和背景信息，也就是，容纳被我们称为“地球”、“宇宙”或别的“世界”的每一个“物种”和“环境”。
灵魂怎样处理数据？
通过一个处理系统，那是建立在几何基础上和光的概念上。
书本怎样储存在灵魂里？
它们不是储存在3D里，而是以概念的形式存在。
摘自第七章：
我称有翅膀的结构为“天使”。如同前面所说，
称为天使的理由，是因为它们是矩阵的I/O端口，他们被使用在交流上。
本书的争论点：意识与大脑的关系。
意识究竟是存在于大脑内，还是独立于大脑外。大脑究竟是意识的起源，还是意识的解码。这些问题，科学界早就有争论，而且一直都在争论和论证。1963年获诺贝尔医学奖的英国科学家约翰艾克理教授在他的获奖论文中说：“神经细胞彼此之间有无形的沟通物质，这就是灵魂的构成，人体内蕴藏着一个非物质的思想与识力的‘我’，它控制着大脑，就好比人脑指挥着电脑，它使大脑内的脑神经细胞发动工作。这种非物质的‘识我’，在肉体大脑死亡之后，仍然存在并且有生命活动形态，可以永生不灭。”
约翰艾克理教授没有提到“意识”，但是已经提出非物质的“识我”。
聪明的读者一定看出来了，我用约翰艾克理教授获奖来为自己的说明“注脚”。我这样来搬弄，其实本书的作者并不喜欢——他认为，矩阵知识和视觉界面是他自己的发现和见证，具有科学探索意义。
意识与大脑的关系，有待于科学家来论证和探讨。这本书，是作者的一个见证和发现。它表达一种新科技前景。可以把它叫为一种见证，一种科技，也可以叫它为一种“存在”。
（想想看，如果“意识独立于大脑之外”观点获得普遍性的认同，这对世界的影响将是“翻天覆地”的。那将会引起一系列的知识革命）
总之，在这本书里，作者发现了，或者说论证了这样的观点——
真实的你，即生活，实际上没有维度，不涉及任何你体验的宇宙。它不涉及能量、万有引力、磁性能、时间，或者任何其他性质。
肉体仅仅是通过程序产生的故事（体验）。这故事涉及浮雕、字母、数字“串”，以及其它奇怪的像字体这样的“串”。这些控制着图像和故事（体验）的相互作用。头脑本身，是意识，也就是知晓或生活的软件（程序）所产生。所以，我们涉及身体和宇宙的全部体验，是一个故事。这故事是在一个巨大的网络中播放，通过意识两端之间的交流产生。
大脑只是一个界面，是意识的译码器或解码器，意识通过它来体验环境或世界。
在矩阵的“结构”里，有“所有”的“起源”。“所有”是永恒的，从来不消失。
3、各章“引语”
为了方便阅读，我将各章节的“引语”摘录于此。
第一章“电脑程序一样的世界”
我们相信是宇宙的东西，唯一涉及一个精心制作的、符合体验的“第一人称的计算机游戏”。第二章“重新认识意识”
意识也称为生命/生活、察觉、本我、感知。
意识没有大小，尺寸。
意识是单一逻辑，不是双重逻辑。意识概念性地看事情，包括看概念。
意识的内容是“无”，也是“有”，或者说是“无中生有”（something which is
nothing)；功能是察觉；动作是光；语言是几何。
意识不是由人体产生，它存在于人体之外。大脑只是一个界面，是意识的译码器或解码器，意识通过它来体验环境或世界。
意识的语言是几何，它用几何来表达规则、定律、原理。
意识创建第一个矩阵是“眼睛矩阵”。“眼睛矩阵”是主地图，意识通过它来处理格式和功能。
意识是唯一的，只有一个意识。但意识有无数的分割，或者说，意识有无数的小水滴。意识与小水滴的关系，也就是我们所说的“大我”与“小我”的关系。“大我”与“小我”处在两个末端，即“里面”和“外面”。
第三章“上帝，GOD的符号”
“上帝”这个词是“程序”，也就是几何符号GOD。
GOD是ZIONic文字。不仅如此，今天我们所知道的语言字母都源自ZIONic。ZIONic是“纯意识”的语言，使用在灵魂的处理系统中。第四章“眼睛矩阵”
我的目标是，使用一个基于几何的格式，创建一个可以与意识进行交流的“界面”。实际上，从第一个矩阵开始，系统就已经存在。这个矩阵就是眼睛矩阵。
眼睛矩阵是意识的程序舞台，用于数据处理。在这舞台上，意识通过对舞台的探索，通过对格式的配置、组合、分割，装载和拆卸，也就是，通过结构或几何的图案识别，来发现功能，表达规则和概念。
“眼睛矩阵”地图是主地图，其他地图的使用，依赖于你想做什么来决定。
第五章“八边形的环”
在矩阵的结构里，有多种处理任务，也就是，在矩阵里，结构中有结构。每一个结构有自己的处理，通过分割配置后，产生别的结构和处理。怎样分割配置，看处理的需要。
第六章“六角星应用于载入程序”
在前面，我们谈到了GOD的符号。这个符号构成一个六角星，也就是古代人们所称的“大卫星”。
这是意识创造的一颗星。在矩阵里，它有着非同寻常的作用。
关于这星，我将进行多一些的解释。记住，DAVID（大卫）不是今天人们所想像的“大卫”。大卫不是人，而是矩阵里的一颗星。圣经里所描写的大卫，只是一个寓言故事，如果我们想理解这些古老著作写的是什么，需要在这个方法上进行理解。
第七章“矩阵里的I/O端口”
记住，我们是跟随着意识在眼睛矩阵程序舞台上探索。所以，我们要尽可能地理解这个舞台所包含的各种格式功能。这些理解很重要，因为数据处理涉及几何的概念表达。意识，通常被认为是察觉、感觉或生活。它籍由交流系统的形式来识别事物。所以理解几何语言很重要，理解每一个几何结构表达了意识或生活的什么内容。
第八章“世界是平的”
世界是平的，如同在一堵墙上。
我们体验的世界是在一个平面里。
第九章“打开矩阵里的书本”
每件事来自“无”，借助于一个“故事”或“文字”来体现。这“故事”不是由你或我来控制，而是通过“书本”的“文字”来控制。
称呼为书本，是因为可以对它进行阅读和写入。
我们的体验来自矩阵里的程序“书本”。有两个不同的程序：
①环境
②物种，即我们的身体……那是与选择的环境相互作用。
那么，程序的内容怎样获得播放，并表现称为宇宙这个世界呢？
这需要我们理解世界的真实构成，真实的世界究竟是什么；理解程序书本的构成，以及下载、打开这些书本的相关格式功能。
第十章“使用视觉进入矩阵”
“视觉的界面”是基于意识的几何规则。
意识的系统是建立在概念上，你视觉的世界也是建立在概念上，意识依照着这些概念，创造一切。
我们闭上眼睛，看到视野里出现的矩阵或世界，也是意识概念性的作用。这是概念对你视野产生自动化的影响，或者说创造。
第十一章“意识两端的交流”
与纯意识产生交流的“界面”，关键在于一个格式。这是一个可识别的普遍性标准的“交流”格式。通过这个格式告知意识，“里面”意识（中心）正尝试着跟“外面”的意识进行“交流”。
如果我们使用一个正确的“格式”，而且正确地进行“交流”，那么，意识会作出“回应”。意识对愚蠢的问题，不作出回应。
意识拥有的智慧，远远超乎人类的理解。这一认识非常重要，因为这直接影响到我们交流的“结构”和“内容”，也就是影响到问题的结构。所以，我们的提问，结构上必须是智慧和恰当。
同时，如果我们提我们所知道的“问题”，也不会获得“回应”。
在这样一个“格式”里，我们可以直接地“写入”提问。但是，使用这个格式，必须要懂得一些规则，也就是需要我们学习和理解几何的基础格式，理解矩阵里的每一个结构和位置，这样，我们才知道，使用与每一个结构和位置有关联的提问。
第十二章“宇宙是一个游戏房间”
眼睛界面有许多不同的应用。
一个主要的区域涉及这个宇宙的探索。
这个宇宙是纯意识一个“游乐场所”，是供你玩乐的地方。
第十三章“信息转换及处理”
记住，我介绍的是一个界面的应用，涉及到程序内容的处理，也就是，怎样将隐藏在格式里的程序内容，即“物种”和“环境”的内容释放出来，通过处理，产生我们的体验。
实际上，我所介绍的全部内容，都是关于处理。
所以，处理自然涉及信息和转换。
①信息：
程序内容在永久性图书馆里。
永久性图书馆存在于六边形和五边形的格式里。六边形的“永久性图书馆”包含图片；而五边形的“永久性图书馆”包含涉及几何和图片的“故事”。
②处理：
一个“圆盘”或“平面”有两个面。一面是产生我们体验处理的八边形格式，而另一面是储存我们体验数据（内容）的六边形格式和五边形格式。。
③转换：
所谓转换，就是将程序内容从永久性图书馆里，转换到八边形格式的灵魂处理系统里。
意识根据体验的诉求，在永久性图书馆里选择信息。意识采用选择和下载功能，将信息下载，通过“指令”的控制，放置到八边形中的“正方形”格式里，通过“八边形”格式功能，对副本进行处理。
这个选择和载入功能，是一个小的八边形格式，相当于一个选择和载入“键”。
第十四章“灵魂是现存的计算机系统”
在这里，让我描述“视觉界面”的工作，它不仅应用在输送系统，还应用在别的领域，比如建筑房屋和道路，改变土地轮廓，输入来自地球以外的事情，以及有关遗传的编辑，体验或进入别的世界等。
但是，过程不发生在界面。几何是以程序为特征，是与意识交流的一个方式，意识通过阅读几何语言来识别交流内容。所以实际上，界面只是一个信息板。
实际上，真实的处理发生在创造最大效能、被称为“灵魂”的计算机系统里。灵魂的工作类似于一个巨大的计算机和处理系统。
第十五章“在矩阵里，有一条管道进入地球”
我们所体验的宇宙和物种是在灵魂里面显现，灵魂仿佛是一个程度极高的处理系统，导致宇宙和物种图像一起活动或相互影响。因为程序是如此复杂难懂，是如此完整，它给予我们真实的感觉。但是实际上，所有一切仅仅是全息，是基于精确规则或原理的几何概念。
第十六章“体验矩阵”
实际上，我所描绘的矩阵地图，是来自复制。我将自己看到的、体验到的、了解到的描绘下来。
意识通过有步骤地、一个格式、一个浮雕的显示，来表达程序功能。
所有的一切，是因为一次“濒临死亡”体验引起……
第十七章“DNA，666的几何规则”
与人（物种）程序有关是DNA。这涉及到称为“666”几何结构的“运算规则”，或者说涉及到人（物种）“兽的运算规则”……兽，即动物。
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。诸如GTA，武装突袭之类的游戏中，开发者是如何实现超大地形的？对于这一问题有什么主流的解决方案？补充：例如一些开发者提到的浮点精度问题是如何解决的？又如果npc在玩家视野之外是如何运算的？？
----------------------------本文同时发在我的 Blog，在那里或可获得更好的阅读体验：----------------------------首先肯定一下，这是一个非常有趣的问题。在这个答案里，我将尝试先回答主干问题，再对补充说明里的几个问题简单说一下。下面是本文将涉及到的一些相关技术的列表，（需要说明的是，这些技术单独来看并不复杂，实际动手实现并理解各种取舍以后，在项目当中针对具体的需求去设计和搭配才是关窍之所在）----------------------------一、程序技术篇：算法和架构（Programming Algorithms & Architecture）1. 无限循环的平铺地图（Infinite Tiling）2. 可预测随机数和无限宇宙（Predictable Random）3. 精度问题解决方案（Precision Problem Solving）4. 超大地形的处理 （Terrain Visualization）
4.1 古典算法（从 GeoMipMapping，Progressive Mesh 到 ROAM）
4.2 层次的艺术（Quadtree 和 Chunked LOD）
4.3 以GPU为主的技术（Paging，Clipmap 到 GPU Terrain）5. id tech 5 的 megatexture （超大地表上的非重复性海量贴图）6. 过程式内容生成 （Procedural Content Generation）
6.1 过程式纹理（Procedural Texturing）
6.2 过程式建模（Procedural Modeling）二、内容制作篇：设计和创造（Content Design & Creation）1. 随机地图类游戏 (Diablo II) 中地图的拼接2. 无缝大世界 (World of Warcraft) 中区域地图的拼接3. 卫星地质数据的导入，规整化和再加工（一些飞行模拟类游戏）4. 超大地图的协同编辑：并行操作，数据同步，手动和自动锁的运用三、异次元篇：我们的征途是星辰大海1. 终极沙盒（EVE）：当规模大到一定程度——宇宙级别的混沌理论与蝴蝶效应2. 打通两个宇宙（EVE & Dust）：发现更广阔的世界——宇宙沙盒游戏和行星射击游戏联动----------------------------## 一、程序技术篇：算法和架构（Programming Algorithms & Architecture）### 1. 无限循环的平铺地图（Infinite Tiling）我们就从最平淡无奇的无限循环平铺地图说起吧。这应该是最原始，也是最没有技术含量的开放世界构筑方式了。技术上由于过于朴素，也没什么好说的，就是在同一个坐标系内像铺地砖那样展开，坐标对齐即可，就是接头处需要注意一下，不要穿帮就行。但是千万别因为简单就小看这个技术哟，上面列表里面的不少技术都是在循环平铺的基础上发展起来的，下面我们就来瞧一瞧吧。按照维度的不同，循环平铺有下面三大类：a. 在一维方向上扩展的横版卷轴游戏（以动作类游戏为主）和纵版卷轴游戏（以射击类游戏为主）。这些类型的游戏里，为了避免循环平铺给玩家带来的重复的疲劳，卷轴游戏会添加一些随机或动态的元素，比如超级玛丽里的背景上云朵的位置，分出多个层次以不同速率卷动的背景层，等等。b. 在二维方向上循环平铺的固定视角2D游戏。这一类游戏里，比较典型的就是 Diablo。暗黑中的随机地图生成，在本质上，就是叠加了一定的随机性，约束和边界条件的循环平铺效果。c. 在 3D 游戏里循环平铺高度图，形成连绵不断的地形效果。这在早期的模拟飞行射击类游戏里比较常见，现在已经很难搜到图了，我在上大学的时候写的第一个地形渲染 demo 就是平铺的，可惜刚刚翻硬盘已经找不到了555。这一类游戏，在平铺时适当地辅以一些贴图的变化，可以在很省内存的条件下，做出非常不错的效果。找不到游戏内的图，拿下面这个高度图来凑数吧。请大家脑补一下，把下面这个灰度图立体化之后，一块一块像地砖一样循环平铺以后，3D渲染出来的连绵起伏的直抵地平线（好吧，直抵远裁剪面）的山脉的壮观效果吧。----------------------------### 2. 可预测随机数和无限宇宙（Predictable Random）（本节内的描述和算法，部分参考了《Game Programming Gems I》 [“2.0 Predictable Random Numbers”]() 一文，请感兴趣的同学自行查找原文通读）有个传说中的游戏叫 Elite ，不知道有没有同学玩到过。据说这游戏运行在32K内存的机器上，其中16K还是只读的ROM。这游戏据说拥有难以匹敌的游戏深度：近乎无限个行星，每一个都有各自的名字和特征。可预测随机数本身是游戏内运用非常广泛的一个技术，这里我们着重谈一下它在为游戏提供（微观上）更丰富的细节和（宏观上）更广阔的世界的作用。这一技术的最重要原则是，为了在一个游戏世界中给出无限空间的幻觉，我们需要满足两个分解条件，可以把它们成为宏无限（macro-infinite）和微无限（micro-infinite）”。前者涉及到问题的空间规模，后者则任意一个对象所支持的最小细节层次级别。----------------------------从实现上来说，如何设定随机种子是这个技术的核心。由于给定一个随机种子，生成的随机序列是完全可预测的，那么根据游戏内的一些时空的设定，通过对随机种子进行一些定制，得到在游戏内任意某个时刻和某个空间点上完全可预测的行为就是可行的了。最简单的是使用以下几个元素与随机种子配合计算：1. 世界坐标（即 X Y Z 值，既可以表示空间中的某个点，也可以表示某个区域）2. 系统时间（可以用真实时间，也可以用游戏内设计者定义的时间，如果是前者的话需要考虑离线时的处理）3. 正态分布（在游戏里建一个查找表即可，这是最廉价的方案）这些因素加上对应的随机序列，已经可以营造出宏观上比较有深度的一个宇宙空间了。理论上，如果所有的随机性都是由给定的随机种子产生，而这些随机种子要么是游戏定义的常量，要么是查表得到，要么是均匀流逝，要么是由更高层次的随机种子生成，那么这样一层一层上溯到尽头的话，任何一个游戏内的宇宙，都可以归因到一个初始的种子，这个种子，就是决定论中经典物理学的所谓的第一推动吧。其实如果真做到了这一点，我们大可以把这个种子交给玩家，在首次进入游戏的时候掷一个 2^64 骰子。这是真正的上帝创世的感觉，想象一下，上帝说，要有光，于是掷出了骰子，第一推动怦然落地，整个时空的巨大齿轮开始运转，在不同的时间点和空间点上，更多的随机序列被生成出来...这幅图来自于游戏 Frontier：Elite II（出自[这篇文章]()），下面配的字样是：“This picture doesn't even begin to show the scale of the universe.” 大家感受一下。----------------------------微观上本质上也是一样的，只是把发散的过程倒过来，变成了逐级收敛的过程。为了在某一个点上放大时，能得到尽可能细致，准确和一致的表现，我们需要对较低层次的世界定义更丰富的规则和约束，比如黑洞对周围的影响情况，双星体系的轨道，恒星的种类与行星个数之间的对应关系，不同恒星系结构下行星表面的大气构成，等等。这样才能较好地平衡多样性和独特性，带来更真实的模拟效果和更令人信服的游戏体验。----------------------------### 3. 精度问题解决方案当足够大尺度的世界被创建出来时，就会自然而然地遇到精度的问题。同时这也是补充说明中提到的一个问题，这里我们简单介绍一下几种实践中的解决方案。先描述一下问题吧，我们知道，IEEE754 中规定的32位浮点数中，有23位是用来表示尾数的。也就是说，对于接近1的浮点数，可能会带来 2E-24 左右的误差（大约是 0.）以现实单位计算的话，如果游戏世界是边长为100km的正方形，那么在这个正方形的最远角落里，我们的最小空间单位是约 7.8 毫米；而如果是中国这么大的面积的话，空间误差将达**半米**左右。那么可以想象一下，如果是宇宙级别的游戏，采用32位浮点数作为全地图精度，那么实际误差可能会有多么大。在实践中，这种误差可能会带来以下这些影响：1. 无法将相邻的对象对齐。这种情况，场景美术（关卡设计师）应该会比较头疼，这对于游戏的编辑器来说是大问题了。物件没法在引擎编辑器里对齐；在不同的平台上，对齐也不一样；甚至不同的编译器，同一个编译器的不同版本编出来的引擎；对齐都不一样 ... 所以说处女座不要做 LD :P。2. 模型间的穿插和裂缝 本来封闭的墙角可能漏个洞，本来放在地上的石头变成了悬浮在空中。这实际上是上一种的变种。3. 骨骼动画的抖动 由于世界矩阵往往参与骨骼动画的运算，误差可能会被逐级放大，在那些最远离根骨骼的骨头上（也是玩家最容易注意到的地方），抖动可能会发生得非常剧烈。4. 物理模拟失真 一些柔体的模拟可能会直接失败，而刚体也可能会产生怪异的运动。碰撞系统也可能无法正常工作。所有这些一旦发生，都是很容易觉察的。一旦你发现在一个很大的坐标上有这些问题，而接近原点处问题却消失了，那么很有可能就是精度在作怪。而需要注意的是，出现这种问题，只和游戏中出现的数字的规模和跨度有关，和游戏选择了什么样的长度单位（如用毫米还是公里做单位）无关。----------------------------那么怎样使用有限的坐标精度来描述较大尺度的世界呢？最直接的方案是 使用双精度浮点数 （64 位），如果这是可接受的选择，那么就不必费心引入后面讨论的复杂度了。其次是 区域划分法 。我看到
同学已提到，不过这里出于完整性的考虑，再简单说一下。正如 Milo 同学所说，“把世界划分成不同的区域，在区域内的计算使用其局部坐标系统。”相对应的跨区访问，需要对应的“本地A -& 世界 -& 本地B”的坐标转换。还有一个方案是 节点中转法。正如移动电话的基站用来承载和协调整个通信网络那样，我们在游戏的给定活动区域使用静态信标，所有的逻辑上与之相关的单位，都以该信标的坐标作为参考单位，这样也可以做到把数据访问局部化。相距足够远的两个物体（相当于上面的跨区访问）交互总是通过静态信标来完成（正如移动电话网络中发生的那样），这样的好处是相关的复杂度可以隔绝在这个中转系统的内部。此外
同学提到了一个坐标转换法，“所有位置信息都以角色位置为中心做一次转换”。这正是 《Game Programming Gems IV》 [“4.0 Solving Accuracy Problems in Large World Coordinates”]() 文中的方案。这个方案可以解决部分问题（主要是渲染相关的问题），但是仍有一些问题需要考虑，比如：1. （上面提到的）编辑器内操作的物体，在序列化到文件中时，精度丢失的问题。2. 大部分物理模拟通常需要一个角色无关，摄像机无关的全局坐标系。等等。----------------------------### 4. 超大地形的处理 （Terrain Visualization）终于说到对超大地形的处理了。可以说从上世纪九十年代起，超大地形的可视化，一直是3D游戏领域热门的话题。今天我们就借着这个机会，把相关的算法和实现理一理吧。考虑到篇幅太长的话，俺的手指头招架不住，再一个不少对这个话题感兴趣的同学可能压根就不是程序员，一些实现细节可能我就只是简单提一下，贴代码什么的还是算了，尽量保证整篇文章的信息浓度适中吧。----------------------------总的来说，这十多年来，地形渲染技术的发展史就是一部生动的对现代GPU的开发，利用和改进史。整个过程大致可以分成三个阶段：一开始，GPU处理顶点能力很弱，这个时期的各种精巧算法（如一些VDPM和后期的ROAM），**尽力在用CPU来降低顶点的总量**，避免一不留神压垮图形系统；后来，图形系统的能力上去了，人们开始更多地考虑到**把地形系统融入到通用的场景管理**中去，如四叉树八叉树什么的就是在这个阶段被广泛应用的；再往后，GPU已经很强大了，CPU由于要承担更复杂的游戏逻辑，越来越成了整个系统的瓶颈，这个阶段，人们琢磨的更多的是，怎么**利用GPU给CPU减负**了，一直到如今，由 GPGPU 带动起来的异构计算，也都是这个路数。----------------------------由于内容比较杂，超大地形这个段落，按上面的描述，咱们分为三个小段分开来讲吧。让俺先沏上一杯碧螺春，为客官一一道来。#### 4.1 古典算法（从 GeoMipMapping，Progressive Mesh 到 ROAM） GeoMipMapping 是从纹理的 MipMapping 技术演化来的一个地表处理技术，原理上是根据任何一小块地形在屏幕上显示的实际尺寸（主要跟与摄像机的距离和起伏程度有关）来选择对应密度的网格，然后把不同分辨率的网格之间以某种方式拼接起来（没有这一步的话就会有裂缝），本质上是一种比较粗糙的区域 LOD 算法。顺便说一下，由于那时候针对顶点级的处理很多，导致这种T型裂缝很常见，以至于有个专门的名字叫“T-Junction”，针对这个的处理在当时也有很多方案。这是俺刚刚到老硬盘里刨出来的大三时写的 GeoMipMapping 代码，编了一下居然还能跑起来。有点土，别介意：P 可以看到不同的 MipMap 级别是用不同的颜色渲染的，也可以看到接头处 T 型裂缝的处理。唉，这代码勾起了俺的青葱回忆啊，那就顺便再来两张 T 型裂缝的示意图和消除过程吧。--------------------------------------------------------Progressive Mesh 是后来很流行的技术 Simplygon 的前身，原理上基本也是一致的，就是以某种方式渐变性地化简某个给定的 Mesh。渐进式网格有两种：视点无关的 （View-Independent Progressive Mesh，VIPM） 和视点相关的 （View-Dependent Progressive Mesh，VDPM）。两者的区别就是，前者预先离线生成好所有的渐变过程，运行时直接用就行（也是后来 Simplygon 采用的方案），而后者随着摄像机的位置和角度的变化，生成对应的简化模型。两相对比，VIPM的好处是运行时运算开销低，简化模型的效果好，缺点是费内存（因为数据都存下来了，当然后来增量的方式能省一些），而VDPM在当时是不错的选择，因为跟VIPM相比不用费额外的内存，而且对于视点（就是摄像机）变化不剧烈的应用，不需要每帧处理和更新对应的简化模型（普通的MMO类的一般一秒一次就够了），此外由于一些简单的遮挡剔除和背面剔除，能够比VIPM裁掉多得多的顶点（一般能多裁1/3到一半吧，在当时这可是头等大事）。总的来说，至少在当时，两者的应用都比较广泛，而到了后来，显存越来越大，总线却越来越紧张，VDPM这种典型的刷顶点的算法（比较费总线带宽）就逐渐失去了市场，这是后话了。大家可以在[这里]()看到一些 PM 在地形渲染上的应用。图咱就不上了，大家可以到 Simplygon 的网站上去看。----------------------------ROAM 可算作是上面提到的 VDPM 更进一步了。这个算法实际上借鉴了当时主流引擎的标配BSP的思路，想利用二叉树这个最简洁的空间描述数据结构，把（CPU端的）顶点消减发挥到极致。整个地表被组织成一个巨大的二叉树，有两个队列，一个是分割队列，一个是合并队列，分别用于处理摄像机移动时，增加进入视野的区域细节和消减退出视野的区域细节。精心设计的 ROAM 效果非常华丽（尤其是在线框模式下），你会看到在各种因素的影响（包括局部坡度，与摄像机的夹角，遮挡情况等等）下，各种三角形像魔术般的不断地变幻，生成和擦除超多的细节，效果非常魔幻。我印象很深的是当时连续打Quake3两个小时完全无感的我，调试这玩意的时候，每每不到十分钟眼就花了。网上找了两张比较典型的 ROAM 大家感受一下吧。--------------------------------------------------------#### 4.2 层次的艺术（Quadtree 和 Chunked LOD）其实用于空间管理的树状结构有四叉树和八叉树（还有上面的二叉树），但地表通常以前者居多。是因为，从小范围来看，变化剧烈的地形是3D的，适合八叉树在xyz三个方向上扩展；但当尺度大到一定规模之后，地形通常退化为相对扁平的2D空间，就像摊平了的地球表面那样，在竖直的Z方向上变化相对不大，而XY平面则是可能无限延伸的。Quadtree 四叉树很直白，具体的细节我就不讲了。值得一提的是四叉树往往也同时用于场景管理的快速剔除和查找，从理论上来讲，四叉树是一个平面上最迅速的用于剔除空间，定位一个物体，内存开销也是相对较低的数据结构。当用于地形渲染时，顶点剔除的效率也很高，我印象中仅次于高度优化的 ROAM。内存开销低主要是因为四叉树是可以完美展开到一个位数组里的，这样的话意味着整个树的利用率达到了百分之百——所有的空间都用来存储数据而不是维持结构。不过四叉树也不是啥都好，T型裂缝就比 GeoMipMapping 难处理，因为存在跨级的多段 T 缝，如下图：除此之外还有一些细节问题，这里就不一一说明了，地形的四叉树渲染还是有很多细节需要细心处理的，此处暂且放下不表。----------------------------Chunked LOD 是一种杂合改良的 LOD，其实糅合了上面说的不少细节，本质上是一种分区块地消减细节的技术。所谓 Chunk 是批量处理的一种方式，只是一种粒度划分的单位而已，跟现在 Java 的 GC 里分区回收概念上差不多。下面是典型的 Chunked LOD 后的效果：顶点多次过滤优化后的效果：效果在当时还是很惊艳的。通常不到50k的渲染数据量已经能有非常逼真的效果了。----------------------------#### 4.3 以GPU为主的技术（从 Paging，Clipmap 到 GPU Terrain）上面的基本上都是传统方案，这一节我们将逐渐过渡并挨个介绍一下以 GPU 为运算主体的算法。----------------------------所谓分页（Paging）实际上是仿效虚拟内存的运行机制的一种方法。由于地表的顶点数据都是静态数据，适合常驻显存。当世界尺度较大时，显存没法一次放入所有数据，那么系统就像虚拟内存那样，把那些暂时没有用到的数据交换出去。随着游戏的进行，Paging In/Out 也在不断进行，辅以一定的异步机制，加载到显存的延迟可以被很好地掩盖。玩家的直观感受就是：哇，海量的细节。----------------------------而 Clipmap 则比 Paging 更进一步，以金字塔的形式逐级把数据排列好，直接整体更新和渲染。从这里也可以看出 GPU 时代人们的思维方式的逐步变迁。从以前顶点级别（Vertex Level）的“锱铢必较”，到后来的一次多塞一点也无所谓，只要批次（Batch）少就 OK。下图可以看出 Clipmap 的基本思路。----------------------------所谓的 GPU Terrain Rendering 就是把高度图从内存里经由 2D Vertex Texture 搬到 VS 里去生成三角面，这样的好处是 CPU 和内存就被彻底解放出来了。只是访问上有一些限制，不像直接处理内存那样方便。具体的细节可以看这里：[GPU Gems 2: Terrain Rendering Using GPU-Based Geometry Clipmaps]()在 GPU 上做还有个巨大的好处是可以借助 Gaussian Noise 即时生成更多的细节了。直接拿一小块预生成的高斯噪点图在需要的时候叠加一下，就能在没太大额外开销的情况下，增加各种细节。如下图所示：----------------------------随着大家对 GPU 理解的深入，地形的处理又有很多的小技巧可以做，尤其是在 PS 里面，比如法线生成，动态uv展开，光照按需叠加/衰减什么的。不过呢据我所知没有什么非常别具一格的架构上的新思路了，所以就不再深入了。### 5. id tech 5 的 megatexture （超大地表上的非重复性海量贴图）megatexture 在当年（2007）是一个非常值得一提的技术。在这个技术出现之前，几乎所有的地表渲染用到的贴图都是若干张 blend 到一起后，以 tiling 的形式重复平铺在地表上的（包括比较典型的魔兽世界也是如此），这样的直接后果是图片的种类用多了耗资源，用少了又很容易感到单调和重复。而 megatexture 则是一张全局的超大贴图，从根本上避免了重复这个问题，理论上（实践上也是）能够生成非常壮丽和独特的地质风貌，是传统的刷地表无法创作出的效果。可以说这个技术让真正的全景地貌成为可能。----------------------------技术上的细节puzzy老师写过一个 pdf，强烈推荐感兴趣的同学搜来看一下（可以搜“ **ID Tech 5 中"Megatexture"针对地形的D3D9
基本实现原理 - 姚勇**”），珠玉在前，我就不啰嗦了。就来一张效果图吧（好吧我知道能坚持看到这儿的同学，这图基本上肯定都看过了）全局超大贴图对一个开放性世界的价值不言而喻。想象一下，跟拿乐高积木拼接出来的视觉效果（传统的 texture blending and tiling）相比，一幅万米画卷上，每个像素都可以随意描绘，是一种什么感受。 比如，你可以相对轻松地实现“整个世界的地貌瞬间被密集核弹蹂躏了一场之后”的效果。如果你想模拟整个生态环境的变迁，在不同粒度上的整体性修改更是无价之宝。----------------------------### 6. 过程式的内容 （Procedural Content Generation）“过程式生成”是一个不是很恰当的翻译，实际上更贴近本意的说法是“以程序的手段生成”，这里我们简洁起见，仍使用过程式生成的字样吧。过程式的内容生成是随机技术的在视觉效果上的一个重要衍生。这个技术虽然到最近才被广泛应用，但实际上从技术角度讲，在很久以前就已经有比较成熟的实现了。我手头的 2003 年出版的翻译版 Game Programming Gems III 中 就有 4.16 和 4.17 连续两篇文章以“程序手段生成的纹理”作为主题。这是构建超大规模的世界的一个重要的技术工具，尤其是与上面的 megatexture 技术结合起来，可以创造出非常令人震撼的视觉复杂度。下面是 sourceforge 上一个开源的项目 [PCity - Procedural Modeling and Rendering of Cities]()可以看出，对于过程式生成来讲，只要有非常小的初始数据集（meta-data），可以在宏观上达到很大尺度和复杂度的视觉效果。过程式生成有两大分支，一个是过程式纹理，另一个是过程式建模（上面的 PCity 属于后者），下面我们分别来谈一谈。#### 6.1 过程式纹理（Procedural Texturing）人们发现，自然界中有很多视觉效果是可以用数学公式加上一些简单的随机性来模拟的，比如云彩，水流，火焰，木纹，大理石，草地，夜空，大气等等，程序生成的纹理效果大大丰富了普通纹理能表现的效果，就好像是物理引擎给游戏增加了活力一样。一个普通的噪点图，在不同的情境下，作为辅助参数来参与生成动态纹理，可以产生出近乎无穷无尽的变化。这是过程式生成的云，出处在[这里]()。这是过程式生成的外观，使用了 Allegorithmic 公司的 Substance Designer，出处在[这里]()这里是一些分解材质，相当于过程式纹理的图素，出处在[这里]()。#### 6.2 过程式建模（Procedural Modeling）过程式建模特指以程序的手段动态建模。这是一个更大的话题，现在比较成熟的中间件的代表是 Speedtree，比如下面这个效果：完全不同风格的纹理，模型的任意杂合，随意生成，效果也非常真实，非常适合做恐怖游戏。在 Speedtree 的网站上还可以看到长成茶壶的树之类的奇葩。我还记得有一年的GDC，在 IDV 的 Speedtree 的展台看到的一段华丽视频，就是各种藤蔓植物在几秒钟之内长满了一个峡谷内的整个大坝，电影级的效果非常震撼，不知道现在网上是否还能找到。----------------------------过程式建模是一项非常迷人的技术，我本人也曾被深深吸引，在上面投入过一段时间的精力。2010年时，我在开发一款飞行射击类的 MMO，当时接触到了 [Gamr7]() 的过程式建模技术，感觉很不错，在飞行类游戏中，地面物体的建模可以完全以程序方式生成，这个对当时的我来说吸引力太大了。那时我花了一个月把 Gamr7 的技术集成到自己的框架里，并在上海世博会期间，与 [Bernard Légaut 先生]() 一起在世博会的法国企业馆展示了合作成果。摘两张当时的 PPT 吧。截图中的素材基本上都是使用了过程式自动生成的（不是美术手放上去的），树是用 speedtree 生成的。总得来说，过程式建模是一项潜力远远没有得到释放的技术，现有的工具还处于比较原始的阶段。在当年 PPT 的技术展望（Beyond the Tech）一节中，我写到“（过程式建模带来的）更高级的抽象使我们可以控制更高的复杂度，从而带来更丰富的细节 (Higher abstraction makes much more details and complexities manageable) ”时至今日，受限于技术的发展，这仍只在某个特定的主题（如 Speedtree 的植被模拟和一般的城市模拟）内有效。对于随机性的粒度，我们仍缺乏有效的手段去控制。当年展望时的两大 Expectation（一个是建立起模式和库抽象从而满足不同层次上的复用需求，另一个是如何统一过程式技术中的无序和有序，有效地控制随机性的粒度），现在据我所知仍是所缺甚多，颇为渺茫。当然了，对有志之士，这也不失为一大探索方向。## 二、内容制作篇：设计和创造（Content Design & Creation）聊完了程序方面的内容，我们来简单讲讲超大规模世界在设计和制作方面的一些情况。这方面因为我不是专家，只是做一下简单的介绍，不足之处，还请专业人士指正。### 1. 随机地图类游戏 (Diablo II) 中地图的拼接在暗黑二，暗黑三和类似的游戏“火炬之光”等游戏中，通过巧妙的拼接，理论上可以通过组合，生成近乎无限大的地图。这是暗黑三第二章里所有地图的可能的部件形状：这是拼接之后的样子：除了拓扑结构上可以任意排列组合以外，在每一个分片上预留足够多的通用接口也很重要。比如一扇拱门，可以是闭合不可交互的状态，也可以通向下一个直角走廊，也可以是通往一个副本的入口。要注意标准化的组件如果太多也会让玩家觉得单调和重复感过强，火炬之光在这一点上就做得不错。下图是火炬之光生成好的地图样貌：可以看到效果还是很不错的，一眼看过去已经不太有重复感了。### 2. 无缝大世界 (World of Warcraft) 中区域地图的拼接无缝世界类游戏的区域拼接和上面的随机生成类游戏的区域拼接是很不一样的。可以看出，不同的区域之间有着很长的接壤线和完全不规则的边缘。在这种情况下，为了简化制作，大部分边界区域以高山作为阻隔。你几乎不怎么会看到有建筑横跨两个不同的区域，原因也是在此。在沙盘制作时，通常的做法是在整个世界地图（对应的世界编辑器）中规划好每个区域的范围，也就是分区分块。每个区域由不同的设计师在场景编辑器中分开制作。在制作当前场景时，与该场景接壤的几个场景的最新版本都会加载上来，编辑器中可以提供一些方便的工具，便于在接壤处对齐。主要是高度的对齐和贴图的融合。前者通常的选择是高度上用 Smooth 工具平滑过渡到邻接场景，后者通常最简单的处理方法是真正的过渡点两边使用同一种贴图即可，实际的美术风格过渡（如果需要的话）在邻接地图的接壤线附近完成。一些贯穿不同地图的元素（如河流等）可能需要世界编辑器的参与来指定水平面的高度和区域范围之类的参数，但这一类元素通常不会太多，因为它们没有明显的 Gameplay 贡献，反而加剧了不同场景之间的耦合。如果游戏有动态的天气/环境氛围系统，那么不同场景之间需要做一些平滑的过渡，这些程序用普通的插值实现就可以了，设计师一般只用关心当前场景内的表现即可。当然有的游戏这个过渡做的不好，玩家体验非常生硬，也是有的。总得来说，这一类无缝大地图的复杂度主要是在编辑器的协同方面（后面我们会再提到）,实际的创作复杂度较前面的随机地图生成为低。----------------------------### 3. 卫星地质数据的导入，规整化和再加工（一些飞行模拟类游戏）超大规模的开放性世界地图，还有一类是直接使用卫星地质数据以加强整个世界真实性的。据我所知，育碧出品的 Tom Clancy's H.A.W.X. I & II （就是国内翻译的 鹰击长空 I & II）就是使用了 GeoEye 的商业级高分辨率卫星地图。既然用了真实的卫星地质数据，这一类游戏同样能生成非常震撼的效果，也就不用多说了。找两张截图大家感受一下吧：这一类的缺点是不能模拟真实世界中没有的环境（当然拿去再创作的不算）。这种真实数据的数据源就没什么好说的了，我简单说一下导入后的处理。通常导入后的贴图需要美术在色彩和明暗上二次加工一下，得到和游戏匹配的整体氛围。需要提供比较精确的工具给美术进行高度图和高分辨率纹理的拟合。此外通常这一类地质数据是没有 NormalMap 的，需要提供工具生成一下。还有就是，河流和湖泊这一类水体的处理，3D游戏通常在渲染效果方面对水面特效照顾得比较多。如何生成跟真实环境相匹配的河流和湖泊是一大难点。因为一般游戏里是有一个绝对水平的特效面片的，而如果给真实环境中得来的高度数据上配一个这种特效面片，通常无法跟真实的贴图相吻合（尤其是在山脉和峡谷等地形中的水体）如何提取真实的高分辨率贴图中的水面信息，自动生成对应的3D水面，也是一大话题。当然，如果不怕费事，也可以由美术直接做出来了事。----------------------------### 4. 超大地图的协同编辑：并行操作，数据同步，手动和自动锁的运用现在咱们回过头来聊一聊在 wow 这一类超大地图里，如何在多人团队内协同编辑的问题。----------------------------对于美术（这里专指负责场景的设计师）来说，常见的最简单做法是每人一块（或多块）区域地图，团队内维护一个公共的物件和贴图库。（物件和贴图可以由专门同事制作，需要时也可外包）在这种情况下，美术的并行化程度很大程度上取决于团队自身能力，对场景编辑器没有特殊的技术上的需求。超大地图的场景编辑器在加载周边邻接的区域地图时，需要显式地标示出其版本和上次修改日期，这样可以把邻接区域的修正工作量降到最低。最好的做法是能够通过版本管理软件，在有同事修改了邻接区域以后自动更新并重新加载（当然可以稍有延时，不用那么即时），这样的并行工作效率可以达到最高。真正的难题通常发生在策划那边，当需要编辑跨区任务或事件时，如果对 Ownership （也就是场景实体的所有权问题）管理不善。跨区系统可能会产生各种层出不穷的 bug。比如同一个 npc 承担了多个跨区职责时，其中的状态就可能会互相干扰，在杀掉某个 npc 这一类任务中更易出现，造成难以重现的 bug。这就需要提供明确的所有权管理机制，明确跨区访问的一般规则，提供简单的全局状态检测工具，在设计时就能提示出绝大多数潜在的冲突。当然，这些的先决条件是所有的区域数据，要么提供中央数据库管理，要么工具做到在团队网络内实时同步。----------------------------最后我们来说一下真正有趣的实践，就是“真正的”协同编辑。也就是任意个美术和任意个策划可以工作在任意个区域里。是的，你没看错，这才是终极的开发自由度。其实如果这是一个如典型的 WOW 那样的 MMORPG 的话，这就跟“所有的玩家登录到同一个服务器一起游戏”是同一个概念了。所不同的是，这里的“玩家”实际上全部是开发团队的成员，而且他们是有能力创造和修改这个游戏世界的。只要想通了这个概念，实践上并不像想象中那么复杂。由于美术和策划对同一个地图关注的焦点不同，我们只要把他们工作有交集的部分处理好，他们就能一起愉快地玩耍了。实践上来看，两者的交集通常是 a. 整个区域的逻辑高度图和 b. 所有的相对碰撞关系。也就是说，美术和策划的工作内容里，只要不涉及到这两者，都可以随便搞，但如果影响到了这两者，编辑器需要有能力提示正在修改的人会影响到什么（或按默认行为自动处理），通常是不难做到的。举个例子，策划放好 npc 后，美术去调整高度，把 npc 站的广场弄成一个山坡，那么要么提示美术这么干可能会影响到策划的设计，要么自动把对应的 npc 都重新调整位置，吸附在新的地表高度（一般编辑器允许设置为吸附到地表）。当两个美术在修改同一区域时，就涉及到锁的问题了。锁有两种，一种是在编辑时自动触发，场景地表以区域为单位，物件以 Instance 为单位，当编辑时自动把 Owner 设为当前编辑者，提交改动到服务器时可以选择继续锁或是释放锁。一种是手动锁，就是美术框住一片区域，主动加锁，这样有些时候更方便。编辑器制作者需要考虑的一些细节有：锁住的区域在其他开发者的机器上，需要比较显眼的提示信息；保险起见总是多锁一定的范围，以方便地表平滑等工具编辑时对周边区域的影响，等等。----------------------------## 三、异次元篇：我们的征途是星辰大海上面两部分“程序技术篇”和“内容制作篇”已经把大规模开放世界讲得差不多了，下面的内容我取名叫“异次元篇”，也是随便侃侃，大家随便看看就好。### 1. 终极沙盒（EVE）：当规模大到一定程度——宇宙级别的混沌理论与蝴蝶效应对于开放式世界来讲，如果没有真正与这个世界的尺度相配的开放式的交互，那么仍然是一个死气沉沉的世界。EVE，正是一个为了开放式交互而打造的超大的沙盒宇宙。在这个宇宙中，玩家拥有很高的自由度去探索，创造，建设，摧毁（针对自然环境而言），配合，领导，同盟，背叛（针对社会环境而言）。这游戏我就不展开介绍了，有兴趣的同学可以去看一下 [EVEWiki]()。有趣的是，当沙盒大到一定程度时，它会在很多方面展现出一种自平衡的性质，就像经济学中那只“看不见的手”，自然生态学中地球这个大型生态系统的自我调节和自我修复。在我看来，这也是开放式游戏的最大的魅力之一，也让系统的复杂度进一步接近真实世界。### 2. 打通两个宇宙（EVE & Dust）：发现更广阔的世界——宇宙沙盒游戏和行星射击游戏联动跟上面列举的诸多成功游戏范例不同的是，我接下来要说的，是一个虽然雄心勃勃，但却没有成功的例子。EVE 的制作商 CCP，是一个来自冰岛的很有趣也很有追求的工作室。在 EVE 的大尺度宇宙成功地运行了若干年后，他们选择了一个更大的挑战——设计另外一个大型多人在线游戏，把新老两个宇宙之间联系起来，让两个游戏内的玩家可以互动，相互交谈，配合，雇佣，指派任务，火力支援或其他的互动，最终打通两个宇宙，让两个大型多人在线游戏之间达到有机的协同和交互。CCP 从一开始就没有掩饰这个雄心勃勃的计划，这是一个令骨灰级玩家们震惊和眩晕的设计，也是一个电子游戏行业从未有过先例的构想。这个构想是如此令人敬畏和富有吸引力，以至于我在拿到 offer 后毫不犹豫地投身 CCP Shanghai 的怀抱。在游戏行业，我感到很幸运，能够有机会参与到这样一个项目中来。然而由于一些大大小小的原因，这个项目最终虽在 PS3 平台上线，却没有取得预期的成功。这里既然与主题无关，我就不打算谈论更多的细节了。在 CCP 两年间，我只是一个很普通的工程师，这里的工作经历极大地拓宽了我的眼界，让我知道了什么是真正的 fearless，对先行者们，我始终满怀敬意，对于自己有机会能参与这样的一个项目，我也始终心怀感激。----------------------------谢谢你们，让我能在晚上凝视夜空的时候，脑海中浮现出更广阔的世界。----------------------------（全文完）Gu Lu[]----------------------------[] 补记：一开始看这个话题有趣，想着说两句。没想到一动笔就停不下来，一口气写了七八个小时我也是蛮拼的。其间或有错漏疏敝之处，让行家笑话了。如发现错误，请不吝指正，在此先行谢过。如引发了有趣的想法，也欢迎在评论中一起讨论。[] 补记：今天中午有半个多小时 Blog 无法访问，后来联系 FarBox 才晓得是流量已经超上限，因为我用的是基础版，每个月100MB流量，可以用5年。结果今天一天的流量就把5年的配额全用完了……刚回到家以后亡羊补牢了一下，把 png 都换成了 jpg，省一点是一点吧 :) FarBox 反应很迅速，赞一下 :)另：文章无版权，可随意转载；是否注明出处，亦无要求。本文同时发在我的 Blog，在那里或可获得更好的阅读体验：
细节层次（level of detail, LOD）：模型需要支持细节层次，以减少几何渲染量，以及纹理数据的内存量及内存频宽。LOD有分离散及连续方式。详情可参与《》。串流（streaming）及缓存（caching）：把数据块在运行时异步载入，并按某些条件御载（如least recently used／LRU）。可见性检测（visibility determination）：除基本的视锥剔除（view frustum culling），还需要离线或线上进行遮挡剔除（occlusion culling）。除了渲染方面，也要考虑游戏模拟方面的部分。例如物理碰撞数据的载入，以及是否进行游戏逻辑的LOD等。----更新：浮点数精度问题由于浮点数的精度有限，单精度浮点数只有不足7个十进制数位，如果距离用米作为单位，离原点1公里的坐标，其精度只有大约1毫米。这对于渲染及模拟都有影响。解决的方法之一，是把世界划分成不同的区域，在区域内的计算使用其局部坐标系统。当对象从一个区域移动至另一区域，要进行坐标转换。但最麻烦的情况是两个区域的游戏对象互相交互，在交互时要把其中一个游戏对象的坐标转换至另一对象的坐标系。
谢邀。这个问题问得不是很具体。如果只是渲染超大地形的话，分块+LOD就可以了，实现个cache用IO线程动态地把需要的地形块stream进来就行了。
程序猿一枚 : )
