InverseDa Blog

Git压缩提交

Mon, 17 Jun 2024 00:00:00 GMT

在 Git 中，你可以使用强大的 interactive rebase（交互式 rebase）将多次提交合并成一次。

命令行

选择起始commit

N是从HEAD开始想要合并的提交的数量（从最近的一次提交往前数）

假如：

我们需要达成这样的Git树：

那么需要用到：

交互

在vim上会弹出：

我们只pick最老的commit，其他的commit都squash：

:wq保存关闭

创建新commit

接下来直接创建一个新的commit，然后提交即可。

一个更简单的方法

可以不用squash而是fixup，他直接帮你忽略掉了其他提交信息，只需要push即可（不需要再创建新的提交而是直接push）：

然后保存，直接git push -f即可。

旋转变换

Tue, 30 Jan 2024 00:00:00 GMT

Gimbal lock

Gimbal lock is the loss of one degree of freedom in a multi-dimensional mechanism at certain alignments of the axes. In a three-dimensional three-gimbal mechanism, gimbal lock occurs when the axes of two of the gimbals are driven into a parallel configuration, "locking" the system into rotation in a degenerate two-dimensional space.

https://en.wikipedia.org/wiki/Gimbal_lock

二维旋转矩阵

考虑两个向量和，设旋转矩阵为，就需要满足：

因此可以得出，旋转矩阵是一种正交矩阵，满足：

并且满足：

为什么旋转矩阵的行列式为1？这是因为行列式本质是一种缩放因子，而旋转矩阵是一种变换坐标基的操作，所以也就是相当于旋转了坐标系，因此并没有发生缩放，所以值就是1。

另外，任何旋转矩阵都可以写成反对称矩阵A的指数：

反对称矩阵是一种转置矩阵和自身加法逆元相等的矩阵，简单来讲：

在维空间内，上述结论仍然成立，这里不展开证明了（非常简单）

那具体在二维情况下旋转矩阵的值是多少呢？

二维情况下，旋转矩阵是一种关于旋转角度的函数（矩阵是可以定义为函数的，类似于透视函数）：

证明如下：

假设从旋转到：

从而推出：

写成线性变换的形式：

这就是二维旋转矩阵了，可以验证这个矩阵满足行列式为1.

三维旋转矩阵

三维旋转的复杂度会大大提高，主要是需要确定旋转轴。在二维上的旋转，只有绕z轴旋转（这里暂时不引入OpenGL的标架）的情况。但在三维，会有饶x、y、z轴旋转的情况。其实推导很简单，就是类似于二维旋转。

并且，三维旋转可以细分为旋转矩阵表示、欧拉角表示和四元数表示。

旋转矩阵表示

如果用旋转矩阵表示，需要分三种情况：饶x、y、z轴旋转的情况

欧拉角

如果用欧拉角表示，则需要定义三个欧拉角roll（）、pitch（）和yaw（）：

在三维情况下旋转可以用欧拉角表示。可分为动态欧拉角和静态欧拉角，两者均有万向节死锁问题。

欧拉角的定义基于旋转矩阵，它规定了物体的旋转次序只能有xyz的组合，即：xyz，xzy，yzx，yxz，zxy，zyx。这里举的例子是xyz。

静态欧拉角

静态欧拉角是根据世界坐标系的三个坐标轴xyz为基准进行旋转的，这三个坐标轴是不会变化的，始终是相互正交的，因此可以这样描述静态欧拉角：

计算得出：

一个有趣的数学现象，所有静态欧拉角的旋转矩阵，如果我们把矩阵的列单独拿出来看，可以发现矩阵的三个列分别对应了旋转之后的xyz轴分别在原本的xyz轴上的映射的分量。

万向节死锁

那为什么静态欧拉角会发生万向节死锁呢？坐标轴不是固定的吗？按理来说不应该出现自由度消失的情况。

其实我们一直都理解错了。欧拉角一个重要的概念就是，他每次的旋转变换都是以最初的姿态为初始状态变换的。我们从数学上和本质上去理解为什么会出现万向节死锁。

数学

假设先沿着x轴旋转，然后沿着y旋转90度，最后绕z轴旋转，其欧拉角用旋转矩阵表达为：

这里比较直观的发现，最后的结果不包括了，这说明我旋转的情况和z轴无关，我仅仅通过x和y就能得到这样的结果。

本质

欧拉角一个重要的概念就是，他是一个完整的变换。也就是每次变换，都要经过的乘法操作。什么意思呢？假如初始状态顶点坐标为，三个欧拉角为，我们要旋转到，那么就需要一个个操作，操作次序也就是：

可以发现被变换对象一直都是，说明不是在原有的基础位姿上变换的！

然后旋转到，也是同样的道理：

然后我们会发现每一个操作，都要先重新绕x轴旋转一次。虽然很冗余，但这是欧拉角旋转的定义。并且这也间接的告诉我们接下来的关键问题。

将旋转到，操作次序：

看出来了？其实不是在你原有的欧拉角基础变换后的位置计算旋转，他要重新通过你最初始的姿态计算一遍。这个时候我们发现，假设，我们是在y调整之前，先调整的x旋转。也就是当y的角度还没到90度的时候，先调整的x。这和我们预期不符合，最终姿态看样子像是绕着z轴旋转了（因为经过y轴旋转90度之后的z轴和原来的x轴重合了）。这就是万向节死锁。

操作次序只是为了方便理解，让你知道欧拉角旋转始终是从初始姿态计算的，实际上程序直接计算最后一步。

下面是两个简单的解释：

简单来说，你以为旋转的结果是：X（10）Y（90）X（10）
实际上的游戏引擎计算的结果却是：
X（10）X（10）Y（90）
或者：
X（20）Y（10）
（这里的XYZ不是R_XR_YR_Z，只是表达一下直觉上的感受）

你想要的顺序:X1→Y→Z→X2 实际顺序:X1→X2→Y→Z 欧拉角本身不是问题，用欧拉角这个状态表示方式去表示了过程才导致了问题

动态欧拉角

动态欧拉角是根据自身物体的坐标轴为基准实现的旋转。可以用陀螺仪表示：

陀螺仪的三个环表示三个轴，他们不是始终固定的，根据物体的姿态调整，这就意味着存在两个环可能会重叠（平行）。另外外环会带动内环旋转，这与旋转次序是类似的。

在随着物体转动的坐标系下描述该问题非常方便。正如上面的石雕所示，我们取y,x,z的顺序依次绕轴旋转：

首先是绕y轴旋转任意角度，可以认为是原地转圈

接着绕着x轴旋转 90 度或者 -90 度，变成躺平或者俯瞰的姿势

这时候z轴就和最初的y轴重合了

我们称丢失了一个自由度。这种视角看物体的旋转十分便于我们想象，但是比较难用数学方式表达，因为旋转轴是变化的。

动态欧拉角与静态欧拉角互相转换（代数意义上）

接下来的问题，如何转换动态欧拉角的旋转公式？可以根据静态欧拉角转换出来。

设动态欧拉角绕自身旋转为，假设是按照x→y→z旋转的，那么就有：

即绕自身x转动，等价于绕世界x轴转动；绕y轴转动，得先撤销之前x的转动，然后绕世界y轴变换，再应用之前x的转动；绕z轴转动也是同理，先撤销y然后撤销x，应用绕世界z轴变换，再应用xy。

然后就能得到：

所以，动态欧拉角变换和静态欧拉角变换是相互反过来的！也就是自身旋转xyz，相当于绕世界转zyx。

因为静态欧拉角有万向节死锁，因为等式成立，所以动态欧拉角也有万向节死锁问题。

绕任意轴旋转矩阵（Rodrigues旋转表达 - 罗德里格旋转）

轴的方向向量为，满足（单位向量），绕旋转轴旋转的向量为，旋转后的向量为，逆时针（绕旋转轴）的旋转角度为。由旋转的模长不变性知道。

将分解为和方向（垂直于和平行于），不难得到如下关系：

构建一个新的标架，将该问题转换为在标架的旋转问题。我们假设空间是右手坐标系，那么规定并计算可得到标架：

考虑到：

绕旋转轴逆时针旋转得到的向量，将其分别分解为和（其中在平面，有；在上，有）。

由几何关系，可以得到：

代入，可以得到旋转后向量的垂直分量表达式：

因此旋转后的向量：

整理得到：

这是Rodrigues旋转的向量表示。为了得到Rodrigues旋转的矩阵表示，我们做如下的操作。

令，为了求解矩阵元，我们可以采用特殊值的方法，令，且：

先计算得到：

于是：

同理，令和，能够得到最终的旋转矩阵：

四元数

四元数由两部分组成：一个向量以及一个旋转角度。几何意义是表示以这个向量为轴所旋转的角度度数，如下图所示，一个四元数由向量v和标量s组成，表示以向量v为轴，旋转s角度；另外一套符号系统则是用θ表示旋转角度和u来表示旋转轴。这两个表示都是等价的：

如果我们将向量u/v的xyz三个分量拆开来写，就可以得到四个标量：这就是四元数的名字的由来：

有些地方喜欢将四元数写成：

本质上都是一样的，ijk在这里就是用来表示旋转的轴。

四元数加法很少用，只有在后面的插值才会有一定的使用。

四元数乘法代表了旋转顺序，按照顺序旋转进行前乘，例如如果先进行q1，再进行q2，那么总的旋转q就是：

为什么四元数可以解决万向节死锁

欧拉旋转的本质是将绕任意轴旋转最终分解为绕x，y，z轴的旋转，才会导致万向节死锁。而用四元数旋转可直接表示为绕任意轴旋转。通过四元数的表示方法就可以看出

四元数插值

四元数插值的方式相对比较特殊，我们不能直接简单的线性插值，按照比例将两个单位四元数加在一起：

这样的结果就是导致q(t)的长度不再是1，结果会在这条虚线上移动：

哪怕我们重新再把它的长度变回1，这个运动也不是随着角度而平滑运动的。所以我们需要用另一个方式进行插值，我们设下面的公式：

我们现在就是要接出来和，此时我们将沿着两个向量的方向进行分解，设是两个四元数之间的夹角：

根据相似三角形：

由于所有四元数都是单位四元数，长度都是1，所以：

也就是说四元数完整插值的公式是：

Ambient Occlusion

Mon, 05 Feb 2024 00:00:00 GMT

AO定义

AO全称Ambient Occlusion，即环境光遮蔽。用来加深场景的遮蔽效果，也就是加深阴影的效果。AO的实现可以更加真实的反应模拟世界中的能量守恒，被广泛用到游戏中。

经典的AO定义如下：

这个公式基于辐射度量学，满足能量守恒，用这个公式计算的AO在效果上是最佳的。

是位于表面的某点，是点的法向量，是在半球面内的立体角，是点的可见度函数：

因为和都是单位向量，令，这个积分可以化简为：

因此，的含义就是点在半球面内的遮蔽程度，可以证明：

其中。

因此，越接近1，那么的遮蔽程度越大。

传统的AO计算方法采用光线追踪算法。光线追踪算法的好处就是效果很好，因为是直接计算积分，满足能量守恒。

但是这种方法不适合游戏中，因为太慢了，所以就有了下面的计算近似AO的算法（强调一下，是近似AO）。

SSAO

SSAO是一种基于延迟渲染，在屏幕空间下计算的AO算法。这个AO算法本质上就是在屏幕空间下进行类似积分的运算，但是还是有一些差别。

原理当然需要用到G-Buffer，在获得四张贴图——位置（可选）、法线、环境光、深度之后，在屏幕空间中，进行SSAO的计算。

首先是获得AO贴图，AO贴图是一种灰度图，如下：

可以看出，有强烈的遮蔽信息。所以我们需要先生成这样的AO贴图。这就是所有AO算法需要实现的一点。但是传统的光线追踪需要大量的三角形求交，所以不适合在游戏中应用。这就为什么SSAO出现了，SSAO在屏幕空间中进行遮蔽计算。

如何获得AO呢？在屏幕空间中，首先遍历像素点，在像素点所在的世界空间坐标的法线方向半球面内随机的选取采样点，然后对这些采样点进行深度测试。也就是判断这些采样点是否被遮蔽，如果被遮蔽了，就计数加1. 最后算出被遮蔽的采样点和总采样点的比值，这个比值是永远小于1的。然后存入到贴图中。这样就能得到AO贴图了。

在后处理中，我们可以对这个AO贴图采样，得到的数值，作为Phong光照中ambient分量的参数：

怎么随机采样？

定义一个核函数，矩阵大小可以是8*8（假设），每个元素都是一个在切线空间的三维向量，表示的是xyz三个方向的随机采样点：

取值范围为[-1, 1], [-1, 1], [0, 1]，为什么要这样？因为我们是在屏幕空间里计算，而z轴在屏幕空间的取值范围就是0到1，其他的事-1到1.

为什么要定义在切线空间，试想一下，如果不依赖这样的核函数，那么我们对每个得到的顶点，都要在法线方向上进行核函数的生成，然后得到随机的采样点，性能差而且效果也和原本的差不多。所以最好的方法还是定义一个固定的随机核函数，然后对每个采样后的顶点进行切线空间到观察空间的变换即可，然后就能直接得到随机的采样点了。下面是计算AO的过程：

综上所述，SSAO采用了如下的近似：

引擎开发日志1 - Vulkan封装

Fri, 08 Mar 2024 00:00:00 GMT

技术栈

底层图形API：Vulkan

引擎语言：C++

脚本语言：暂定Lua

引擎的设计模式：主体采用ECS+MVC

Vulkan Base

Context上下文

Swapchain交换链

RenderProcess渲染阶段的Pipline、Layout封装

Renderer渲染器

Shader着色器

CommandMgr命令管理器

Vec2、Vec4、Mat4数学库（暂定先实现这些）

Texture纹理

DescriptorMgr描述符

Manager

ShaderMgr：负责管理Shaders，目前暂时采用哈希表映射

TextureMgr：在原有的TextureMgr基础上增加材质的管理

ModelMgr：管理模型

Descriptor Problem

目前封装存在的最大的问题是不够独立，新的模块需要频繁更改封装好的Vulkan库的代码，需要进一步将公用接口进行隔离。

引入

假设两个Shader，不考虑frag和vert，那么可能会出现以下共用uniform的情况：

我们会发现，view、projection和worldTime是公用的全局变量，可能多个Shader都会用到它，所以他们的Descriptor应该是只有一个的，而不能每个Shader都拥有一个相同Descriptor的拷贝，不然当项目大了起来对内存来说是致命的。

我们需要引入一个管理这些uniform相关的数据结构。

原有的流程

Context创建Shader模块

这个示例中，首先获取了ShaderMgr，然后创建名字为default的shader，然后设置DescriptorSetLayoutBinding，分别为MVP矩阵和texture：

其中ShaderMgr关于SetDescriptorSetLayoutBinding和CreateDescriptorSetLayout的函数如下：

descriptorSetLayoutBindings是一个键值对，需要提供这个描述符的绑定点名称和所属于的集合。

descriptorSetLayouts是创建后的layout，通过集合名称确定。

RenderPass确定Layout

Renderer阶段获取更新set

理解Descriptor

如下图所示：

不像OpenGL，Vulkan不能对单独的Uniform或者其他被描述的变量进行Buffer。而是采用集合的设计，将要在Shader使用的Uniform变量的布局被SetLayout指定，通过vk::DescriptorPool 分配出vk::DescriptorSet ，再由这个集合Buffer。这样做的效率比OpenGL高很多。

还是原来的问题，考虑公共UBO，比如view 和projection ，他们在渲染的过程中，只需要绑定一次即可。如果在OpenGL，每切换一个绘制对象就要重新绑定。所以很浪费效率。

Solution

解决方案是分别封装DescriptorPool，DescriptorSetLayout，DescriptorWriter，每个类都会有各自的Builder。

DescriptorSetLayout

该类提供创建vk::DescriptorSetLayout 的相应接口，能够接受多个多个binding。使用的方法如下：

这说明创建了一个全局setlayout，描述了一个binding = 0的uniform对象：

可以设置多个binding，只需要：

描述了：

DescriptorPool

DescriptorWriter

FrameInfo Problem

现在存在一个很大的问题就是FrameInfo的封装可以说是基本没有：

可以看到，不同的RenderSystem，可能会用不同的FrameInfo，我们这样使用会让代码非常的丑，而且很冗余。

目前能想到的解决方案之一就是修改FrameInfo的结构体：

将原来的的set改成了map，就方便集成descriptorSet了。

不过大概率之后会改，因为总会遇到很复杂的情况。

UBO

在vulkan中uniform不能单独buffer到device，需要由descriptor set描述，而descirptor set需要由descriptor pool分配。

基于这个理念，结合之前封装的Descriptor组件，可以封装出一个这样的UBO模板类：

记录第一次做肠镜检查

Thu, 14 Mar 2024 00:00:00 GMT

❔

为什么突然要做肠镜？3月9号的时候，述姐跟我聊天的时候聊到护肤，她说其实肠胃的健康程度影响皮肤也很深。我就突然想到自从去年开始我的右下腹部（应该是十二指肠那边）很胀，经常肠鸣有气体，当时耳朵的手术刚做完，就不想再去做检查了（对医院有些ptsd）。但已经一年了，并且志雄也说要检查，所以想想还是去做一下。于是第二天述姐陪我做了检查……

3.10去医院检查

挂了下午三点半消化内科的号，准时到达消化内科：

然后是一个很温柔的小姐姐给我做检查，问了我发病时间，体重有没有减轻，有没有便血，然后就开始摸我的腹部，检查我是不是有不舒服有疼痛感。

然后就安排我第三天进行无痛肠镜：

看得我心肌梗塞了，晚上得喝1L泻药，然后早上五点还得起来喝2L泻药+西甲硅油……

拿到单子之后就是依次进行：

检查心电图→给麻醉师鉴定是否能麻醉→取药

这个时候其实需要挂麻醉与围术期科，但是因为麻醉师很忙，挂不到号，就只能第二天早上8点过来鉴定。

所以直接取药了，拿了三包和爽和一瓶西甲硅油乳剂。

出了医院那一刻，就不能吃很多东西了。首先只能吃颜色浅的食物，其次只能吃消化好的食物。于是我只能眼睁睁的看着述姐吃好的呜呜呜：

我只能吃粥，而且要把皮蛋挑出去……述姐吃的肠粉可香了

还买了苹果和香蕉，这些可以吃：

之后回到宿舍了

吃泻药

做肠镜的全程，就这个最恶心最痛苦。因为这个和爽，非常难喝！而且还要1L，这是人能喝完的吗？

怎么形容这个和爽的味道呢？就是咸的菠萝味，但很奇怪很恶心。只能说喝过的人都懂。

我好不容易喝完（先记住这个），一段时间居然没反应，于是我躺在床上耍手机了。

然后没想到突然来感觉了，真的是差点就拉到床上了……我直接飞奔到厕所蹿稀。不得不说这个和爽是真的猛，把我的成年老💩都拉出来了。

之后和舍友聊了很久的天，八卦了贼多人，然后就睡觉了。

3.11做肠镜

早上五点

早上五点起来，继续把剩下的喝完。我在外面的走廊边散步边艰难的喝。

喝到后面实在是受不了快吐了，然后就去xhs上看看集美们的方法，没想到有两种：

用脉动兑

买根棒棒糖，喝一口甜一口

我两个都试了，第一个不太好，我还是觉得恶心。但是第二个很好，这样的喝法我确实不会觉得恶心了。

还得是集美。

最后一包泻药还得加上西甲硅油乳剂：

之后就又是愉快的蹿稀时间，此时已经拉不出内容物了，全是水。说明此时肠道应该是满足了检查的要求，很干净。

麻醉鉴定

因为涉及到全麻，所以要有人陪伴，很感谢述姐能在那么早的时候陪我去医院……感动呜呜叫。

七点半我们就出发去医院了，首先是麻醉鉴定。

麻醉医生问了我也没有什么疾病史，就差不多鉴定完毕了，可以做麻醉。

开始做肠镜

先换上了专用的裤子，然后在门口等了一段时间。

叫到了我之后，直接去了3号门口，医生问我是不是第一次做，还有疾病史什么的。随后拿了一张床，让我躺上去。

接下来就很恐怖了，医生首先让我侧着躺好（一定要侧着），然后拿出了氧气罐让我吸，此时我感觉像是要做大手术一样，很慌。接下来，医生拿了一个装满白色麻药的针筒（还挺大的）。慢慢地推入我的身体。

突然！我就没知觉了！woc，我还以为是有个渐渐没知觉的过程，没想到一下子我就没意识了。好神奇。接着我梦到了我在写代码（梦里还在打工呜呜呜），而且很真实，让我以为不是在梦里。

过了一会我就突然醒了，醒的时候述姐已经在我旁边了。然后我才意识到：噢我刚才在做肠镜。

刚醒的时候，腿都是软的，不能正常走路得扶着。再次感谢述姐！

然后述姐帮我拿报告，检测结果是没有问题的：

只能说幸好，那估计是肠道菌落紊乱的问题，医生给我开了几个养肠子的药就离开医院了。

爽吃

我们直接去学府路爽吃螺蛳粉！

（别学我，刚做完不能吃辣的，我已经受教训了，拉屎又疼又辣）

这就是我本人的第一次肠镜之旅了，总的来说很神奇。

简谈GPU性能

Thu, 01 Feb 2024 00:00:00 GMT

Chapter 34. GPU Flow-Control Idioms

GPU Gems 2 is now available, right here, online. You can purchase a beautifully printed version of this book, and others in the series, at a 30% discount courtesy of InformIT and Addison-Wesley.

https://developer.nvidia.com/gpugems/gpugems2/part-iv-general-purpose-computation-gpus-primer/chapter-34-gpu-flow-control-idioms

CPU vs GPU

CPU和GPU的最大差别就是，GPU比CPU多了很多ALU以及核心，并删掉了一些东西。从单核角度来看，GPU像是简单版的CPU，但GPU的核心非常多，这就导致了GPU在处理并行计算的时候是比CPU强很多的。

我们将上面的CPU“改造”成GPU：

为什么要这样改造？

Idea 1 - 移除不必要的部分

我们可以看到，GPU仅仅只保留了解码单元（Fetch/Decode）、数学逻辑运算单元（ALU）、执行上下文（Execution Context）三个部分，这样可以加速GPU核心执行一条指令的速度。由于GPU核心的架构更加简单，所以在同样大小的物理面积上，可以塞下更多的GPU核心。

Idea 2 - 在许多的ALU之间来分摊一条指令的开销（SIMD）

另一个可以加速程序运行的方式就是在多个ALU之间来分摊一条指令的开销，这样的技术也被称为SIMD（Single Instruction Multiple Data）

SIMD(Single Instruction Multiple Data)即单指令流多数据流，是一种采用一个控制器来控制多个处理器，同时对一组数据（又称“数据向量”）中的每一个分别执行相同的操作从而实现空间上的并行性的技术。简单来说就是一个指令能够同时处理多个数据。

所以现在，我们的GPU核心被设计成了如下的状态：

我们可以看到，在一个GPU核心中，不止一个ALU单元了。以上图所示，假设我们的GPU具有16个核心，每个核心中具有8个ALU单元，那么我们可以一次同时处理128个片元。

GPU的分支问题

在Shader和CUDA中，我们有一条约束规定：

尽量不要用if-else语句，尽量使用宏来代替它。

这是为什么呢？

Divergence问题

比如Shader在执行下面的分支语句：

但是由于在不同的ALU中执行，这里的x可能不一样，某些ALU中的x小于0，有些x却又大于0。所以就会出现如下图所示的情况，不同的ALU会执行不同的条件分支。

这样的一种情况就会造成 "Divergence"，通俗的讲就是不能够充分的发挥SIMD的性能。

Stall问题

Stall是在《计算机系统3》中学到的知识，因为当时是Stall问题出现在CPU的流水线设计中，当当前指令依赖于上一条指令的结果，但上一条指令的运算时间相对较长的时候，就要空出Stall，直到上一条指令的运算结果完成。

在GPU也会出现这种情况，就比如这个Shader语句：

需要对纹理进行采样才能得到kd，但是采样的话其实消耗的时间会相对长一些，这样下面的kd可能会出现Stall问题，即推迟当前指令的执行，当上一条结果出来后才继续。

解决方案就是不同核心之间交错处理片元：

简单的说：我们不用所有的核心来一次处理完所有的片元，而是用一个核心处理一组片元，这样交错的去处理。如上图所示，当一个核心发生stall时，我们采用另外的核心继续处理别的片元，这样我们可以保障当一个核心发生stall的时候，别的核心不处于空闲的状态。

总而言之，GPU相比于CPU

对核心架构进行瘦身，移除了不必要的结构，这样可以在同样大小的面积上塞入比CPU核心更多的核心数量

在一个核心中塞入多个ALU单元，并使用SIMD技术对运行程序进行优化。

通过交错处理片元的方式来减少程序的stall