WebGL渲染引擎技术选型总结

经过一年断断续续的踩坑，我的webgl渲染器已经到了攻坚阶段（很惭愧，离成熟还有不少距离）目前的主要工作集中在延迟渲染，阴影走样和PBS材质的构建阶段，先放几张截图

网站在这里：canvas-toy

一个demo样式的WebGL渲染器当然是没什么意义的，我的工作当然不是只是做出上述这些简单的小渲染场景，而是要做一个封装良好同时保持先进性的渲染库。

在语言层面，WebGL算是赶上了一个JavaScript技术急剧变化的潮流，这也就导致了我画了非常多时间在语言本身之上，包括不断更新项目结构以适应新的ES规范，从纯粹的JS转到TS等等。虽然我不是Web前端程序员，然而我花了很多精力保持和前端业界同样的规范。通过写这个渲染器，我深深觉得，WebGL真是有天然的技术壁垒在里面。WebGL基本等于OpenGL ES 2.0~3.0。不熟悉以及不了解图形学原理的人根本无法直接操作这些原生API，也不懂这些事什么意思。我想这也是这些渲染库存在的理由

追赶潮流的代价是巨大的，却也是令人兴奋的。对于这个库，我最最明智的决定就是选用了TypeScript。这也是对WebGL的大程序最友好的选型决定了。TypeScript的最大助力在于类型检查和代码补全，这对于有非常多类型的WebGL接口函数来说太重要了，打个比方：

1
2
3
4


//  some code of CanvasToy
let gl: WebGLRenderingContext;
gl.bindBuffer(gl.ELEMENT_ARRAY_BUFFER, geometry.faces.buffer);
gl.bufferData(gl.ARRAY_BUFFER, new Float32Array(attribute.data), gl.STATIC_DRAW);

短短两行，挂载在对象gl上的函数和数值就已经这么多了，参数同样也是非常麻烦，如果没有类型检查，得一边写代码一边开着WebGL的Specification看着，生产力十分低下，许多编译期能发现的错误全部转移到运行期了

当然，TS对于自定义类型的类型支持和标注也很有用，绝对是提高生产力的好工具。

然而麻烦的事情在node和ES6

众所周知，TypsScript由微软出品，质量没的说。但是，node社区和ES6的发展却稍稍落后于这个时代。JavaScript刚刚发展起来的模块系统几经修改，从commonjs到amd再到standard ES6，对开发者造成了许多困惑。我真正理解amd是在没有办法亲自写了一个amd的demo之后，在此之前，我几乎停留在 “amd” == “一种模块机制” 的认识水平上。 amd的define，require这些函数的应用场景，更多是在多页面应用上，对于一个Web App，amd提供的按需求模块化加载的确很有用，能有效地组织源码的同时提供异步加载。但是。对于一个单页面的App，amd看起来比较不优雅，其一在于代码可读性不高，其二在于需要一个module loader（这也是我一直对使用amd有些抗拒的原因）

除了规范稍稍有些麻烦以外，JavaScript的工具链也是非常的麻烦。首先，我们从TS开始，就有一个有各种参数的tsconfig.json配置文件，这个文件制定了TS的编译参数。TS最终的target language是js，那么ts就必然有关于amd，commonjs， systemjs，umd，es6的各种模块生成配置方法。

对于一个开源库来说，我们希望最终的库文件是一个单文件，也就是我们需要把所有模块打包到一个文件里。最初，TypeScript提供了internal modules，也就是namescapce，namescpace支持跨文件整合和依赖，他的依赖指定方式是在文件的首部增加一个指向性的注释

Foo.ts

1
2
3
4
5
6


namespace bar {
    export class Foo {
        ...
    }
}

Fooo.ts

1
2
3
4
5
6
7
8


/// <reference path="Foo"/>

namespace bar {
    export class Fooo extends Foo {
        ...
    }
}

这样，TypeScript就能直接编译到一个文件，然而不幸的是，这样的模块声明方式是不被推荐的，因为现在的潮流是使用标准的ES6模块（在TypeScript中被称作externel modules）。许多库都渐渐变成了这种方式

如果仅仅是这样，那可能并没有什么问题。但是，如果你的项目中不幸依赖了一个external module，或者这个项目本来是internal module，但由于某些开发者基于“这样更优雅的想法”，把库更新成external module，那问题就大了。。。为了使用这个external module，你必须使用import语法来导入，比如

1
2
3
4
5
6
7
8


/// <reference path="Foo"/>
import * as SomeLib from "SomeLibrary"

namespace bar {
    export class Fooo extends Foo {
        ...
    }
}

这时候编译器是会报错的，因为一旦有import，整个文件就被视为一个模块，namespace bar 是在该文件内是独立的，和Foo.ts中的bar是两个模块

这样带来的问题是灾难性的，想使用一个external module，就必须import，import之后，又把整个internal模块切割了，最后的解决办法是传染性的把所有的文件都换成import形式，namescpace被放弃使用。

问题还没完。没有使用external module时，所有的模块能很好地编译到一个没有define，没有require的全局对象上去，所有的类和函数都在这个全局对象上

这样其实是一个很好的中小型项目的解决办法，既没有污染全局命名空间，又做了良好的封装。但是JavaScript的专家说了，我们要做最先进的模块系统，于是这样的方式立马被否定了，随着各大库开始对跑在浏览器上的库使用amd，define/require反到变成优雅的方式了

于是理所当然的，在更换到external module的时候，TS编译的结果是多个amd module，这些module在一个或者多个文件里，需要一个requirejs或者browserify或者webpack来做进一步的加工或处理

我觉得这正是javascript令人生厌的地方，总是要经过非常麻烦的多道工序才能完成一件事情，同样的事情在C++，Java都属于根本不需要操心的事情。

我没有选择requirejs或者browserify或者webpack中的一个（但是我确实折腾webpack折腾了很久，一直不能和typescript完美配合），因为毕竟我只需要把库的功能导出来，提供amd接口就够了，因为使用者应该具备"使用amd library的基础知识"

除了我上述说的这些坑以外，我还在nodejs里面踩过karma，karma with requirejs，jasmine，以及组合使用ts，karma，jasmine，requirejs的巨坑。我时不时有一种后悔选了WebGL做引擎开发试水的感觉，因为我在这些别的语言早已不是问题的问题上画的时间实在是太多了

文章目录