自由學習記錄（68）

🧠 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() 做透視除法使用。

越不透明，越能折射效果