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

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

随着Gitee宣布，发布开源仓库需要经过审核，否则变成私有仓库的消息。 加上国内访问GitHub很慢，所以萌生了搭建自己的代码仓库的想法。 Git服务器选型 说到自己搭建git服务器，常用的解决方案有下面这些： GitLab CE GitLab 是最常用的搭建git服务器的仓库管理系统，能够满足开发人员所有的幻想。 但是 GitLab 运行起来十分耗性能，对于树莓派来说，太吃力了。 所以pass

光线追踪(Ray tracing)，是有别于光栅化渲染的另一种渲染方式。 在光栅化渲染中，计算着色点的颜色通常只会考虑着色点本身，因此想要在光栅化渲染中做出一些全局效果（比如全局光照）是非常麻烦的。 同时光栅化渲染会用到很多近似的方法，因此得到的渲染结果也是一个近似的结果。 而光线追踪是一种全局的渲染方式，能够得到一个准确的渲染结果，但代价是这种渲染方式十分耗时。 光线追踪的原理 光线追踪顾名思义

文章转载于：zkqiang’s blog 起源 WebAssembly 起源于 Mozilla 员工的一个业余项目。2010年，在 Mozilla 从事 Android Firefox 开发的 Alon Zakai，为了把他以前开发的游戏引擎移植到浏览器上运行，利用业余时间开发了一款名叫 Emscripten 的编译器，可以把 C++ 代码通过 LLVM IR 编译成 JavaScript 代码

该地形抬升效果主要是仿照超图的“地形开挖抽出显示”功能实现的。 并且最终效果要优于超图。 效果对比。 常规效果对比 细节对比 远看其实效果类似，但是拉近看后会就发现一些不同。 在边缘处，超图的地形会超出绘制的范围一定距离，并且地质面和地形并没有很好的贴合。 开启网格对比 还有一处不同是在debug的时候发现的，虽然不影响使用效果，但是对于功能调试还是影响蛮大的。 在开启地形网格显示后，可以发现

在光栅化渲染中，我们考虑的着色通常是一种局部计算的结果。 也就是对于着色点的颜色，只考虑光源、相机以及着色点自己。 对于其他的物体则完全不考虑，甚至当前物体的其他部分对着色点的影响也不考虑。 因此，显而易见，这样的着色结果是不对的。 因为如果有其他物体挡在光源和着色点之间，那么这个着色点就应该是黑的或者说暗的。 这就是为什么会存在阴影。 ShadowMapping 是光栅化渲染中最常用的一种生成阴

离屏渲染(Off-Screen Rendering)顾名思义，指的是定义另外一个相机，并让GPU在当前屏幕缓冲区之外再开辟一个新的缓冲区，通过自定义的另一个相机进行渲染操作。 这一块新的frame buffer可以用来作为画面输出，也可以用于参与计算。 作为画面输出 将离屏渲染得到的frame buffer直接做为图像，输出到Canvas上的效果可以参考这篇文章。 作为画面输出 同时拾取多个对象

对于任何一个三维物体，我们都可以把他的表面展开到一张二维平面的图像中。 并且模型上的每一个点都与这张二维平面图像上的点存在一一对应的关系。 这就是纹理映射的意义。 UV坐标 要确定模型上的点与二维平面上的点之间关系，就需要为展开的二维平面定义一个坐标系。 这个坐标系通常用UV来表示，并且无论这张图像有多大，它的UV坐标范围总是是从0到1的。 在定义模型时，对于三角形的每一个顶点，都对应一个UV

由于之前开发的视频融合功能允许进行画面裁剪。 而如果在场景中直接裁剪的话需要将裁剪点投影到地球表面上。 这就造成如果融合面是与地球表面垂直的，就无法进行裁剪。 一个比较通用的方式是利用UV坐标进行画面裁剪。 为了方便获取相应的UV坐标范围，所以编写了一个视频裁剪窗口。 通过在裁剪窗口上绘制/编辑多边形来计算相应的uv坐标。 记录一下关键代码和效果。 首先看看视频融合中的效果 绘制测试 关键