主要是在最近工作中的一些心得體會。
後處理效果的效能問題主要在：
1.螢幕每個畫素都要進行計算。
2.可能會建立多張rendertexture的空間占用。
3.多次blit操作，比如高斯模糊多次迭代。
4.偶爾還需要新建攝像機渲染到rendertexture。
優化提公升效能的思路也比較簡單，不過要結合具體後處理的效果來分情況優化。最重要的是找到新的廉價的實現方式，不過往往由於眼界侷限，在短期內達到優化的結果很難，所以使用一些比較容易操作的tips也是一種選擇。
1.全屏計算——>quad區域性計算（針對不對螢幕所有畫素進行修改的後處理效果）
後處理需要在螢幕空間逐畫素進行計算，所以如果可以將計算的畫素數量控制在較少的範圍，則節約不少的alu。
在允許的情況下，可以使用場景中放置乙個quad來代替全屏後處理。思路是，將原來後處理的計算**轉移到quad的shader中執行，將當前攝像機rendertexture傳遞到quad的材質中，將quad的頂點通過computegrabscreenpos()計算得到螢幕空間的uv。
舉個例子，比如乙個後處理的描邊效果，如果應用比較侷限，可以在需要描邊的物件上放置乙個quad（根據需求決定是否使用billboard），將邊緣檢測的計算轉移quad的shader中進行計算。使用commandbuffer來傳遞當前攝像機的rt。不過可能需要一些額外的操作，以及需要注意commadbuffer的順序，否則會造成顯示不正常。
2.rendertexture&blit
rendertexture&blit的優化比較複雜，因為往往伴隨的演算法的優化。可以在一些對精度不敏感的效果中使用下取樣來節約空間。不過並不建議修改rendertexture的格式來節約空間，因為有部分移動裝置效果顯示不正常的情況。（對這塊有研究的可以不用care）
3.盡量不要新建攝像機渲染到rt（針對新建攝像機的攝像機設定與主攝像機相同，尺寸除外）
一些效果的實現中，採用新的攝像機渲染到rendertexture，然後將此rt用於後續渲染的方式。雖然在實現原理上，這樣做的思路比較清晰，但是在資源消耗方面，在移動平台並不適合使用。
如果新建的攝像機的視口配置與當前的主攝像機一致，那麼便可以使用這個優化方式。個人的實現方式，使用commandbuffer，建立一張臨時rt，然後將需要渲染的物件收集到乙個renderer型別的list中，然後遍歷renderer，drawrenderer到臨時rt中。這樣的話，就不需要新建乙個攝像機。
Unity引擎後處理效能優化方案解析
作者主頁 作者也是u sparkle活動參與者，uwa歡迎更多開發朋友加入u sparkle開發者計畫，這個舞台有你更精彩！目前我們專案使用的後處理外掛程式是unity technologies postprocessing。選用前，我們對比過眾多後處理外掛程式，最後根據效果和使用方便程度，結合策劃...
unity 部分obj不接受後處理
考慮了很多方案，比如渲染次序和mask stencilebuffer 渲染次序 sorting order 深度 renderer都有的屬效能開放出來，sprite renderer原本就開放在inspector裡面了 render queue 在shader裡面設定 command buffer ...
Shader 實驗02 後處理實現景深效果
景深 depth of field 是指在攝影機鏡頭或其他成像器前沿能夠取得清晰影象的成像所測定的被攝物體前後距離範圍。而景深效果是指在焦距之外的地方都是模糊的，只有焦距的地方清晰。通過取樣攝像機的深度紋理，得到當前螢幕紋理每個點的深度，使用深度值與焦距值得到每個點到焦距的距離，並使用距離來對原影象...