這段時間一直都在忙著寫CoagelEngine，沒時間上來更新。花了一個月的時間，現在基本把渲染器的框架寫好了。渲染器是用Visitor模式實現的。同時API無關，理論上來說同樣可以支持Directx，不過我沒用過DX，現在只實作了GLRender。通過在場景的主節點Root（唯一）上調用Root->accept（GLRender*），就可以自動的渲染整個場景，GLRender會遍歷整個場景圖，智能的判斷需要渲染的物體是什么類型，比如是Camera，TriMesh，TriStrip，BSpline等等。

場景中的每個節點都可能在程序運行時刻改變，比如Camera會相應鍵盤和鼠標來改變當前的視點，地形和復雜幾何體會根據視點不同改變Lod等級，粒子系統會根據時間改變，骨骼動畫等等，為了實現對這種功能的支持，我開始的設計是在每個節點上維護一個CallBack的鏈表（也可以是vector），當Render訪問到這個節點的時候，先執行CallBack，然后再往下遍歷，或者是渲染當前節點。但是后來在實作紋理調度機制時發現這種方法有會使程序的結構變得很混亂，最后確定用另外一個Visitor來實現兩次遍歷。也就是說，先用一個UpdataVisitor來遍歷場景圖，改變所有的節點，然后再用RenderVisitor來渲染。這種方法可以提供更優雅的程序結構，但是會有一定的性能損失。不過通過對整個場景圖的良好的組織和限制，這種損失可以被限制在一個可接受的范圍。

紋理調度策略：我希望能實作出比較合理的紋理調度策略，并且這種策略也可以用到其它的數據調度上。目前的設計是這樣的。有一個texture Class來管理紋理，然后用一個textureGroup來管理多個texture class。當我要把1 個或多個紋理附給一個物體時，我就把一個texture group傳給這個物體。但是這個時候，系統并沒有初試化這些紋理，也就是說，紋理還在系統內存中，而不在顯存中。只有當一個物體
確實需要被渲染時，才將它帶的紋理傳到顯存中。當這個物體被從場景圖中刪除時，textureGroup也被刪除。本來最初的計劃是每個texture class只能屬于一個特定的texture group。但是這樣就不能實現不同
texturegroup中texture的共享。比如場景中的一面墻和很遠處的另一面墻具有同樣的外觀，如果不能共享紋理，就會造成同樣的紋理需要被創建兩次，浪費了系統時間和顯存。因此用smartPoint來管理texture class是一個更合理的選擇。只有當所有需要這個texture class的group都被刪除時，這個texture才被刪除。

轉載于:https://www.cnblogs.com/badkeeper/articles/167868.html

總結

以上是生活随笔為你收集整理的好长时间没更新了的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。