« 2014 IGF 评选 | 返回首页 | 随机地形生成 »

ejoy2d shader 模块改进计划

由于有公司很多同事参与 ejoy2d 的开发,所以 ejoy2d 这个项目已经转移到 ejoy 的 github 名下。

有更多项目的参与的情况下,原来 ejoy2d 的简单构架慢慢显出一些局限性。主要是不同的项目会根据项目的需要(通常是针对某些特定需求的优化,以及特别的效果需求)修改底层 shader 的部分。最早设计的时候,因为考虑到只是用于 2d 游戏的开发,所以把 shader 模块实现的比较简单。特别是 attribute layout 是固定的,而 uniform 管理也没有留下太多扩展性。

在现代手机的 GPU 架构下,从渲染层渲染层 API 看,其实 2d 和 3d 其实没有本质上的区别。都是基于三角片渲染的。需要把顶点上传到 GPU 中由 vs 处理,在最后对像素做 fs 渲染出来。

而 2d engine 和 3d engine 的区别通常在于 2d engine 的顶点变换很简单。不需要用 projection matrix 和 view matrix 做变换。2d engine 中的对象多半是四边形,数量很多,常见的优化手法是将大量的四边型合并到同一个渲染批次中;所以 world matrix (以平移变换为主)在 CPU 中和顶点计算再提交更常见一些。

2d engine 从应用上说,就是在处理一张张图片。所以对图片(四边型)的处理的变化要多一些。这使得 fs 要多变一点,需要引擎提供一定的可定制性。但很少去处理 3d engine 常见的光照投影这些东西。更多的是为了优化贴图用量等目的而技巧性的去使用一些图片。

突出 2d engine 的专门面对的业务的特性,而简化 GPU 提供的模型,用简短的代码构建 engine 框架,是 ejoy2d 设计的初衷。而且我也相信,简单可以带来更好的性能。所以一开始设计 ejoy2d 的时候,shader 模块的很多东西都被写死了,以最简单的方式达到目的。仅暴露了很少的外部接口,再在这些有限的接口上设计数据结构,做性能优化。


事情总要做两遍以上,才能做对。目前 ejoy2d 完成了三个项目,由十多个同学亲身用过。让我看到了局限性:前段时间我个人精力主要放在 skynet 上,而客户端在紧急的情况下,由不同的同学给 ejoy2d 打了好些补丁,来解决实际面临的问题。

我想,还是需要有一个更灵活一些的 shader 模块底层才能更好的发展。而且希望这个模块可以用于未来引入 3d engine 的元素,而又不会增加太多的复杂度包袱。

为了做这件事情,我在最近两个月阅读了 Unreal4 的渲染层代码、horde3d 、还有之前读过的 pixellight

为什么要阅读其他成熟引擎的代码,再自己实现;而不是直接使用这些引擎?在我看来原因是这样几点:

  1. 最重要的一点,编写代码解构问题并解决的过程非常有趣。

  2. 大多数引擎历史悠久,带有或多或少的历史包袱:从计算机图形的发展历史看,有许多东西是曾经被提出来后来又被否定掉的。历史越久的引擎就越多的支持了这些可能不再被使用的可能性。支持多种不同的底层 API 在移动设备上也是没有必要的(虽然提取出不同 API 的共性这件事情本身很有价值,可以提炼出相对正确的模型)。

  3. 移动设备的显卡特性相对统一。许多 PC/Console 高端显卡上才支持的特性,在三年内都不太可能在移动设备上广泛使用。为这些东西增加的结构复杂性非常不值。同时一些为了低端设备考虑的东西,又不太需要兼容,去掉它们年可以简化引擎底层。

  4. 只是实现渲染的基础部分,而不考虑工具的话。无论 2d engine 还是 3d engine 都没有太多的工作要做,并不是一件高成本的事情(控制在一个人半个月到一个月左右的工作量)。关键是正确的去做。

  5. 受够了正在使用的 Unity3D 的闭源策略(尤其是资源管理部分),如果未来有新的项目需要一些 3d 元素,可以多一个选择。


上面提到的几个 3d engine ,从阅读角度讲,我最喜欢 horde3d 。它的渲染底层最简单,只需要读 RendererBase 这一个模块就能理解。

它只封装了 opengl 的可编程管线(但其实扩展到 DirectX10/11 也很简单),没有做那些华而不实的抽象层。在 RendererBase 之上,又根据 3d engine 的需要设计了 Renderer 一层。

所谓封装,就是根据业务的需要裁减你不需要的可能性,简化和合并 API 。(根据你可以预计的使用场合)规划资源的管理,并加入合理的限制(限制可以防止错误的使用,并简化实现)。

在 RendererBase 的层次上,主要是封装显卡驱动级的各种渲染状态切换,创建 shader ,把 attribute layout 抽象出来,和 vertex buffer 一起加以管理。uniform 的管理可以裸露出来,到上一层 Renderer 再说。texture 和 render target 也是在这一层次做封装的。horde3d 很好的把这些东西用自己的 id 管理起来,屏蔽了 opengl 层的 id 。

对于 render target ,在移动设备上其实暂时还不需要对 MRT (multiple render target) 做太多支持。因为短期内还看不到在移动设备上使用 Deferred Shading 的实用性。


周末动手按 horde3d 的思路重新封装了 shader 模块,大约写了不到 2000 行代码。包括了 C 模块和 lua 封装。C 接口定义了不到 30 个 API ,比 hord3d 的 RendererBase 要简单一些(它有 70+ 个 public api ,而 UE4 的 RHI 有 150+ 个);而 Lua 封装可以方便直接在 lua 里使用它做测试。

由于尚未完工,暂时放在了 github 的私有仓库里。

Comments

u3d不开源,只能写脚本,对习惯了开源的人来说,很不爽~界面就对程序员不太友好~

个人觉得源码层面目前可能不是非常有价值的东西(如果还是c/c++层面), 对于客户端引擎,如何设计工具是件重要的事,unity的价值在于此

个人觉得源码层面目前可能不是非常有价值的东西(如果还是c/c++层面), 对于客户端引擎,如何设计工具是件重要的事,unity的价值在于此

个人觉得源码层面目前可能不是非常有价值的东西(如果还是c/c++层面), 对于客户端引擎,如何设计工具是件重要的事,unity的价值在于此

个人觉得源码层面目前可能不是非常有价值的东西(如果还是c/c++层面), 对于客户端引擎,如何设计工具是件重要的事,unity的价值在于此

你觉得unreal4这种设计理念是发展方向吗?虽然功能强大但是会不会过于复杂?比起unity这种轻巧灵活型的引擎哪种代表着今后的引擎发展方向。

我认为不强调关卡设计和复杂的光影效果, unreal 没有太多帮助。

只是把几个模型用 3d 渲染出来。还是挑一个尽量简单的 3d engine 用比较好。还可以针对性做优化。

我也想看Unreal4的源码来着,但没有时间。能不能请你给点提示?比如重点在哪里、用什么样的顺序浏览,等等。我的设计方向还是大规模单位混战,同屏100个,我希望至少小兵、英雄、炮台是用3d来做。对于我这样的需求,Unreal4的源码有什么帮助么?谢谢。

Post a comment

非这个主题相关的留言请到:留言本