Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1357299
  • 博文数量: 281
  • 博客积分: 8800
  • 博客等级: 中将
  • 技术积分: 3346
  • 用 户 组: 普通用户
  • 注册时间: 2006-05-17 22:31
文章分类

全部博文(281)

文章存档

2013年(1)

2012年(18)

2011年(16)

2010年(44)

2009年(86)

2008年(41)

2007年(10)

2006年(65)

我的朋友

分类: LINUX

2008-09-17 21:11:43

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引擎了。当然,如果要开发一款功能强大的引擎,那还有很多很多的功能需要满足,其中一些功能将在后面的章节中有详细的描述。
阅读(1140) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~