之前在公司使用
dx9做端遊引擎，優化效能中涉及到乙個演算法，就是遮擋剔除。最經典的演算法就是使用
api中的遮擋查詢介面，
gpu gem
上面有一篇文章專門講這個。實話說，這個演算法看過好幾次，直到今天都沒有徹底明白。後來看到有的人評價說這個演算法不一定能改進效能，甚至還會導致更低。看到這個我有點底氣徹底放棄了，是的，我一直有個觀點，就是越簡單越好，一旦某個東西很複雜，我就會警惕起來，就會懷疑設計有問題。當然聽說
dx11
下面這個遮擋剔除的介面很好用，有機會可以試一下。
後來讓乙個同事去研究了下
ce3裡面的遮擋剔除演算法。
ce3裡面使用了軟體光柵化的方法，大致流程就是，在編輯器中放置一些正交的長方體作為遮擋體，在渲染時，每幀都在
cpu上面光柵化這些遮擋體（當然是在解析度比較小的渲染目標上進行），然後對遠處物體進行查詢。不過這個同事在我們自己的引擎上實驗過後得出的結論是，反而會拉低幀率。我的判斷是他沒有使用好
sse指令，
ce3這種引擎絕不會做沒有名頭的事。
既然這個不能用（肯定是我們自己的原因），那就自己創新演算法吧。受
ce3演算法的啟發，我就想，何不將光柵化的操作放到
gpu上呢。要知道，
gpu幹這種「粗活」比
cpu好上千百倍。我就想到有乙個東西可以直接拿來用，都不增加額外的開銷，那就是
pre-z
的結果。具體做法就是將上一幀的
pre-z
結果在gpu
裡面降取樣，然後拷貝到
cpu，使用這個結果進行查詢。
當然，原理很簡單，實際中遇到的技術細節還真不少。首先，由於是使用的上一幀的深度值，那麼在鏡頭快速旋轉時，該出現的物體沒有出現。還有個問題，物體的包圍盒在螢幕上占有一定面積，如果每個畫素都檢查就太耗效能了，檢查幾個關鍵點就行了，可問題又出現了，位於移動物體後面的物體會有時出現有時消失。經過不斷改進，總算都解決了。在很多場景中，尤其是主城內，這個演算法極大提公升了速度。
在實現中，
演算法細節還有不少。不過只要方向對了，剩下的就是用時間來磨細節了。
Unity中的優化 遮擋剔除
遮擋剔除 當乙個物體被其他物體遮擋住而不再攝像機的可視範圍內時部隊其進行渲染 在檢視面板，你需要標識所有需要應用遮擋剔除的場景物體，最快的方法時選擇多個想要遮擋剔除計算的物體，然後標記它們為occludee static和occlusion static 乙個普通物體可以設定這裡兩個狀態 地形不能 ...
關於最短路的幾個演算法
關於最短路的幾個演算法有dijkstra，bellman ford，floyd dijkstra dijkstra適用於邊權為正的情況，從單個源點出發，到其他所有結點的最短路 演算法的核心是用已經知道的結點 i 的距離 d i 去更新和這個結點相連的其他結點的距離 struct node struc...
關於結構體指標以及 和 區別的幾個嘗試
1 指標是否需要分配到空間問題 定義如下結構體以及指標，change並未指向任何結構體 struct student struct student class1 2 struct student tem class1,max tem 1,min max 1,change 經過賦值比較之後，交換max...