上篇说过我或许没那么坚持游戏行业，可是啊，真到了要转行的时候我却犹豫了，我在犹豫什么啊？我csndm
我又拿到一个offer，景嘉微长沙，蛮好的，半导体行业，国内做图形GPU的据我了解目前就2家一个摩尔线程，一个景嘉微，半导体行业也不是想进就能进的，薪资甚至涨幅50%，在长沙也是属于top了，如果在当前美国持续制裁国内的半导体，以及AI的发展，还有Nvidia一家独大的环境下，我预测国内的GPU发展起来是必然的，而且这个公司有军工的背景，如果真的入行了，绝对是前途无量的。然而我却犹豫了。
是的，我甚至都没有想到我如此的坚持游戏行业，现实情况如此的糟糕，游戏行业的管制，大厂的垄断，内卷的现状，以及各种糟粕的游戏，即使在游戏行业短时间内你也不会做出什么优秀的作品不是嘛？
那虚无缥缈的梦想不断牵引着我向前，我不知道前方有何种东西在等着我，改变不一定是坏事，但也不一定是好事，如果换任何一个正常的人选，我觉得他都会选择半导体这条康庄大道，跟着时代的潮流，猪都能在风口上飞起来，但，猪啊猪，你是否想要飞呢？
这份稳定而又令人羡慕的工作也像一面明镜，映射着我的内心，真的到这个抉择的时候，我才发现...
迷茫终究是迷茫了起来，初中没迷茫，高中没迷茫，大学也没迷茫，进社会了，开始迷茫了，总感觉用力使不上劲，不是那么尽力，又已经很尽力了，像一个陷进泥潭里面往上挣扎的人，你说他死了我觉得也差不多，但他又确实没死，感觉上还能抢救下。
想要去做游戏，学了那么多，找不到工作hh，小丑面具终究是带上了，那初中开始厌学了，没考个好大学，真后悔吗？其实也不，高三都不知道什么985211的，我觉得根本就不在一个起跑线，学历这样对自己来说可以了，说实话当你真看见过某些领域的巅峰后，你就能深刻明白自己的差距到底在哪里，比如说空洞骑士的四锁五门，当你真看到那些所谓的大佬第一次通关视频的时候你会发现它们其实本质上没有什么不一样，就是不断地练习，但就是你能不能接受这个练习的过程而已。
沉淀需要时间，我想去争取这个时间，所以实习后的第二步打算是再找一个起码有点或者不出名，但必须有我个人认可作品的团队，看看到底为什么，尝试了6个月吧，4月份开始，到10月份，也想从目前做的公司离职，原因是根本没有一个像样的团队（不知道在干嘛，主管别的公司的，有问题说一声后基本自己解决，debug全是格式的修正，很多时候靠几乎同级的...
UnityShader基础知识UnityCG.cgincUnityCG.cginc是与Unity捆绑在一起的shader包含文件之一UnityShaderVariables.cginc定义了渲染所需的一大堆着色器变量，如变换、相机和灯光数据。这些都由 Unity 在需要时设置HLSLSupport.cginc进行了平台设置，因此无论你针对哪个平台，都可以使用相同的代码。因此无需担心使用特定于平台的数据类型等UnityInstancing.cginc专门用于实例化支持，虽然它不直接包含该文件，但它依赖于UnityShaderVariables
subshadersubshader可以使用多个shader变体组合在一起,允许构建不同平台跟细节,例如为windows使用一个subshader,移动设备使用另一个subshader
passsubshader必须至少包含一个pass,shaderpass是实际被渲染的地方,可以有多个,有多个pass意味着被渲染多次但对于效果来说是必须的
CGUnity的shaderLanguage HLSL跟CG的变体,必须用关键词指示CGPROGRAM...
噪声（快速简介）有点累，也有点晚，写的很敷衍，嗯~ o(￣▽￣)o
基础哈希我们可以instance一个n*n的cube 的tile 然后根据随机的哈希值还有uv去赋值不同的颜色
这里介绍一个Small xxHash https://xxhash.com/
实现出来大概长这样
可以根据不同的cube的position以及uv 实现不同的效果（比如球，环）
值噪声（ValueNoise）根据不同的点的线性插值来实现的
一维
二维
三维
柏林噪声（PerlinNoise）一维
二维
三维
噪声变体（Noise Variants）这部分主要是一些噪声发明者实际上论文里的实现参数（值）应该是什么
分型噪声（Fractal Noise）频率（Frequency）噪声的频率，它描述了它的变化速度八度（Octaves）分形噪声由不同频率的多个样本组成。这些被称为Octaves（其实不太好翻译，我觉得可以叫小分型？）振幅（amplitude）分形噪声的概念是，一个Octaves的振幅随着其频率的增加而减小空隙度（Lacunarity）频率缩放被称为噪声...
Part I重点是介绍基础的怎么使用，有以下的重要结构
所有的workUnit里面的，不同类型的音乐如场景，人声可能由不同的公司制作，所以有一个workUnit方便集合（本身是xml文件）
有三个重点部分
Audio目录存储所有音乐资源
Events事件管理音乐内部的逻辑（播放循环等，且事件底下统一按小写处理，不区分大小写）
SoundBank主要是用来与代码交互，代码要找到相应的SoundBank 才可以调用下面的事件
soundbank生成目录就是游戏需要调用的目录，event要扔在SoundBank里，Audio通过Event管理
Part II重点在于编辑器的使用 音高，音频编辑（裁剪，淡入淡出），随机类型的音乐（虚文件夹），序列类型的音乐（虚文件夹）等
感觉用起来很舒服，起码比FLstudio要舒服的多，左下角有所有的功能提示，FLstudio只有简介，Wwise甚至有说明，各种编辑起来也很方便，不知道是不是因为本身属于一种编程思想的音频引擎？O_o
有一个值得注意的地方是，在编辑器里面Audio目录里面Copy是新建的引用，而不是新建文件夹，引...
SIMDSingle Instruction Multiple Data，单指令多数据流，可以使用一条指令同时完成多个数据的运算操作。传统的指令架构是SISD就是单指令单数据流，每条指令只能对一个数据执行操作。
简单举个例子一次可以算4次加法
使用方法1：内联汇编下面的写法是 GCC 和 Clang 等编译器支持的特性。Visual Studio 使用的 MSVC 编译器并不支持 GCC 风格的内联汇编
12345678910111213141516171819#include <stdio.h>#include <stdlib.h> int main(){ float a[4] = { 1,2,3,4 }; float b[4] = { 5,6,7,8 }; float res[4]; __asm__ __volatile__( "movups %1,%%xmm0\n\t" // 将a所指内存的128位数据放入xm...
FFXVI Shadow Part V正文Part V ：HiQuality最后的第 5 阶段处理重要角色的更高质量的阴影,绘制在专用的Closeup Shadowmap中,在现有的 VisibilityBuffer 上合成角色阴影
Closeup Shadowmap:与我们的高质量阴影技术一起使用。与普通阴影贴图一样运行，但视图仅限于一个感兴趣的对象，而不是整个光源的视野，以获得更好的分辨率精度。
Output: Updated Final Light List Buffer当阴影图块从完全亮起变为部分亮起时，需要分配一个Visibility Slot并保存Visibility SlotID。相反，需要通过将 Visibility SlotID 替换为完全点亮的标志。这两种情况都通过更新最终光源列表缓冲区中的阴影图块条目来处理。
Output: Updated VisibilityBuffer使用特写阴影贴图生成阴影。当灯光/像素可见性降低时，其在 VisibilityBuffer 中的值将更新。
Output: Updated Standard Shadowmap...
FFXVI Shadow Part IV正文Part IV ：Generate第 4 阶段使用从原始延迟照明着色器导入的代码计算每个光源的每像素可见性。使用Early Light List buffer中 Shadow Tile 条目中的光源列表，我们迭代它们以使用 Percentage Closer Soft Shadows 生成阴影，但可以用任何其他技术替换它。
Output: VisibilityBuffer
此缓冲区包含 8x8 内存块，用于存储shadow tile的每像素光可见性。这是延迟阴影系统所需的最大中间缓冲区，一旦照明阶段完成，就可以在帧的其余部分丢弃（其他缓冲区也是如此）。每个像素使用 8 位来表示光可见度的百分比，但 4 位可能就足够了，具体取决于项目的需要。
’Generate Deferred Shadows’ compute shader pseudo code 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051...
FFXVI Shadow Part III正文Part III ：Find Lights此第 3 阶段过滤来自 Tile Group Light Mask Buffer 的光index，对每个 Shadow Tile 进行更准确的每pixels测试。由于之前的结果由多个阴影图块共享，并且 Froxel 测试会产生误报，因此我们在下一步计算阴影之前尽可能多地消除阴影当每个计算线程处理 1 个pixels时，我们读取场景深度并迭代 Tile Group Light Mask Buffer 条目中的 Tile Group 灯光。shadow tiles考虑当光源在其至少一个pixels的范围内时，该光源是有效的。
在阴影图块中发现的光源近似值的精度误差。此处显示了两个 Froxel，由它们的 Shadow Tile 绑定加上最小和最大像素深度分隔。在Shadow Tile 1中，使用精确测试时，只有灯光A和D才能找到。通过更快的近似值，灯光 B 和 C 也会被错误地检测到（对这个阴影图块的像素没有影响）。Light B，因为它位于 Shadow Tile Froxel 内部。和光 C，...
FFXVI Shadow Part II正文Part II ：Approx主要有两个目标
查找每个阴影图块的潜在有效光源
储存在构建的光源列表里
从depthBuffer 1 获取每个shadow tile的最小和最大场景深度，通过他们于屏幕坐标组合生成Froxel(视锥体素，使用tile的坐标跟最近/远深度的位置定义视锥体的子部分)
从Tile Light Mask Buffer 和 zBin Buffer中找到Froxel有效的光源下标，通过使用快速球体测试以及Froxel的范围点判断每个光源该测试取自文章
https://bartwronski.com/2017/04/13/cull-that-cone/
输出1: Tile Group Light Mask Buffer（tile组用于查找近似的光的可见）输出2: Tile Light SlotID Buffer（Tile Light SlotID Buffer GPU 缓冲区，用于存储在近似阶段分配后每个 Shadow Tile 的 Light SlotID。）（Tile Light SlotID：...