Dream Engine 2 的一些事(二)

最近在忙着优化游戏,除了用到的第一代引擎本身的优化外,美术也在资源制作上开始优化,减面、合并材质、模型、减关键帧、合理使用粒子模块…这些规则即使在我看来也不容易把握好,可苦了这些很感性的美术了。同时策划也尽可能做些优化工作,比如增加场景布局结构的合理性等,游戏客户端和服务器端也在优化,总之全民皆兵。可以预见到今后 CL 游戏场景将会更复杂,所以我也在积极推进美术工具的使用,以提高他们的生产效率,比如 Light Map Editor,CL 是基于静态光照来表现游戏场景的,之前都是美术在 3dsMax 中手工去调节整个场景的顶点色,费时费力,上周美术试用引擎提供的 LME 之后,提出一些反馈意见,我们也在改进之中。
说到静态光照,不得不说 DE2 的光照方案,在开始阶段我并没有确定开发 DE2 的静态光照技术,直到上个月的 GDC09,我了解到,UE3 这次的改进主要在静态光照系统:增加了称之为 LightMass 的系统,可以实现静态的全局光照,这样可以节省大量设置场景灯光的时间,使用这套系统可以可以告别以往一个 Level 要上百个光源的历史了。CryTeck 也推出了 CE3,实际上是 CE2 的低配置版,但游戏开发本身的功能也增强了。无论怎样,从这两款引擎的变化来说,引擎开发商们更务实了,渲染技术的发展也不像以前那样激进了,甚至还有些倒退,也许是考虑到金融危机的影响,PC的硬件发展将会放缓,从这方面来说是也许个正确的选择。根据这些信息,DE2 的静态光照系统也基本定型了:支持全局和局部静态光照,支持 Normaled LightMap 和普通的 Light Map,支持 Vertex LightMap 和 Texture LightMap。实际上 DE3D 早已经实现了局部静态光照,流程也已经完善,所以在此基础上开发 DE2 的静态光照系统是相对容易的。首先我实现的是 Normaled Light map,在翻阅了 HL2 渲染技术文档之后动手试了一下,基本都实现了,值得注意的是 bump basis 是在 tangant space 定义的,生成 lightmap 时要在 tangant space 生成光照信息,另外还要注意和引擎定义坐标系、Matrix 的行列优先级、旋转手相性要一致。Diffuse 光照好了,接下来是 Specular,HL2 中的静态 Specular 是通过 Envorment Map 来实现的,这种方法比较麻烦,而且需要预生成额外的纹理,我仔细研究了一下 UE3 的静态 Specular 的方式,通过简单的 Normal 和 bump basis 的 Dot 计算出 Specular 的系数,即可得到效果不错的静态 Specular,其实本质上也不算是静态,因为计算是实时的。接下来是全局光照,我希望用 Radiosity 来实现,参考了一篇 GPU 实现 Radiosity 静态光照的文章,完成了基本框架,已经交给同事去细化。
最近 Aion 挺火,我玩了一下,对其中可以生成 Alpha 物体的静态阴影很感兴趣,遂想如何实现,首先想到用 GPU 生成 LightMap 阴影,因为可以通过 texkill(clip) 过滤掉指定 alpha 值的像素。也曾想过用现在的 CPU 方式,但问题是第一是借用物理引擎的射线检测实现的阴影,当场景复杂光源较多时生成时间很长,第二就是很难生成 Alpha 物体的阴影(比如树叶),即使做到,实现上比较复杂,而且不灵活(比如无法获取美术在 Material Editor 中设定的自定义 Alpha Ref Value)。前段时间在 MSN 上和一位朋友 http://ixnehc.spaces.live.com/ 聊起这个话题,他与我分享了他的实现方案,给我很大启发:这是一种类似于 Deferred Shader 的方式,将需要光照计算的 LightMap Sampler 记录在浮点纹理上,通过 DS 方式计算光照,得到最后的 LightMap 数据,Shaow 采用和 Shadow Map 类似的方式生成,但存在精度问题,但仔细想会发现,对于方向光源,可以采用类似于分段 ShadowMap 的方式提高精度,对于点光源或者聚光灯,一般范围不会非常大,在大多数情况下也能满足要求。周一和同事们讨论了这个技术方案,认为可行,并制定了详细的技术实现细节,目前正在开发中。这样 DE2 将实现以 GPU 为主导、CPU 辅助的静态光照生成技术,将进一步提高静态光照的生成效率。另外,我们还讨论了 UE3 LightMass 系统的一些静态光照的技术细节,例如 Emmisive Lighting 等,这些也将在 DE2 中实现。
资源管理,整个三月份主要是在做这部分功能,由于之前的设计方案考虑到资源查找的优化,引入了资源ID 的概念,但这个优化增加许多复杂性,从结构到实现,从底层到高层,同时还牵扯出多人编辑资源的 ID 同步问题,以及 AutoPatch 时的 ID 同步问题,为了解决这些问题,我们还需要开发辅助的模块和工具来完成整个功能,甚至差点搞出个 C/S 结构的分布式编辑器模式。但即使这样,我们还是把整体设计方案确定了下来,包括所有的技术细节。某天晚上加班,引擎的同事问我:我们的资源管理是不是太复杂了?这让我陷入了沉思:我的初衷是什么?为什么现在会这样复杂?这样带来的性能提升和开发复杂度以及后期维护的成本是否平衡?经过一个周末的思考之后,痛定思痛,我决定去掉这个包袱,虽然性能没有提升,但是系统变得简单明了(Kiss 原则 )。周一我和同事们又仔细分析,最后决定丢弃之前的设计,轻装上阵。只是没想到这个决定得到了大家的一致认可,不约而同的都松了一口气。
逻辑编辑器,前几天我们讨论 DE2 的对象管理,讨论到最后就讨论到逻辑编辑器上来,由于之前对于网游逻辑的 Deploy 的问题一直悬而未决,使得我一直都在怀疑 Logic Editor 的实用性,因为这将改变既有的游戏开发模式,这种改变需要一段时间来适应。会议开完我的思绪仍然停不下来,抓住公司的 Server Engine 的主程序继续讨论,从开发模式的改变到实现的技术细节,我们讨论的比较深入,甚至可以肯定第一个用这种方式开发的游戏一定比传统的方式要慢,但从长远来看,是改进了游戏开发模式,提高生产率。所以,基本上确定了技术方案以及新的游戏逻辑开发模式,尽管还是有几个不确定因素。
上周把 DE2 的开发计划提交给了 CEO,这是一个粗略的计划,除了 DE2 的开发,还包含对 DE3D 的维护以及 Support 游戏项目的工作。DE2 的开发是我主动提出来的,作为公司的 CTO,我始终认为技术是游戏研发公司的核心竞争力,没有这个基础,在开发上很难走的更远。网游也在不断发展,玩家的需求会越来越多,游戏的功能也越复杂,对技术的要求也越高,虽然一款游戏的成功是多方面决定的,但是至少在技术层面,如果可以做好足够的基础保证,甚至走在业界的前端,将是保证公司持续竞争力的重要因素。
虽然,这条路难走,障碍很多,但我依然会继续前行。
Advertisements
此条目发表在DreamEngine开发手札分类目录。将固定链接加入收藏夹。

发表评论

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

WordPress.com 徽标

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 /  更改 )

Connecting to %s