自由学习记录（68）-EW帮帮网

🧠 blender为什么不用 M 或 T？

键位	含义	为什么没选
`M`	Move？其实被用作「Move to Collection」等功能	不符合历史定义，而且功能太多了
`T`	Transform？但 transform 是一个总称（含移动、旋转、缩放）	`T` 被用来打开工具栏（Tool Shelf）

Blender 设计理念是 直接映射操作行为 而非语义缩写，所以：

"我抓住物体（Grab）→ 然后移动" 这个动作 = G

重启blender删除0的使用数据

动，这是特效

不是拿骨骼k的，特效拿骨骼去k---大材小用

丝袜的网格就不能是边缘清晰了

Alpha Cutout（又称 Alpha Test）

这些都是适合使用 Alpha Cutout 的典型场景：

镂空金属：例如铁丝网、铁门，alpha map 控制哪部分镂空。

裙摆边缘：卡通风格中经常用来表现轻飘飘的剪裁边。

特定风格下的头发：如二次元发卡、刘海尖等，边缘清晰，直接裁切。

树叶：一整片叶子贴图中，有 alpha 图表现叶子形状，用裁切来剔除空白区域。

卡通渲染特效：比如一些光环、魔法阵边缘清晰的效果。

边缘效果太实：

没有平滑渐变的边缘，会像“锯齿状”。

在一些软材质（如羽毛、烟雾）上不适合，看起来太硬。

移动端性能较差：

因为 clip() 或 discard 会造成分支跳转，GPU 不能批量并行执行，会增加性能压力（尤其 tile-based mobile GPU）。

Alpha Blend（左）：使用 alpha blend，像素不直接裁掉，而是混合透明度，边缘更自然，但排序问题严重。

Alpha Test / Cutout（右）：边缘硬，树叶清晰，没有叠加透明问题，适合植物类。

摄像机可以设置rendertype，改看到的物体材质的rendertype

当做形式，但特效相关

ab，如果是 Blend One OneMinusSrcAlpha

如果改成 Blend SrcAlpha OneMinusSrcAlpha

结果上预先再乘以一个alpha，所以会显得忘里面再吃一点，更加暗一点

视频里更明显

名称	意义
`Zero`	(0,0,0,0)，相当于完全不参与混合
`One`	(1,1,1,1)，完全参与
`SrcAlpha`	当前像素的 Alpha 值，用于控制透明度
`OneMinusSrcAlpha`	1 - Alpha，常用于背景保留比例
`DstColor`	目标颜色参与混合
`OneMinusDstColor`	背景颜色的反向
`SrcAlphaSaturate`	`min(alpha, 1-alpha)`，用于特殊自遮挡

名称	含义
`Add`	默认，Src + Dst
`Subtract`	Src - Dst
`ReverseSubtract`	Dst - Src
`Min` / `Max`	分别取颜色的最小值/最大值
`Multiply`	乘法混合，变暗
`Screen`	滤色，提亮
`Overlay`	叠加，亮中有暗、暗中有亮
`ColorDodge` / `ColorBurn`	高光/暗化模式
`HardLight` / `SoftLight`	硬光/柔光（Photoshop同名混合模式）
`Difference` / `Exclusion`	差值、排除，主要用于特效或滤镜
`HSLHue/Saturation/...`	高级 HSL 模式，需要扩展 OpenGL 支持

// 标准透明混合
Blend SrcAlpha OneMinusSrcAlpha

// 累加发光效果
Blend One One

// 全部替代原始颜色
Blend One Zero

右边要用到c#里面的知识

最终颜色=Src∗DstColor+Dst∗(1−DstColor)

每个通道是 逐个分量（component-wise）参与混合的，四个值完全独立。

Unity 和 OpenGL 中颜色混合不是单值计算，而是对 RGBA 每个分量 独立混合，DstColor 代表的是 (Rd, Gd, Bd, Ad)，参与逐分量乘法。

Shader 变量是否占用内存？：会占用，但很少
就像普通编程语言（如 C/C++）一样，Shader 中局部变量在函数作用域内会占据寄存器或临时存储空间，但函数执行结束后这些空间就被释放。它不会叠加占用内存，只会复用。

🧪 Blend 配置选择建议

使用场景	Blend 设置	说明
❌ 没有预乘	`Blend SrcAlpha OneMinusSrcAlpha`	Unity 默认
✅ 预乘了 alpha	`Blend One OneMinusSrcAlpha`	更干净，无边缘污染

实际在做特效的时候很多图都是预乘的

特效是，是拽特效库里面的图，里面的图有带alpha，有不带alpha的

所以需要根据这种复杂的情况做不同的shader

颜色预乘（Premultiplied Alpha）不是为了让颜色“变”，而是为了让混合公式更简洁、更正确。

RGB = 原始RGB × Alpha

这确实让颜色变得“看起来更浅”，但这不是为了视觉效果，而是为了更安全和高效的混合。

预乘的真实目的：

目的	说明
✅ 避免边缘污染	没预乘时，Alpha 为 0 的区域 RGB 仍保留原始颜色，可能在边缘混出错误色（常见于羽化、贴图压缩）
✅ 简化混合公式	使用 `Blend One OneMinusSrcAlpha`，跳过 shader 中手动 `rgb * alpha` 的步骤，提高效率
✅ 提高性能	在某些 GPU 中预乘图像可以加速合成处理，尤其是在后期特效、大量粒子系统中

贴图一个羽毛的边缘处，Alpha 为 0，但 RGB 仍是蓝色。
- ✅ 未预乘：这时候羽毛周围是透明蓝 → 混合会出现蓝边。
- ✅ 预乘：这时候羽毛周围 RGB = 0 → 混合干净无色。

即使 alpha 是 0，那些 RGB 信息仍然参与混合计算，只是最后你“看不到”而已，但它们影响了结果。

假设羽毛边缘处贴图颜色如下：

RGB = (0.0, 0.0, 1.0) // 蓝色  
A = 0.0 // 完全透明

outColor.rgb = Src.rgb * Src.a + Dst.rgb * (1 - Src.a)
             = (0.0, 0.0, 1.0) * 0.0 + Dst.rgb * 1.0
             = Dst.rgb

看起来没事对吧？但是如果：

贴图有压缩（如 DXT、BCn），蓝边可能“泄露”到 Alpha 不为 0 的区域
有MSAA、模糊、滤波、颜色拉伸等，RGB 会被周围像素采样
这时候这个“透明蓝”的 RGB 值就污染进来了

👉 所以虽然当前像素是 A=0，但它的 RGB 会影响附近的混合区域。

PR（Pull Request）是什么？

Pull Request（简称 PR） 是 GitHub（以及其他 Git 托管平台）中用于提议更改代码的机制。

你可以理解为：

“我 fork 或 checkout 了项目，在某个分支上修改了代码，现在我想合并回主项目，请大家审核我的代码。”

在 PR 页面上你可以看到：

哪些 PR 是 Open（未合并）
哪些是 Merged（已合并）
PR 的内容改了哪些文件、增加/删除了哪些代码

设置里的general

Branch Format（自动创建分支的命名模板）

当你让 Codex 帮你在 GitHub 上做代码修改、创建 Pull Request 时，它可能会自动为你创建分支（branch）。

这个设置决定它用什么格式来命名这些分支。

ta-fix/{feature}-{date}
就能生成 ta-fix/alpha-blend-fix-2025-07-08 这样的分支名。

设置里的environment

当你让 Codex 执行代码（比如测试脚本、自动安装依赖、运行构建任务等）时，它在什么系统环境下运行、如何准备运行环境、是否联网等。

Container image（容器镜像）

这是你代码执行时用的基础系统环境，类似虚拟机的“操作系统”。

你选择的是 universal，它是基于 Ubuntu 24.04 的通用镜像，已经预装了很多常见工具（如 Python、Node.js、Git、curl、pip 等）。
点旁边的 Preinstalled packages 可以查看这个环境自带了哪些依赖。

💡 **理解类比：**你可以把它当成“你租给 Codex 用的一台电脑”，这就是装的系统。

Environment variables（环境变量）

这里可以设置运行代码时注入的环境变量，常用于：

设置路径（如 PATH=/custom/bin）
提供构建标志（如 BUILD_ENV=debug）
控制行为（如 USE_GPU=false）

🚫 默认不需要设置，除非你知道项目某些部分依赖这些变量。

Secrets（机密变量）

这里可以添加一些不应该暴露在代码里的敏感信息，如：
- API token（比如 GitHub Token）
- 密码、私钥路径
Codex 会在运行环境中注入这些 secret，但不会在输出中显示出来（防泄漏）

📌 适合你之后部署 Web 项目或要访问私有资源时使用。

“Network access is always enabled for this step.”
意思是 这一段 setup 脚本始终可以联网执行，哪怕你在其他地方关闭了 Codex 的联网权限。

所以你需要确保 setup 脚本不会拉取恶意代码或安装危险依赖，尤其是在使用第三方仓库或插件时。

这里的Test和Createpr是干什么的

这整个过程

步骤	意义
✅ Codex 生成了脚本	写入了 `SimpleLogger.cs`
✅ 自动跑了 `git status`	检查是否准备好纳入提交
✅ 输出干净	说明文件被正确追踪，没有遗漏
✅ 可以点击 “Create PR”	正式发起 Pull Request，推送到 GitHub 上

`Create PR` 按钮 —— 是创建 GitHub Pull Request 的快捷入口

你点这个按钮，就是：

将 Codex 生成的更改（在右侧 Diff 面板中可见）作为一次 Pull Request（合并请求）提交到你的 GitHub 仓库。

也就是：你允许 Codex 把这次代码更改作为“一个功能或补丁”正式提交，并进入 GitHub 的协作工作流。

现在尝试Createpr

跳转到view视图里面

xxxxx

我的建议还是去好好玩几遍 https://编辑learngitbranching.js.org/?locale=zh_CN git 游戏, 理解一下 git 的底层逻辑, 不然以后你碰到 git 问题真的挺恶心的. 如果你真的把版本控制弄的一团糟, https://ohshitgit.com/ 是你的解药.

----

结论是codex速度太慢，稍微又熟悉了一下github

xxxxx

浮点精度问题，噪声图和maintex相互交错，所以需要frac

UV 被扰动后超出了 [0,1] 范围

uv += noise; // noise 可能是 [-1, 1]，扰动后 uv > 1

精度，超出的部分没东西采样，就透明

frac(x) 会保留 x 的小数部分，相当于将 UV 强制 wrap 到 [0,1) 区间

frac(0.25) → 0.25
frac(1.001) → 0.001
frac(-0.3) → 0.7（因为 floor(-0.3) = -1, 所以 -0.3 - (-1) = 0.7）

和 `mod(x, 1.0)` 的区别？

frac(x) 和 mod(x, 1.0) 类似，但 frac 更快，且语义专为 [0,1) wrap 设计
注意：对于负数时，frac 总是返回正数，而 mod 会根据语言/平台返回正负不定（GLSL 的 mod 和 HLSL 的 mod 表现不同）

系统时间留到非常非常久了

如果在多个 DCC 软件中只做简单建模（正方体、雕刻等），导出的 FBX 是否可以完全统一？
又是哪些额外因素会导致 FBX 不再一致？

❌ 骨骼、权重、动画等内容 —— 不能保证完全通用

功能项	FBX 是否支持	不同 DCC 软件是否能一致解析	原因说明
✅ 网格结构	✔️ 完全支持	✔️ 一致（标准几何体）	顶点、面、UV、法线都定义明确
⚠ 法线切线	✔️ 支持	⚠️ 有时自动重算或丢失	依赖导出选项与导入默认设置
❌ 骨骼结构	✔️ 支持	❌ 节点坐标系/绑定姿态不同	rest pose / joint orientation 差异
❌ 绑定权重	✔️ 支持	❌ 权重精度/归一化方式差异	有时需要重刷或重新绑定
❌ 动画轨迹	✔️ 支持	❌ 曲线解码方式不同	有些软件用自定义控制器
❌ Blendshape	✔️ 支持	❌ 命名方式、存储策略不一	Maya vs Blender 表达方式不同

只包含模型构建（Mesh）本身的 FBX 文件，是可以做到几乎完全通用的，即：

几何体（顶点、边、面）
UV 坐标
顶点法线（如正确导出）
基本贴图路径（漫反射贴图）

这些内容在主流 DCC 软件（如 Blender、Maya、3ds Max、ZBrush、Unity、Unreal）之间是可交换、可解析、可正确导入的。

xxxx

lerp(a, b, t) 中的 t 超出 [0, 1] 时，结果仍然会被正常计算，且可能为负数。不会自动 clamp。

如果你想确保 t 限制在 0 ~ 1 范围内，需要手动加 saturate(t)：

lerp(a, b, saturate(t)); // 只在 0~1 内插值

噪声图单通道，扭曲图是三维的

两个通道控制uv的扭曲方向，blue通道保存噪声图

remap是希望可以往正负两个方向去偏移，所以

图存0~1，然后需要变成正负方向remap，-0.5，再乘2

变成-1~1

noise图里面的数字的含义是，对需要影响的图的影响权重，独立则不会产生任何意义

噪声图的值 ≠ 意义，而是意义来源于你如何使用它

举例：

用法场景	噪声值代表的意义
UV扰动（flow map）	像素值代表扰动的方向或偏移量
溶解遮罩（dissolve）	像素值作为某一阈值的比较，控制显示区域
光照扰动（Fresnel mask）	像素值作为 Fresnel 效果叠加因子
透明度扰动（你现在的 GhostWarp）	像素值参与透明度计算，改变渲染效果
随机颜色混合、分布、特效参数控制	像素值控制混合比、颜色选择或变化速率等

half noise = lerp(1.0, var_WarpTex.b * 2.0, _NoiseInt);
opacity = baseAlpha * noise;
此时：

var_WarpTex.b 是噪声图中的每个像素值

它的作用是：“让 opacity 按不同像素位置产生扰动”

如果你注释掉这句，用常量 1.0 代替 noise，那噪声图再存在也毫无意义

return float4(-1.0, 0.5, 2.0, 1.0);
在不同平台中你会看到：

条件	最终显示颜色
普通 8bit 屏幕输出（LDR）	黑+中绿+纯白 → 实际为 (0.0, 0.5, 1.0)
使用 HDR Camera + Bloom 后处理	可能看到泛光或亮度异常
自定义 RenderTexture 输出	保留完整 float，结果依赖后续处理

你看到的结果是混合误用的副作用，不是设计内的“反色效果”

它并不稳定，也不跨平台，在移动端、低配机或 Vulkan/Metal 下可能直接变黑或完全透明。

总结：蓝色 → 变橙黄是合理的，原因如下：

步骤	解释
蓝色 × -1	得到负蓝（0, 0, -1）
作为 Src.rgb 参与混合	变成 `+1.0 + 背景*2`（超亮 + 冲突）
背景叠加高亮蓝	Gamma 曲线 + Bloom 推向橙黄方向
显示器 clamp & tonemap	导致白泛、橙斑、颜色错觉

之后的课程加上背景扭曲

对于一个像素来说，当 UV 被放大（乘以大于 1 的数），会导致其在纹理空间中“移动得更快”，从而在屏幕空间中采样到更密集、更细小、更重复的图案；而“差别变小”，是因为单位屏幕距离内采样的纹理跨度更小、变化频率更高，导致整体趋于细节压缩。

官方建议把uv拿float去存储

对啊，这些都是变量啊，为什么一定要按照标准来，这里也只是介绍了方法去使用uv

这个Ghost的逻辑写的，导致wrap强度调整还会移位MainTex

xxxxx

这种就简单做个河流，做个小池塘

xxxx

直接使用offset里面的值去改变流动

UnityObjectToClipPos (v.vertex) is required because every vertex shader must output the vertex position in clip-space (the value carrying the semantic SV_POSITION). If the GPU doesn’t receive that clip-space position for each vertex, it cannot:

Clip triangles against the view frustum.
Homogeneously divide the coordinates to produce normalized device coordinates (NDC).
Rasterize the triangles into fragments and interpolate any other varyings you send (UVs, colors, normals, etc.).

Is the generated `o.pos` value “used”?

By the GPU pipeline: absolutely—rasterization depends on it.
By your own code: you rarely sample it directly in the fragment shader, but any macro that needs screen position, depth, or fog will consume it (e.g. COMPUTE_SCREEN_POS, TRANSFER_SHADOW in Unity shaders).
If you omit or write an incorrect SV_POSITION, the mesh won’t appear or will be clipped incorrectly, even if all other varyings are perfect.

观察空间 VS（View Space）：float4

定义：以相机为原点的坐标空间。（ps：观察空间与屏幕空间不一样，观察空间是一个三维空间，屏幕空间是二维空间）。

https://zhuanlan.zhihu.com/p/505030222

Unity 渲染流水线变换矩阵详细讲解_哔哩哔哩_bilibili

【教程】技术美术入门：渲染管线概述_哔哩哔哩_bilibili

近大远小的效果，根据near和far压扁模型，展现正常图片效果

只是把模型进行了一个变形的处理

灰色部分都是硬件去处理的，不能控制

视椎体剔除，是针对一整个模型的

投影矩阵本身不能“删除”物体，它只负责把视野内的空间投影成 Clip 空间值。
真正进行“剔除”的是 GPU 固定功能管线，对 Clip 空间做裁剪规则判断。

控制是否参与“裁剪空间剔除”（GPU自动）

这是 GPU 光栅化阶段默认的行为，但你间接可控：

控制方式	控制对象	举例与说明
✅ 修改 `Projection Matrix`	控制裁剪区域范围	例如：加大FOV、拉远近平面，Clip空间容纳更多
✅ 改变传入顶点位置	你自己修改了 vertex shader 输出的 `SV_POSITION`	比如“假装”物体在视野内，让它不被裁剪
⚠️ 不推荐：强行输出视野外点	可以让视野外物体被“拉回屏幕”	但这会造成视觉错位或崩溃，不常见

总结：你无法关掉裁剪机制本身（除非你完全重写渲染流程），但你可以通过“改变投影矩阵”或“修改传入坐标”间接绕过。

SRP 不能取消的：

固定流程阶段	是否可控	原因说明
Clip Space 裁剪（裁剪坐标超出 -w~w）	❌ 不可控	这是 GPU 固定的光栅化前流程，无法在 SRP 级别关闭
Homogeneous divide（齐次除法）	❌ 不可控	这是 GPU 自动做的投影机制
深度测试、Z-buffer 写入（除非你禁用）	部分可控	你可以关掉 ZTest，但不能移除整个深度机制本身

透视除法之后，转（标准化设备坐标） NDC在通过顺逆时针剔除了背面的三角面之后

就要进入屏幕空间（转换成屏幕的1920x1080）这样的形式

这个过程里只拿xy坐标，z坐标后面有更重要的事

TRANSFORM_TEX 是 Unity Shader 中一个非常常用的宏函数，主要用于对 纹理坐标（UV）进行缩放和平移变换

#define TRANSFORM_TEX(tex, name) (tex.xy * name##_ST.xy + name##_ST.zw)

- frac(_Time.x * _ScreenTex_ST.zw)

减法是移动的标配

`screenUV *= originDist` 的行为不总是视觉合理

它是用物体离相机距离 Z 来缩放屏幕 UV
但这个“锁大小”是假设物体平行于摄像机投影面

⚠️ 如果模型不是正对相机（比如有角度），这个缩放会导致视觉失真或纹理漂移

tex2D(_ScreenTex, i.screenUV) 里的 screenUV 可以大于 [0, 1] 吗？如果超出范围会发生什么？

答案是：

✅ 可以大于 0~1，关键取决于纹理的 Wrap Mode（环绕模式）

默认行为（Unity中多数纹理默认是 Repeat）：

`i.screenUV` 范围	`tex2D` 的采样行为	说明
0 ~ 1	纹理正常采样	落在贴图内部
>1 或 <0	取决于贴图导入设置中的 Wrap Mode	会发生重复、拉伸、或边缘值钉死等现象

贴图方向完全取决于模型的 UV 展开方式，与世界空间的 XZ 无直接对应关系，而与模型局部坐标系中顶点的 UV 映射有关。

也就是说平面的uv是有问题的，不要信

可以信的，只要你可以位移，和你可以放缩整体

tiling很大，超出了0到1的范围，但此时的offset是相对于原uv0到1的移动手段，而移动是是整体，所以offset独立于tiling的密铺

return uv.r

也就是说左边的uv为1，和物体的坐标系相反，这个plane的uv是这样映射的

直接整个都是反的，靠

`posVS.z`

是当前 顶点位置 v.vertex 转换到 View Space 后的 Z 值
即：这个点 相对于摄像机的前后距离
注意：在 Unity 中，Z 轴朝向是负的，所以：

posVS.z < 0 → 在摄像机前面（正常可见）

posVS.z > 0 → 在摄像机后面（看不到）

`originDist`

是 模型原点 (0, 0, 0) 转换到 View Space 后的 Z 值
也就是：整个物体中心（模型局部坐标系原点）离摄像机的 Z 距离

这通常作为一个“基准深度”或“单位深度参考”。

`o.screenUV = posVS.xy / posVS.z;`

👉 这是在 View Space 里直接除以 Z，没有转换成 Clip Space。
这样也可以吗？为什么？

可以，但只是近似模拟透视投影效果，不是完整的标准投影流

这个写法是 一种“自定义构造屏幕投影UV”的简便方式，在不使用完整 MVP（Model-View-Projection）变换的情况下，模拟投影缩放效果，常见于早期或者低开销 Shader。

但注意：这种方式是“非线性近似”的

项目	`posVS.xy / posVS.z`	正规 `clipPos.xy / clipPos.w`
精度	低，不能精准对应屏幕像素	高，严格按照投影矩阵压缩
投影适配性	固定 FOV + 固定 NearFar 才能稳定使用	任意 FOV、透视矩阵都支持
视觉表现	可用于模拟投影、屏幕UV、雷达图、波纹等	准确用于屏幕UV、GrabPass、遮罩、溶解等

你现在这种写法是合法的，特别适用于：

没有 GrabPass，但想要制作“贴屏特效”
只需要视觉感受类似透视缩放，不追求像素精确投影
效果贴在 Plane、Quad 上，或者用在扰动类 FX 中（水波、能量、雷达）

阶段	名称	作用
View Space	相机视角下的真实空间，仍是“物理单位”（米）	有透视锥体结构，Z 越大越远
Clip Space	被投影矩阵拉伸成四维“正方锥”	进行裁剪、透视除法前的空间
NDC Space	经过除法后压成了长方体（[-1, 1]^3）	屏幕映射前的标准单位坐标

除以了view space下的z，

解决了一个问题，不会畸变了，但带来了一个问题，就是现在不会随着远近而变化这张贴图了

接着就解决近大远小的效果

不要用顶点的距离，因为这里除一下再乘一下还是回去之前的效果--依然畸变

在 Unity 内置渲染管线中可以这样GrabPass （虽然不推荐大规模使用）

在 URP / HDRP 中，GrabPass 被弃用，但提供了更高效更明确的替代方案

URP: _CameraOpaqueTexture（你要在管线设置中开启）
手动 Blit + 设置 RenderTexture 给 Shader
使用 CommandBuffer.Blit 将屏幕渲染缓存下来

Blend 是“当前像素缓冲区中的颜色”

它只能访问：当前正在写入的目标像素点的颜色
这通常是：Framebuffer 中该像素的已有颜色（上一层 pass 或物体渲染后的结果）
操作由 GPU 的渲染硬件自动进行，不允许你手动读取或修改，只能通过 blend 参数控制混合方式：

Blend SrcAlpha OneMinusSrcAlpha
💡 你只能控制颜色怎么混，但不能读它的内容，也不能改它对应哪块区域。

GrabPass 是“整张屏幕截图的纹理”

它会在渲染这个物体前，把整个屏幕内容渲染成一张纹理（RT）
然后你可以在 Shader 中任意采样任意位置的屏幕内容：

tex2Dproj(_BGTex, grabPos);
可以采样的区域不仅限于当前像素点，可以扭曲、扰动、偏移等操作

在 tex2Dproj(_BGTex, grabPos) 中，使用 proj（投影采样）而不是常规 tex2D()，是因为 GrabPass 返回的是屏幕空间坐标中的一个齐次坐标（Homogeneous Coordinate），也就是一个 clip space / projection space 的值，带有 w 分量，它必须被还原成 2D UV。

函数	传入参数	会不会自动除以 `.w`	典型用途
`tex2D()`	`float2 uv`	❌ 不会	普通 UV 贴图
`tex2Dproj()`	`float4 uvwq`	✅ 会除以 `.w`	投影纹理 / GrabPass 的屏幕坐标

一小时入门URP：从渲染原理到艺术馆制作_哔哩哔哩_bilibili

xxxxx

针对网格的shapekey

GrabPass 提供的是屏幕图像，但这个图像的采样坐标来自 裁剪空间（Clip Space） 的输出 SV_POSITION。

o.grabPos = ComputeGrabScreenPos(o.pos); // 背景纹理采样坐标
的意义非常关键：它将顶点的裁剪空间坐标 o.pos 映射成可以用于采样 GrabPass 背景纹理的坐标，并且保留为 float4，供后续 tex2Dproj() 做透视除法使用。

越不透明，越能折射效果

是合理性的编排

自由学习记录（68）

🧠 blender为什么不用 M 或 T？

🧪 Blend 配置选择建议

预乘的真实目的：

PR（Pull Request）是什么？

设置里的general

Branch Format（自动创建分支的命名模板）

设置里的environment

Container image（容器镜像）

Environment variables（环境变量）

Secrets（机密变量）

这里的Test和Createpr是干什么的

`Create PR` 按钮 —— 是创建 GitHub Pull Request 的快捷入口

现在尝试Createpr

和 `mod(x, 1.0)` 的区别？

如果在多个 DCC 软件中只做简单建模（正方体、雕刻等），导出的 FBX 是否可以完全统一？
又是哪些额外因素会导致 FBX 不再一致？

❌ 骨骼、权重、动画等内容 —— 不能保证完全通用

noise图里面的数字的含义是，对需要影响的图的影响权重，独立则不会产生任何意义

噪声图的值 ≠ 意义，而是意义来源于你如何使用它

你看到的结果是混合误用的副作用，不是设计内的“反色效果”

总结：蓝色 → 变橙黄是合理的，原因如下：

Is the generated `o.pos` value “used”?

观察空间 VS（View Space）：float4

控制是否参与“裁剪空间剔除”（GPU自动）

SRP 不能取消的：

`screenUV *= originDist` 的行为不总是视觉合理

✅ 可以大于 0~1，关键取决于纹理的 Wrap Mode（环绕模式）

默认行为（Unity中多数纹理默认是 Repeat）：

`posVS.z`

`originDist`

`o.screenUV = posVS.xy / posVS.z;`

但注意：这种方式是“非线性近似”的

Blend 是“当前像素缓冲区中的颜色”

GrabPass 是“整张屏幕截图的纹理”

网站公告

今日签到

热门文章

最新发布

自由学习记录（68）

🧠 blender为什么不用 M 或 T？

🧪 Blend 配置选择建议

预乘的真实目的：

PR（Pull Request） 是什么？

设置里的general

Branch Format（自动创建分支的命名模板）

设置里的environment

Container image（容器镜像）

Environment variables（环境变量）

Secrets（机密变量）

这里的Test和Createpr是干什么的

Create PR 按钮 —— 是 创建 GitHub Pull Request 的快捷入口

现在尝试Createpr

和 mod(x, 1.0) 的区别？

如果在多个 DCC 软件中只做简单建模（正方体、雕刻等），导出的 FBX 是否可以完全统一？ 又是哪些额外因素会导致 FBX 不再一致？

❌ 骨骼、权重、动画等内容 —— 不能保证完全通用

noise图里面的数字的含义是，对需要影响的图的影响权重，独立则不会产生任何意义

噪声图的值 ≠ 意义，而是意义来源于你如何使用它

你看到的结果是混合误用的副作用，不是设计内的“反色效果”

总结：蓝色 → 变橙黄 是合理的，原因如下：

Is the generated o.pos value “used”?

观察空间 VS（View Space）：float4

控制是否参与“裁剪空间剔除”（GPU自动）

SRP 不能取消的：

screenUV *= originDist 的行为不总是视觉合理

✅ 可以大于 0~1，关键取决于纹理的 Wrap Mode（环绕模式）

默认行为（Unity中多数纹理默认是 Repeat）：

posVS.z

originDist

o.screenUV = posVS.xy / posVS.z;

但注意：这种方式是“非线性近似”的

Blend 是“当前像素缓冲区中的颜色”

GrabPass 是“整张屏幕截图的纹理”

网站公告

今日签到

热门文章

最新发布

PR（Pull Request）是什么？

`Create PR` 按钮 —— 是创建 GitHub Pull Request 的快捷入口

和 `mod(x, 1.0)` 的区别？

如果在多个 DCC 软件中只做简单建模（正方体、雕刻等），导出的 FBX 是否可以完全统一？
又是哪些额外因素会导致 FBX 不再一致？

总结：蓝色 → 变橙黄是合理的，原因如下：

Is the generated `o.pos` value “used”?

`screenUV *= originDist` 的行为不总是视觉合理

`posVS.z`

`originDist`

`o.screenUV = posVS.xy / posVS.z;`