|
我的理解是，比如3dmax软件建模，如果没有这个引擎的话，用opengl实现建模的话将是很困难的一件事情，需要编程绘制每一个点，对应每一个纹理坐
标进行纹理映射，而通过3d引擎，可以很轻松地建模，很多东西引擎都帮你实现了，你只需操作。用引擎实现的东西，架构相似，但看上去确是不同的。
有些功能，比如在大量文本中查找关键词，用简单的方法实现很慢，或者功能很难实现，让开发人员感到很难办，就像搬运工看到1000公斤的货物一样，当然搬
运工希望有一个发动机来拉动这些货物，这样他就不需要亲自拉了；程序员也一样，希望有一样东西来帮他解决让他晚上睡不着觉的问题，所以xx引擎就出现了。
引擎的特征：
1.能够解决很头疼的问题，这些问题不是需要非常高的效率，就是很难实现。
2.必须能够有良好的重用性，让人想用它的时候可以直接拿来用。
所以如果你做了一个东西，能够解决某些难题，这些难题在一定范围内普遍存在，并且能够重用，那么你就可以声称你开发了一个xx引擎。
最简单的游戏引擎就是游戏的主程序（不包含媒体数据）只要加上不同的游戏数据（如场景，脚本，设定...）就会变成架构相似而内容不同的游戏。游戏引擎说白了就是你先用其他语言做一个专门开发你的游戏的开发包。
3D引擎作
为一个名词已经存在了很多年，但即使是一些专业的引擎设计师，也很难就它的定义达成一个共识。通常来说，3D引擎作为一种底层工具支持着高层的图形软件开
发。你可以把它看成是对3D
API的封装，对一些图形通用算法的封装，对一些底层工具的封装。我无法准确的定义3D引擎的含义和作用，因为针对不同的用户和开发项目，3D引擎完成的
功能可能都有不同。因此，我将从功能的角度来定义3D引擎，这种定义法也许能更确切的表达出一个3D引擎的真实含义。
3D引擎最基本的功能应该包括：
1. 对3维场景的数据管理
这里的数据管理是一个比较广泛的定义，不同的3D引擎也许会拥有其中一个或多个功能。这些功能包括：场景管理，对象系统，序列化，数据与外部工具的交互，底层3维数据的组织和表示。
场景管理：
这个名称相信对3D引擎有一定认识的朋友都很熟悉了。通常它和SceneGraph同时存在于一些架构方面的资料中。由于3D引擎可能会用来管理一些庞大
的3D世界，在这个世界中物体与物体之间通常存在一些 相关/从属/影响与被影响
关系，如何组织这些关系，并确切的将这些关系与3D引擎的其他功能联系起来，就是场景管理需要完成的工作。常有朋友问我场景管理是用的哪种算法。从我的理
解来讲，场景管理是一种设计模式，而不是一个具体的算法，也许你会最终选择BSP/QuadTree/Portal/...作为场景管理树的结构，但是这
些已经是实现层面的东西了，而且它们也远远不是场景管理的全部。因此我认为Scene Manager 和Scene Graph manager
这两个概念还是分开理解比较好。
场景管理首先需要考虑如果表达场景中物体的关联关系，这部分通常是由场景图来实现的。通过一个一对多的树形结构已经可以满足要求，当然考虑到数据层的共享
和维护，允许子树进行Clone也是前期设计时需要考虑的一个方面。再此之后，就需要考虑物体之间材质的继承关系，动态环境如何嵌入到你选择的场景图中。
在一个考虑到交互和触发机制的引擎中，还需要考虑物体之间如何发送消息。（比如一个结合了物理引擎的场景）。实际上在整个引擎中你所涉及到的各种算法和设
计，都或多或少的会和场景管理发生联系。比如在一个实现动态光影的引擎中，物体之间如何实现相互遮挡，光源的影响范围如何在场景图上继承，都是在设计时需
要考虑的问题。
2。功能合理的渲染器
之所以要说是合理的渲染器，是因为一个引擎的渲染能力是由多方面决定的。比如一款以实时游戏作为目标的游戏，会选择基于光栅化的渲染算法。在这种设计前提
下，几何体一级的数据不会过于详细，例如物体表面的BRDF，折射率，纹理坐标空间的变化率，切线空间的变化率（当然随着硬件能力的提升和Shader能
力的发展，这些数据也会出现在一些比较高级的游戏引擎中），这时候即使你在设计初期就考虑到这些数据需求，并将它们表现在了Render中，最后也不会由
任何意义。
3。与外部软件的交互能力
简单的说，就是开发工具。任何一款3D引擎如果没有开发工具都不能称为是完整的。这些开发工具可能是一些文件转换器，场景编辑器，脚本编辑器，粒子编辑器....
有了上面3种功能，就可以称为3D引擎了。当然，如果要开发一款功能强大的引擎，那还有很多很多的功能需要满足，其中一些功能将在后面的章节中有详细的描述。
|
