bvh和空間劃分技術不同,它並不是通過切割空間來管理場景中的物件。它是通過將物體分堆,然後在其上面包裹一層bv,達到管理場景的目的。樹的根節點是乙個能夠包裹全部物體的bv,而樹的葉子節點可能只是乙個物件的bv,如下圖:
bv可以選擇aabb,obb,包圍球等等,往往包裹性越好的bv,相交測試越複雜,但是包裹性好可以減少相交測試的次數。這個世界有陰就有陽,計算機的二進位製碼也是0和1,我們生存的世界是不是也是乙個虛擬的程式呢,哈哈跑題了。
父節點的包圍體無需包裹子節點的包圍體,但是需要包裹所有物體的bv。換句話說就是父節點無需包裹中間節點的bv,但要能包裹所有物體。
我們從樹根節點開始遍歷每個子節點,如果節點的bv不在視錐體中或者沒有發生碰撞,那麼這個節點下的所有物體都可以快速被剔除。
bvh和bsp有點像,太過靈活,雖然原理很簡單,但是如何建樹是乙個比較頭疼的問題。建樹困難也就意味著這個技術不適合執行時期動態更新。bvh和bsp一樣往往是在非執行時期對靜態物體進行預計算。
我們不能盲目的構建一棵bvh,先把樹的期望特徵列出來,以這些特徵為目標構建bvh。
有乙個效能測試公式揭示了碰撞效能的消耗:
t = nvcv + npcp + nucu + co
nv是相交測試bv的數量,cv是每次相交測試的消耗,np是相交測試圖元的數量,cp是每次相交測試的消耗,nu是需要更新節點的數量,cu是更新節點的消耗,co是乙個常量消耗。
我們需要尋找乙個折衷的方案來進行碰撞檢測,寫乙個物理庫不難,寫乙個高效的物理庫很難。
樹的構建策略
bvh可以自定向下構建,也可以自底向上構建,也可以插入的方式進行構建如下圖:
自頂向下構建容易,但是通常不是最佳樹。
自底向上構建複雜,但是可以獲得最佳樹。
插入構建,可以實現執行時更新,但是該方案目前研究的比較少。
具體實現細節不寫了,這個需要具體問題具體分析了。
遊戲場景測試
在拿到了正式美術資源之後,首先關心的就是場景的尋路和碰撞問題。尋路是遊戲中人可以行走的區域,碰撞是場景中得物體所佔的空間。對於這2個問題,不同的遊戲有著不同的處理方式。有的是服務端有乙份資料,客戶端生成乙份資料,然後2份資料進行對比就可以很方便的找出不一樣的地方。但是我們的遊戲不是這樣做的,美術在做...
遊戲場景管理 四叉樹
內容會持續更新,有錯誤的地方歡迎指正,謝謝 場景管理 把不同的物體歸屬到不同類別裡,而相似性的判斷是根據物體的空間相干性。把物體分類的目的 希望下次能快速找到所需的物體,所以更偏向於用四叉樹來管理我們的場景,因為四叉樹構建了這樣的乙個快速索引。四叉樹 設想乙個二維平面,我們可以先把它按田字形劃分為四...
遊戲場景管理(三)背面剔除
在圖形渲染中有乙個很大的敵人就是渲染不必要的多邊形,比如處於背面的三角麵片。拿起一本數,無論你怎麼看最多也只能看到書的三個面,有的時候只能看到書的乙個面。看不到的面我們完全可以把它剔除掉,這門武功就叫做背面剔除。如果是軟光柵化,背面剔除通常在世界空間或相機空間中做,演算法很簡單如果平面的法線和視向量...