云风的 BLOG

事情总要做两遍以上，才能做对。目前 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 的私有仓库里。