場景管理

        場景管理是3D引擎的一個核心部分，因爲它是引擎的用戶每天都要用到的一個特性。通常的做法是通過場景圖（可能這樣稱呼不太準確）來實現，場景圖就是一個數據結構，有：層次結構（火炬在英雄的手中），空間結構（一個獸人在英雄的旁邊）以及狀態結構（火炬當中的火是alpha混合的）。
　　這樣一個結構的問題是，它試圖成爲一個萬事通，但是最後在任何一方面都沒有優勢。互聯網上已經有過許多對此的討論，一般的共識是這樣的一個超級場景圖應該被捨棄。當代的一些遊戲當中有些也根本沒有場景圖，也沒有任何表示場景的層次結構。這樣做也許對某一個類型的場合工作的很好，但是當一個引擎需要適應更多的場合來減輕其用戶的工作壓力時，擁有一個場景圖可能是你想要做的。
　　拿上面的例子來分析：英雄的手中握着火炬，當他的手移動的時候，火炬也必須跟着移動，因爲在這個層次結構中，火炬節點是手臂節點的一個子節點，因此這種跟隨移動將自動進行。全能的場景圖的問題是試圖通過一次性的解決所有問題而導致對子問題的處理不是很優秀。兩個相鄰的物體可能在場景圖中的不同分支下，因爲它們分別在兩個不同的層次結構中。還有當兩個具有相同屬性的物體需要渲染時......
　　我們來想象一下下面的場景：兩個戰士通過具有魔法的劍來進行戰鬥，這兩把劍都通過粒子效果來展現他們的魔法效果。很明顯，這兩把劍將會相互撞擊到一起去，所以會空間上會非常靠近；但是他們又是分別握在不同的英雄的手中，因此他們屬於兩個不同的層次結構（外層次結構關係），而顯示兩把劍的魔法效果的粒子效果是相同的，是通過複製實現的。
　　因此一個數據結構無法一次性解決所有的問題，而只能解決一個問題，因此自然地引導我們去爲每種不同的關係設計特定的數據結構。如果按照最近的一篇論文中介紹的，引擎使用的數據結構成爲視圖，數據成爲物體，那麼這個引擎將具有下面三個視圖：
　　場景樹：整個世界的一個層級結構視圖（用於處理層次結構的動畫）
　　空間圖：世界的一個空間視圖（用於對相鄰物體進行分組以揀選）
　　渲染圖：世界的一個最佳狀態圖（用於按照狀態對物體進行分組，例如着色器，材質等）
　　從引擎的作者的角度來說，這聽起來非常不錯：爲了不同的任務設計了不同的數據結構，每個結構都是爲了優化性能特性設計的。但是從引擎的用戶的角度來說，同時操縱這三個數據結構顯得相當笨重。
　　幸運的是，這不是用戶的負擔，因爲這一切都隱藏起來了。用戶只需要一個函數接口來操縱一棵樹：場景樹，也許用戶會收到引擎內部的一些提示和警告。當物體創建的時候，他們將會自動的插入到空間圖中渲染圖中去。還是上面的例子，兩個英雄手中的劍會在同一個節點（通過空間圖）中，並且由於它們相互接觸了，它們的層次結構的動畫也會正確展現處理（通過場景樹），而且它們會分享使用同一個特效的粒子系統（通過渲染圖）。