在讲实现多光源之前，先了解两种不同的渲染方式：前向渲染和延迟渲染。 前向渲染 前向渲染是现在最基础，也是最多引擎使用的标准。前向渲染的流程是给定一个几何体，引擎对其进行从顶点到像素着色器的一系列计算，然后输出到最终的图像缓冲区。场景中有多个几何体时，引擎就是对其挨个进行渲染，完成一个再继续下一个。 前向渲染的问题 前向渲染有一个问题就是无效渲染太多，比如场景中有四个物体，互相之间存在叠压关系，按

地形压平遇到新需求：地形与倾斜精度不一致，导致部分地形会压盖倾斜。虽然关闭地形深度测试能够解决，但是又会引发新的问题，所以决定对范围内的地形做压平处理。 地形压平与倾斜压平类似，目的是将指定范围内的地形顶点修改成设定的高程。 实现原理地形压平原理和倾斜压平其实是一样的，甚至实现起来要更简单(在计算上更简单)。 两者无非都是，将压平高度和压平范围传入对应的顶点着色器。然后在着色器内对每个顶点判断一次

Portainer Portainer 是一个开源、轻量级的 Docker 管理用户界面，基于 Docker API，提供状态显示面板、应用模板快速部署、容器镜像网络数据卷的基本操作（包括上传下载镜像，创建容器等操作）、事件日志显示、容器控制台操作、Swarm 集群和服务等集中管理和操作、登录用户管理和控制等功能。功能十分全面，基本能满足中小型单位对容器管理的全部需求。 安装 Docker Do

淘汰树莓派一直以来，我的个人服务器都是使用两年前购买的树莓派 4B 来搭建的，上面主要托管一些网站和一些简单的服务。 但是后来想搭建的东西越来越多，当时购买的 2GB 版本内存已经远远不够使用了。加上树莓派只能使用 TF 卡启动，使得系统运行和数据传输的速度都很慢。 所以打算把服务器升级一下。 CoolPi升级思路很简单，需要大内存，需要 emmc 或者 nvme ，性能要更强。 网上找了一圈，

起因接到个需求：解决低配置电脑中，浏览 3DTiles 容易爆显存，导致 WebGL 崩溃的问题。 简单翻看了一下 Cesium3DTiles 的显存管理机制，编写了一个管理工具。 合理的使用该管理工具，可以有效减少由于 3DTiles 占用的显存过大而导致爆显存的问题。 Cesium3DTiles 的显存管理Cesium 中单个 Cesium3DTiles 有自己的显存控制参数 maximumM

三角网获取Cesium渲染地形时，以 QuadtreePrimitive 管理地形四叉树，四叉树的每一块瓦片用 QuadtreeTile 来实现。因此 QuadtreeTile 中存储了渲染地形所需的顶点信息和索引信息。 获取需要的地形瓦片通常进行土方量计算会给定一小块范围，并且只针对这一小块范围进行计算。因此，事实上我们并不需要知道所有地形瓦片的三角面信息，只需要获取范围内的就可以了。 地形的三

体渲染传统意义上我们构建模型都是通过构建物体的外表面去实现的，例如通过三角面构建模型，或者通过方程的形式构建隐式的表面模型。 而体渲染则是通过 3d 数据集渲染物体的一种方式，典型的 3D 数据集是医学领域上的 CT，CT 是一组 2d 的切片图像（例如，每毫米深度进行一次切片），因此 3D 数据集也可以理解成一组存放 2d 贴图的数组。 通过 3D 数据集可以渲染出具有内部信息的模型。 3D

热力图 在Cesium中实现热力图网上有较为成熟的案例，可参考 CesiumHeatmap 。 其原理是根据经纬度范围计算 canvas 大小，并将经纬度转化为 canvas 上的坐标。 再利用 heatmap.js 生成热力图，最后将 canvas 贴在地球上即可。 立体热力图 立体热力图事实上是对上面热力图功能的改造。 只不过 CesiumHeatmap 是将 heatmap.js 生成的热力

实现原理 下雪覆盖效果的实现原理其实很简单，计算方法如下： 获取当前像素在世界坐标系下的法线方向 normalWC。 获取当前像素的上方向 upWC（在 Cesium 中，计算当前像素点的上方向，可以通过简单的将当前位置单位化得到）。 判断 normalWC 和 upWC 两个向量的接近程度。 如果 normalWC 越接近 upWC ，则雪覆盖的越多，反之越少。 具体实现 在Cesium中实

水面反射的核心是计算反射相机，并利用反射相机渲染水面纹理。 反射相机计算 反射相机是一个与当前相机相对于水面，呈镜面对称的相机。 定义一个相机需要定义至少三个量：位置，视线方向和上方向。 反射相机的计算有很多方式，这里简单举例两种： 利用点到平面距离计算 计算当前相机位置到水面的最短距离 L ，沿着水面法线方向的反方向，将相机位置平移 2L，即可得到反射相机的位置。 视线方向和上方向可以同理可得。