平视显示器（head up display）简称HUD。游戏经常在三维场景上叠加文本或二维图形信息，如弹窗，血量条等，同时需要保证它们在屏幕上的位置和大小不变。 传统的H5游戏可以使用dom，或是在原本的webgl上面盖一个新的2D canvas（画布）做为HUD来实现，同时使用其接口就可以画出HUD所需要的内容。 但微信小游戏只支持一个画布，无法和传统H5游戏的绘制方式一样。因此，要在3D世界中实现HUD就必须在这个唯一的画布上实现。 我们在后台收到了许多反馈：如何用小游戏的框架来实现HUD的绘制。这一期的小故事，我们跟大家分享如何在微信3D小游戏中绘制HUD: 本文的内容包括： 1.微信小游戏只支持一个画布 2.如何使用三维平面模拟HUD？ 3.相机变化导致HUD产生位移缩放 4.如何用图形渲染管线解决上述问题？ 5.绘制场景时视点变化与投影阶段的问题 6.如何使用顶点着色器解决上述问题？ 微信小游戏只支持一个画布 与浏览器不同，微信客户端只有一个画布，并且不能使用html。 普通H5游戏会使用html，或是创建一个新的2D canvas标签，定位在原本的webgl canvas上面，同时使用2D canvas的接口就可以画出HUD的内容。但微信小游戏不支持这样做。所以在三维世界中要实现HUD，需要在一个画布上实现。 所以在三维世界中要实现HUD，则必须在这个唯一的画布上实现。 如何使用三维平面模拟HUD？ 对于图像，webgl可以通过纹理贴图来展示图像。开发者可将图片作为的纹理贴图，贴在一个三维矩形平面上，使平面一直正对相机，来模拟HUD。 [图片] 对于文字，微信小游戏三维的canvas是使用webgl作为context的。但是webgl却无法像2D的context能直接画文字。开发者如果直接用webgl画出文字，需要导入文字模型的顶点数据，但由于文字比较复杂，顶点数量多，相当于渲染了一个复杂的3D物体，这种方式无论是从文件大小还是性能上，都会有损体验。 [图片] 那么是否可以使用2D canvas 绘好文字，再作为纹理贴在三维平面上呢？ 虽然微信小游戏只能渲染一个canvas，但是开发者可以创建多个的canvas实例。 Step1：开发者可创建一个离屏的2D canvas，再使用2D的接口绘制文字、图片等； Step2：开发者可将这个离屏canvas传给webgl，当成一个texture，贴到一个三维的平面物体上，使其永远都在相机的正前方，通过这样模拟HUD 。 补充 webgl支持直接将canvas作为纹理； void gl.texImage2D(target, level, internalformat, format, type, HTMLCanvasElement? pixels)。 [图片] 相机变化导致HUD产生位移缩放 游戏场景中的相机是会改变的，比如说吃鸡游戏中的第一人称和第三人称视角转化。我们发现了一个问题：当相机的可视范围变化的时候，HUD就会发生形变。 [图片] 那是因为视野看的越广，映射到屏幕上的时候，同一个物体就显得越小。 我们需要保证HUD在任何视角下位置大小都是正确无误的。那么如何才能做到呢？ 要解决这个问题就需要明白计算机是如何把三维场景画到二维的屏幕上的。这个画的过程也就是计算机图形渲染管线帮我们完成的。 如何用图形渲染管线解决上述问题? 画一个三维物体到二维平面可以分为三个阶段： ●“准备数据” （应用程序阶段） ●“画点” （几何阶段） ●“画像素” （光栅化阶段） [图片] 一个HUD实际上是一个矩形的平面物体，通过矩形的4个顶点就可以描述出来一个平面的位置、大小。为了让平面的位置，大小看起来没问题，我们需要修改“画点”阶段的逻辑。这个阶段又可以进行如下的细分。 [图片] 与摄影机相关的逻辑，是视点变换还有投影阶段。我们可以通过修改这两者的逻辑来达到我们的目的。 绘制场景时视点变化与投影阶段的问题 1.视点变化阶段的问题 我们需要绘制摄像机看到的世界，而摄像机可以处在任意位置观察这个世界。视点变化本质是就是根据摄像机看的方向来旋转物体，从而让三维空间的物体正确旋转到观察者看到的样子。原本是摆正放的物体，由于观察者的视角问题（歪着看），所以显示出来物体最终也是歪的。 [图片] 通过在应用程序阶段定义相机的视点、观察目标点以及上方向等数据，我们可以得到一个叫做视图矩阵（View Matrix）的矩阵。把这个矩阵与物体的位置做矩阵乘法就可以得到物体变化后的新位置。 因为游戏世界中，摄像机的位置是不停变化的，而我们的物体却需要一直出现在摄像机正前方。所以游戏场景中的视觉矩阵（View Matrix）在每一帧的渲染中，可能都在变化。这里我们只要将HUD原本一直在变化的视觉矩阵（View Matrix）替换为我们需要的，并且保持不变就好了。 2.投影阶段的问题 投影其实是把透视摄像机原本的可视范围，压缩成一个单位立方体。 [图片] 再通过屏幕映射，就会出现如下的效果出来。 [图片] 这一个过程中，会通过摄像机定义的数据（比如长宽比，视场，近截面，远截面），来生成一个叫做投影矩阵（Projection Matrix）的矩阵。将这个矩阵与位置信息进行矩阵乘法，再进行一些归一化操作，就会得到单位立方体内的位置。 和视觉矩阵（View Matrix）一样，对于HUD的物体，我们也不能使用透视摄像机生成的矩阵，否则就会可能导致大小变化。我们替换成正视摄像机的矩阵。这样算出来的位置就是永远都是正常的，不需要担心游戏中更新了相机的数据。 如何使用顶点着色器解决上述问题? 现在我们要用顶点着色器来修改视点变换还有投影的逻辑。 顶点着色器与片元着色器都是 webgl 提供给我们用来操作渲染管线的能力。让我们可以使用glsl 这种编程语言来对 GPU 的能力进行编程。 [图片] 顶点着色器运行在“画点”阶段（几何阶段），也就是对每个三维物体的顶点进行计算。片元着色器运行在“画像素”阶段（光栅化阶段），把顶点围起来的像素（其实是片元）画上颜色。 我们可以通过顶点着色器，修改视点变换与投影的逻辑，最后达到我们的效果。 总结 由于微信小游戏支持一个单独的画布，开发者想要在任何游戏场景下绘制正常的HUD，可以通过顶点着色器的能力，去修改视点变换与投影的所用到的矩阵，最终来解决这个问题。 微信小游戏还有很多与H5游戏、客户端游戏不一样的设计理念与特点，我们会在后续的文章里继续分享微信小游戏背后的小故事。

- 需求的场景描述（希望解决的问题） 目前小程序只支持NFC HCE来模拟卡片，并不支持NFC来读取卡片数据，在一些小程序当中，往往需要使用NFC功能来读取卡片数据。以我们的校园小程序为例，我们需要借助NFC功能读取卡片中的二进制数据，然后得到卡片的ID，向我们的服务器发送请求以查询卡内的余额以及相关的个人信息，这样的话用户就不需要专门跑到我们在校园内设置的终端机器上查询，以及一些卡片充值等功能我们都需要事先得到卡片的一些数据才能够完成。 - 希望提供的能力 希望小程序能够尽快的提供NFC读取卡片数据的功能