專案裡做水 或者 景深等其他一些效果經常要用到depth buffer。但是unity不許直接訪問depthbuffer.(ps 同時讀寫depthbuffer會造成硬體打斷，對效能也不友好)。所以，如果想用depth,有三個解決方案
1.也是unity提供的開啟乙個depth pass,應該也會用來當做early-z的優化吧（霧。（有個問題 就是unity把 depth pass和shadow cast pass合二為一了 沒辦法不開深度還想要陰影）缺點就是就是drawcall 數量翻倍，對效能影響還是挺大的。
2.把深度寫入到frame buffer的a通道裡，渲完非透明物體後，blit出來使用。缺點就是精度不夠，即使歸一化由於只有8位，精度也不夠。
3.也是我最近測試乙個方案，自定義maincamera的 colorbuffer和depthbuffer。然後當做globaltexture傳入給shader使用。最後在通過onrenderimage 或者 onpostrender blit回framebuffer。缺點就是記憶體消耗比較大，需要2張rendertexture。同時在dx11裡有問題，不排除某些android機型有問題。(ps 之前在專案裡測試 發現unity自帶的depth精度比自定義的精度高很多，經過unity人員的幫助，確認紋理貼圖宣告需要為 sampler2d_float 參考 測試時被另外乙個問題坑了1個小時 就是手機上的shader要放到resources資料夾下，不然blit是blit不成功的）
順便調研了下android的渲染流程:
1.unity對於android，缺省會建立乙個自定義的rt，然後渲染目標都是這張rt，最後在blit回framebuffer。通過跟別人**，這麼做的原因可能有兩點 1.平台適配，畢竟android太多，如果直接渲染到framebuffer上的話，某些操作可能平台不支援。為了統一，就渲染自定義的rt上。2.當有後處理的時候，如果是直接渲染到framebuffer上的話，unity傳入的src需要通過readpixel api來回傳，設計到gpu往cpu通訊，頻寬占用太大。
2.如果有後處理，unity會先渲染到一張temp的rt上，然後在blit到最開始建立的rt上，然後在blit到framebuffer上。（通過snap draggon抓幀檢視的，可能不準確。沒通過原始碼驗證）
3.如果有自定義的rt，同時開啟後處理，unity 的 framedebugger顯示是先blit到temp，然後在blit到最開始建立的，然後在blit到framebuffer上。抓幀工具顯示的是blit到最開始建立的，然後blit到framebuffer上。兩處不同已經跟unity提了問題。等回頭有結果在更新吧。
總之 unity渲染android流程挺繞的，可能考慮了平台統一性，gpu回傳還有自定義的rt格式，大小不合規則也不能直接用來blit到framebuffer的原因吧。
所以方案3要想實用 得1.測試平台適配性。2 檢視帶來的記憶體 以及blit帶來的消耗。不過有了depth很多效果就都可以做了啊(*^▽^*)
Unity 自定義日誌儲存
using unityengine using system.io using system using system.diagnostics using debug unityengine.debug public class debugtrace return m instance endreg...
Unity 畫自定義網格
有時候需要程式化動態生成網格 例如骨骼 先3d建乙個模型，然後匯入到unity 除錯檢視mesh.vertices 的排列，用excel幾下索引。然後賦值 的時候記得按照 123456 的順序排列，因為unity就是這樣匯入的貌似，否則畫的網格不正確，最後記得重新計算下法線 這裡不需要設定矩陣 因為...
unity 日誌級別 Unity 自定義日誌儲存
using unityengine using system.io using system using system.diagnostics using debug unityengine.debug public class debugtrace private filestream files...