纹理单元与绑定目标的关系

运行应用。

说明了纹理单元、绑定目标与纹理对象有以下的对应关系：

具体规则如下：

1. 纹理单元共有32个，序号从TEXTURE0到TEXTURE31。
2. 每个纹理单元都各有TEXTURE_2D、TEXTURE_2D_ARRAY、TEXTURE_3D及TEXTURE_CUBE_MAP等4个绑定目标，用于绑定当前纹理单元下不同的目标。并且，这些绑定目标，在每个纹理单元下，其数量只能有1个。

   这类似于数据库中，TEXTURE0及TEXTURE_2D组成了一个复合键，TEXTURE0及TEXTURE_2D_ARRAY组成了一个复合键。同理，TEXTURE1及TEXTURE_2D组成了一个复合键，TEXTURE1及TEXTURE_2D_ARRAY组成了一个复合键。

3. 每个纹理单元下可以有多个纹理对象，但该纹理单元下各个绑定目标，在某一时刻，均只能分别绑定至一个纹理对象。

多纹理单元应用的内部流程

如果在片断着色器中，同时出现了2个以上的采样器，这是应用程序同时使用多纹理单元的表征：

上面，在渲染每个顶点时，均需要同时使用2个采样器来获取不同颜色值，并将这2种颜色值相乘后，才得到最后的顶点颜色值。

客户端代码：

在TextureMesh的代码中，将texUnits作为属性名保存进texVAO中：

WebGLUtils的renderVAO方法中：

激活TEXTURE0及TEXTURE12个纹理单元，将uSampler0指向TEXTURE0，将uSampler1指向TEXTURE1。并且将当前绑定至TEXTURE_2D的对象的纹理，分别绑定至两个不同的纹理对象。此时WebGL内部状态如下：

而后，当发起渲染命令：

注意，上面代码先激活多个纹理单元并将当前激活纹理下的TEXTURE_2D绑定至不同的纹理对象，而drawElements方法只须调用一次，这意味着，bindVertexArray方法能记住上述WebGL的内部状态。

片断着色器中的代码：

将导致分别从texObj0.texture及texObj1.texture这两个纹理对象中进行颜色值采样。

可见，仅当片断着色器中同时出现了2个以上的采样器时才需要使用多纹理单元；否则，使用默认的TEXTURE0纹理单元即可。

一个纹理单元绑定多个纹理对象的内部状态

我们之前的应用程序，绝大部分都是只使用一个纹理单元，但将TEXTURE_2D先后绑定至多个不同的纹理对象。

片断着色器代码：

客户端代码：

WebGLUtils的renderVAO方法中：

先渲染texMesh1时，WebGL内部状态如下所示：

而在渲染texMesh2时，WebGL内部状态如下所示：

运行应用。

本节小结

是否需要使用多纹理单元，由片断着色器中是否同时出现多个采样器来决定。

activeTexture方法，只在渲染时才需要调用，初始化各个纹理对象时无需调用。

WebGLUtils的renderVAO方法根据其参数vao是否存在texUnits属性来判断是否使用多纹理单元。因此，在客户端中，最简便的方法是使用一个名为texUnits的数组对象来封装不同纹理单元的各种参数，然后将该对象保存为vao的texUnits属性值即可。

方案一

方案二

方案三

本节小结

FaceMesh在使用起来非常方便，但需考虑的问题较多，如需重新生成顶点数组、自动为每个面生成随机颜色、尽量减少内存的占用以提高应用效能等问题。因此，不能让其仅是简单地聚合多个SolidMesh实例。

与上一章中的实现相比，为最大化地提高效能，本章的FaceMesh摒弃了聚合多个网格物体的理念，进行了全新的改写。

而FaceTextureMesh更需额外考虑如何在只使用一个纹理单元的情况下，为各个面指定不同的纹理图像来源。同样，从应用效能考虑，也不能让其简单地聚合多个TextureMesh实例。相反，我们基本上是从最底层重新编写了其代码。

当依此而设计出FaceTextureMesh类后，客户端代码将非常直观，且易于扩展。例如，后面我们将在其基础上扩展为让一个立方体的6个面拥有不同的纹理贴图，并让相邻的多个面共同使用同一纹理贴图。甚至，为一个圆球的众多面贴上不同的纹理贴图。

可以说，为最大化地优化FaceMesh及FaceTextureMesh的性能，与它们所能带来的便利性、可扩展性相比，无论花多少时间都在所不惜。

简单粗暴的实现

整体代码：

运行应用。

尽管应用效果看起来很不错，但最主要的问题在于，一个立方体网格物体，聚合了6个TextureMesh或SolidMesh，占用了大量的服务器内存空间。

精细的实现

运行应用。先看效果。6个面均有贴图。但每个面均有各不相同的纹理设置。

下面是客户端代码：

与前面不同的是，在faceTexOpts变量中，每个面均有一个faceID属性，用于明确指定为哪个面设置纹理。这是因为立方体的几何图像信息是由Geometries所自动生成，而非我们自己手工逐一指定各个面的索引值。

顶面使用类型化数组作为纹理图像内容，未显式设置纹理参数。则默认使用NEAREST进行采样，确保像素界限清晰。

前面也是使用类型化数组作为纹理图像内容，但设置了纹理参数及纹理坐标，则均覆盖了默认设置，以允许对类型化数组的纹理图像进行线性采样。

后面使用Canvas 2D作为纹理图像内容，同时通过设置纹理坐标，形成行列各重复3次的效果。

剩下的左面、右面、底面均使用图像文件作为纹理图像内容，未设置其他参数。对于这种类型的纹理图像，均统一使用线性采样，以确保清晰的图像效果。

左面及底面先后使用了同一个图像文件，应用程序一是对图像内容进行了缓存，确保不同的图像文件只加载一次，以提高程序效能。二是缓存内容为Promise，这样可确保先后引用同一缓存对象的代码，均只在图像文件加载完毕后才统一运行后续代码。

当faceMesh初始化完毕后，其状态如下：

fileTexturesCache确保只为不同的纹理文件名生成唯一的纹理对象，并且所生成的纹理对象集中存储在faces.textures中。

ibo属性存储了渲染每个面时所需的数据信息，其中各个面的textureID是上面faces.textures数组中相应的索引值。这种数据结构，有效建立起了纹理对象的缓存机制。

FaceTextureMesh类代码如下：

initTexVAO的代码较长，主要是在遍历各个面时做了以下3件事：

一是若不为特定的面进行纹理设置，则默认使用一个2 × 2的代表国际象棋棋盘的类型化数组作为纹理图像内容。屏蔽掉特定面的设置值，将可看到此点。

二是为各个面配置如下的初始状态：

其中textureID是初始化类型化数组的纹理对象。

三是各个面的配置选项中如果存在texImg, canvas或texFile属性值，则为相应的面创建相应的纹理对象，并将所返回的纹理对象的id值更新至上面的状态。

对于texImg，genTypedArrayTexture方法根据客户端传进的纹理参数进行设置。

对于canvas及texFile，因为它们都是图像文件，因此genImgFileTexture方法直接以线性的纹理参数进行设置。

texImg及canvas均属于在内存中直接创建纹理图像，不存在延迟加载图像的问题，流程完全落于主线程内，因此无需刷新视图。

texFile需加载图像，getTexIDPromise方法通过缓存机制，返回一个经解析后可得到textureID的Promise实例。

经此3步骤，已为渲染做好了状态准备。

还有最后一个问题，对于配置了texFile的各个面，何时须刷新视图的问题。每处理完一个面即重新刷新视图，将严重降低应用性能。而如果不刷新视图，在应用运行后，只有当用户进行鼠标或键盘操作时才会将客户端所配置的纹理图像刷新显示出来，有点智障。

我们可以充分利用Promise的特性，仅在所有的Promise实例都得到解析后，才一次性地刷新视图：

可见，getTexIDPromise一并解决了缓存、迟延加载、一次性刷新等3大问题。

本实现具有以下特性：

1. 为每个未配置的面指定默认类型化数组的纹理图像
2. 可以设置自定义类型化数组的纹理图像
3. 支持Canvas 2D, SVG及HTMLImageElement纹理图像来源
4. 支持纹理图像缓存，每张图像将只会加载并向服务器上传一次
5. 非类型化数组的纹理图像加载完毕后，自动替换之前的类型化数组的纹理图像

如此，不仅客户端代码灵活，也完美地对付了网格物体面数可能过多的问题。例如下面将要看到的球体。尽管球体的面数多，但如果整体只需一张纹理图像（例如，地球贴图），则初始化速度大为提升。

本节的代码，基本上涵盖了之前各章节的相关内容。FaceTextureMesh已集成进应用框架的Mesh.js中。

createCanvas函数代码如下：

球体结构及单面贴图

客户端代码：

运行应用。左上视口为线框模式，左下视口为实例与线框模式，右边为纹理模式。

在垂直方向上，每条经线共分4段，因此共有5条纬线（两个极点的纬线坍塌为一个点）；在水平方向上，每条纬线被划分为4段，也即整个圆球有4条经线。因此，每两层纬线间均有4个面。

取第5、6、9、10这4个面，为它们均手工指定了一个相同的纹理图像贴图。由于未显式指定纹理坐标，每个面均使用默认的纹理坐标，因此，每个面均完整地贴上整张纹理图像贴图。

FaceTextureMesh在初始化完毕后的状态如下：

所有纹理先统一置于faces的textures属性下，以供ibo.faces.textureID属性值引用。

将纹理图像贴至4个相邻的面

客户端代码：

运行应用。

通过为4个相邻的面分别指定手工分割后的纹理坐标值，则一张完整的纹理图像被贴至4个相邻的面上。

通过计算取面并自动生成纹理配置对象

球体的面数较多，直接通过faceID来指定面不是易事。

运行应用。纹理图像平铺了第1条纬线下面的所有的面。

第一步，自动取出相应的一组面：

从第1条纬线开始，选出该纬线下面的4个相邻的面。

getSphereFacesIDsAtLat函数中的形参faceNums如果等于球体经线的数量，如例子所示，则取出该纬线下所有的面。

第二步，为所选出的各个面配置纹理参数，并用以创建FaceTextureMesh的实例。

genFaceTexOpts函数将一个完全的纹理坐标系拆分至所指定的各个面中，且构建返回faceTexOpts。

形参facesIDs可为多行的面，因此形参facesPerRow指定每行中的面数。函数内部据此计算出具体的行数。

调用完该函数后，faceTexOpts的状态如下：

若将代码：

改为：

则纹理图像平铺至中间两层所有的面。运行应用。

虽然仍存在图像粗糙及纹理图像尚未完全覆盖球体所有的面，但已经可以看出，球体贴图的本质，就是将球体的各个面的纹理坐标值，在一个默认纹理坐标系范围内，依序拆分为更小的纹理坐标值的问题。

因此，我们可以制作出一个地球贴图的应用了。将客户端代码修改如下：

将经线与纬线数量增加至32，以增加球体圆滑度；为球体所有的面生成对应的局部纹理坐标值；将纹理图像指定为一张较高分辨率的地球贴图。

运行应用。

对于经线与纬线数量均为32的球体，其面数激增到1024个。

应用运行中，按W键查看线框情况，按D键查看面的情况，就可清晰地看到渲染量有多大。按X键返回纹理渲染模式。

因此遍历各个面所花的时间成为应用的主要瓶颈。故而只应在最后的一面设置了正确的纹理图像id后，才刷新视图。上面谈到，FaceTextureMesh早就为此做好了充分的准备：

每当生成一个必要的新纹理对象，将textureIDPromise添加进数组textureIDPromises中。且当其解析完毕后，仅执行一条属性值的更新语句。而在所有的textureIDPromise都解析完毕后，才刷新一次视图。

如此编写代码，因面数过多所带来的额外负面影响微乎其微，应用效能大幅提升，没有任何延滞的感觉。且初始化完毕后，无论是旋转、放大、平移视图，均没有任何卡顿。

将经纬线数量均改为64，虽面数冲至4096也无任何问题。

球体贴图的极点褶皱问题

上节中的地球贴图确实很完美，但我们被蒙蔽了一些细节。不是所有的图像文件都适合于充当球体贴图。如果将贴图文件换成其它的文件，不管贴图内容是什么，将会看到南北两极存在明显的极点褶皱。

上节使用的贴图文件内容如下：

设想一下，现在，用这张平面图去包裹住一个篮球。地图的顶部（北极）和底部（南极），在物理上原本是两条线，但到了球体上，它们必须各自被压缩成一个点。这样，顶边和底边的所有像素，都被强行挤到了极点这一个点上，自然会产生严重的挤压和褶皱。

上面自动计算纹理坐标的算法是北级与南极这两行线上的点都分别集中向地图的左上角与左下角收敛。

但为何实际渲染效果看不出有极点褶皱？

这是因为地球贴图的顶部与底部正好有一大片纯白的像素。当这两行所有像素都向各自目标收敛时，这部分区域内的每个像素的上下左右相邻的其他像素均与它长得完全一样。要在白色极圈内找出一个白色的点，谈何容易？因此白色褶皱消失在冰天雪地里了。

因此要消除褶皱的方法之一，就是使用类似于这里的球形全景图，或称等距圆柱投影图。这种图像在上下边缘将被无限压缩成点，因此其图像内容有着特殊的要求：上下边缘必须是纯色或极简纹理。不能有可被容易识别的具体图案。例如，如果图像的顶部或底部边缘正好是一张人脸或是一栋建筑物，则效果惨不忍睹。

消除褶皱的方法之二，是使用立方体贴图，即将球体展开为十字形或长条形的6张方形图，对应于立方体的6个面。因为每个面都是平面，所以贴到球体上时，极点（现在出现在立方体的某个角点）就不会有挤压问题。它没有特殊的图像内容要求，但需要专门的渲染流程支持。

还有另外一种较为少用的方法，就是先将图像上位于极点位置的像素沿径向按比例向外反向拉伸。这样当这些像素收敛时，正好还原了原来的图像内容。但唯有比较无聊的人才会去做这种事情。