Dream Engine 2 的一些事(一)

从今年初 DE2 开始开发到现在已二月有余,进度还算顺利,这次除了次世代的 3D 引擎之外,我们还开始了对象引擎和逻辑引擎的开发,同时对引擎的资源管理的设计也做了进一步的改进。实际上所谓的对象引擎就是基于 RTTI 的可扩展的对象系统,游戏可以根据引擎的 RTTI 规则来扩展自己的逻辑对象,无需重新编译引擎即可在引擎编辑器和游戏中使用游戏对象,同时这套机制也作为引擎核心对象的管理和反射机制。逻辑引擎实际上是一个可扩展的游戏逻辑框架结构,它基于对象引擎,在其内部存在一个逻辑驱动核心,这个核心主要的工作就是不停的更新当前的逻辑序列–更新每个逻辑序列的状态,每个逻辑序列由一系列的逻辑片段构成,逻辑片断通过某种机制关联在一起,形成完整的游戏逻辑流程,在每个逻辑片段内部都可以实现特定的逻辑,通过结合对象引擎的 RTTI 机制可以对游戏对象进行控制,这样就可以实现大部分的游戏对象间的交互。与此同时,通过提供可视化的逻辑编辑工具代替传统的手工编写游戏脚本逻辑,可以提高游戏开发效率,缩短迭代周期。实际上这种机制并不是什么革命性的技术,从本质上来说和传统的 脚本 + CPP = 游戏逻辑 的方式没有什么区别,只不过是提供了一个可扩展的框架结构,将所有用 DE2 开发的游戏的逻辑纳入其中来驱动。但是,目前还有些问题没有完全解决,比如:对于 Online Game 的 Server 和 Client 逻辑如何编辑和部署? 众所周知,网络游戏的逻辑分散在 S/C 两端,而且还不可避免的存在时序和验证问题,如果是单机游戏这种方式可以工作得很好,但是网络游戏的情况就比较复杂。而且这里还有两个细节的问题,一个是策划如何通过逻辑编辑器决定哪部分逻辑是运行在客户端,哪部分逻辑是服务器端?第二就是性能问题,RTTI 也好,逻辑引擎也好,天下没有免费的午餐,要做到可扩展,就要付出性能的代价,高度的抽象和游戏对象的运行时动态查找以及编辑势必带来性能开销,所以,在性能和扩展性上找到平衡点也是摆在我面前的一个难题。

3D引擎方面,DE2 重新设计的渲染架构在开发的过程中感觉到比 DE1 要好许多,因为它完全不需要关心渲染核心以外的数据结构,同时 SG 也实现了在只知道很少量的渲染信息的情i况下向渲染核心发送渲染请求的功能,这样 SG 和 Render Pipeline 就被隔离开来,实际上在系统中存在一个中间层,我们称之为 Render Primitive Manager, 它负责在 SG 和 Render Pipeline 之间沟通,也就是说这个 manager 同时知道两者,但它不需要太多细节就可完成渲染数据的构建工作。为了更好的适应今后的多核心平台,多线程渲染架构也是我一开始就考虑的功能。由于在开发之前做了充足的准备,以及在去年实现的多线程资源管理的基础之上,再加上新的 Render Pipeline 和 SG 的完全分离,我大概用了 2 天左右的时间就完成了开发及测试工作。为了做到和逻辑线程完全并行,渲染线程完全是 lock-free 模式,对渲染线程数据结构的操作完全是异步方式,同时提供方便的回调机制满足特定的渲染以及渲染结果查询需求。

材质系统是变化最大的系统之一,第一代引擎的材质系统完全被废弃,为了更好的扩展性,我们重新设计了 Shader 系统,这样做的前提是整个引擎的着色机制完全基于可编程管线,只保留 D3D 10 还保留的固定管线设置,在固定管线的数据结构实现上参考了 D3D10 的架构,这样将来在迁移到 D3D10 或者后续版本会更加容易。同时我们还设计了一套 Shader 编译机制,实现了在不同着色环境下的动态 Shader 生成,而且做到了和顶点生成结构无关,在这方面我们参考了 UE3 的材质系统和材质模板。目前已经开发完成了可视化的材质编辑器,基本上做到了 UE3 能实现的材质效果我们都可以实现。

Advertisements
此条目发表在DreamEngine开发手札分类目录。将固定链接加入收藏夹。

4 Responses to Dream Engine 2 的一些事(一)

  1. kun说道:

    鄙人最近也在研究UE3的材质系统,发现其非一般的复杂,每个材质在每个pass中都会相应的shader。还有一大堆的DEFINE来决定不同pass不同材质参数下的编译状态,不能在shader编译机制上实现面向对象的编程太痛苦了,据说DX11已经可以支持了,赞!

  2. 文偉说道:

    你就说抄吧,中国人盗版惯了,对知识产权极度的轻蔑,美其名曰叫借鉴,其实还不是Copy,Paste,花点功夫去反省一下吧!

  3. 说道:

    UE3 的 Shader 是开放的,安装 UT2007 或者 Gow PC 版都可以看到 shader 代码。其核心思想基本上是基于动态组装 shader,利用了 shader compile 的优化特性,如果有过编译原理理论基础或者脚本实现经验的话应该比较容易理解。材质通道的概念和 3ds max 中的材质通道基本类似,在生成材质时动态替换成所使用到的 shader fragment,再进行编译。需要注意的是 UE3 的材质编辑器只是其材质系统的一部分,也就是说它只能生成 PS,通过仔细观察 shader 的代码可以知道,UE3 是通过定义一系列 VertexFactory shader 来完成渲染所需的 VS 的,比如静态模型和 skin mesh 是不同的 VertexFactory,只是内部的代码逻辑和计算顶点所需的 shader 常量不同,但是整体的 shader 框架是完全相同的,否则就无法做到统一的编译流程。整体思想大概这样,困难的是如何在自己的引擎中实现这个系统,以及很多细节的问题,比如 shader 常量的设置,如何在不同的着色环境下实现统一的 shader compile 机制,以及把编译细节屏蔽在材质系统外层等等。至于有人说我们只是 Copy Paste,这未免有些主观臆断了,我们没有 UE3 的源代码,谈何 Copy?即使有,整个引擎的架构都不一样,又如何 Copy?我是在 2006 年第一次接触 UE3 的材质系统,2008年底我才实现了类似的材质系统,没有长时间的经验积累和研究就算把 UE3 的源代码放在你面前你也无法理解。

  4. 文偉说道:

    楼主,不必动怒,清者自清,我只是提出一些质疑而已,也没有必要反唇相讥。看过你的留言,我相信你们的渲染系统还是有自己的独到见解的,退一步说即使是参考,也有其价值所在,不是嘛!?

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  更改 )

Google+ photo

You are commenting using your Google+ account. Log Out /  更改 )

Twitter picture

You are commenting using your Twitter account. Log Out /  更改 )

Facebook photo

You are commenting using your Facebook account. Log Out /  更改 )

w

Connecting to %s