清源游民　 gameogre@gmail.com

設計哲學
傳統上，使用 Direct3D 或 OpenGL 來渲染場景和對象，需要遵循一系列程序處理流的步驟：調用 API 設置渲染狀態，調用 API 發送幾何體信息，通知 API 或 GPU 去渲染幾何體。對每個幾何體都是如此返復，直到當前幀被完全渲染。在一下幀同樣如此。
使用面向對象的方法來渲染幾何體簡化了上述過程。通過處理組成場景的各種對象而不是原始的幾何體。這些對象包括：可運動對象，靜態對象（構成世界布局），光，相機等。那些 3D API 則不再需要：只是把這些對象放到場景中， Ogre 負責處理瑣碎的細節。而且，可以用更加直觀的方法來操縱對象，而不是使用矩陣。總的說來，我們可以處理對象，它的屬性，調用更直觀的方法，而不再用頂點列表，三角形列表，旋轉矩陣等手段來管理了。
Ogre 提供了面向對象的框架，包括了對象模型中的渲染處理的所有部分。渲染系統抽象了底層 3D 　 API 的復雜性。場景圖形功能被抽象成單獨的接口，這樣一來，各種不同的場景圖形管理算法可以即插即用。在場景中的所有可渲染對象，無論是可移動的，還是靜態的，都被一組公共接口抽象，這些接口提供了實際的渲染操作（例如 techniques 和它所包含的 passes ） .
設計亮點
一“設計模式”的合理使用
Ogre 中大量使用了經典的設計模式。例如，使用“ Observer ”模式來通知應用程序特定事件的發生，在 demo 中 FrameListener 的使用使得程序可以接收　 frame-started and frame-ended 　事件通知。“ Singleton ”模式強制實現類的單實例。“ Iterator ”模式用來遍歷數據結構的內容。
“Visitor” 模式用來在對象上執行某種操作。 Fa?ade 模式用來抽象底層，提供一個單一類接口。
“ Factory” 　用來創建實例。
二 場景圖與內容分離
傳統上，場景圖與內容同處于同一繼承體系下。它要求從場景結點子類化內容類，也就是說內容類從場景結點繼承。實踐證明這種設計非常糟糕。 首先， Ogre 操作場景圖形在接口層 , 它不假設特定圖形算法的實現。實際上， Ogre 操作場景圖形僅僅通過它的簽名（方法），完全忽略底層的算法實現。
第二， Ogre 的圖形接口只關心圖形結構，不包含任何內在的訪問或管理功能。后者被推到 Renderable 中，場景中的所有幾何（ movable or otherwise ）都從它繼承。這些 Renderalbes 的渲染屬性（材質， materials ）被包含到 Entity 對象中去。 Entity 可以包含一個或多個 SubEntity 。這些子實體是實際的可渲染對象。下面是各對象的一個關系圖：

通過這樣的設計，場景管理與場景內容充分解藕。過于場景圖來說，通過 Movable Object 幾何，渲染屬性變得有效。注意到 Movable 不是從 Scene Node 繼承而來的。 Movable Object 是 attached 到 Scene Node 上去的 . 當擴展，改變，重構場景圖形實現時對場景內容對象的設計與實現沒有任何影響。
從另一方面來說，由于場景圖形不需要知道內容類的任何變化。只要實現一些簡單的場景圖形“確實“需要知道的一些接口。因此，我們可以任意的 attached 一些自定義的東西到場景結點上，比如聲音信息等。（聽說有個 OgreAL, 它包裝了 OepnAL ，猜想就是這樣做的吧）。
三　插件結構
OGRe 被設計成可擴展的。 Ogre 通過“基于契約的設計 ” 來完成。 Ogre 可以被設計成一組共同工作的組件，它們通過一些已知接口來相互交流。這帶來極大的靈活性，某種功能的不同實現與改變非常容易。舉例來講，由于 ogre 處理場景圖元管理是在接口級，用戶可以隨意的選擇特定算法的實現。而且，當用戶創建一個新的實現，可以很容易的以插件的形式提供給 Ogre, 　實現時只要遵循 ogre 定義的一些接口 . File archives , render systems 也以插件的形式提供，粒子系統也是。 插件形式的吸引人之處是，為了加入插件，不需要重新編譯 Ogre 庫 . 插件可以在運行時加載。
四　硬件加速的渲染支持
Ogre 被設計成只支持硬件加速圖形渲染，直接軟件渲染不是它的選項。 Ogre 使用完整的硬件加速能力，包括可編程 shaders 。 Unreal 引擎能做什么， Ogre 就能做什么！！（ ^_^, 作者說的）。引擎直接支持的全局光照 (precomputed Radiance Transfer 等 ) 還沒有實現，因為這些多數用于非實時計算場合，因此不是什么問題 .Ogre 現在和未來將可能只使用 Direct3D 與 OpenGL 。
五，靈活的渲染隊列結構
Ogre 　采取一個新方法來解決場景中各部分渲染次序問題。粗略地看，標準過程通常如下工作：渲染地形或世界幾何，渲染可移動對象，渲染各種特效，渲染 OverLay, 渲染背景或天空盒 . 然而，正如典型的實現一樣（像集成電路處理模塊），這個過程很難改變 . 在許多例子中， 很難改變渲染的順序，導致難以維護與不靈活的設計的。 渲染隊列的概念是： Ogre 以一次一個的方式渲染一組可以排序的隊列，也已同樣的方式渲染每個隊列中的內容。也就是隊列本身有優先級，同樣隊列中的對象也有自己的優先級。

上圖中，隊列由后向前渲染（ Background à OveryLay ） , 在最前的隊列中從左至右渲染。
在這種機制下重新組織渲染順序非常簡單，只要重新分配優先級就可以了。隊列可以定制，隊列中的對象也可以。整個隊列可以“ turned on” and “turned off” ，隊列中的對象也可以。 每個隊列提供了事件通知（如 prerender and postrender ） , 應用程序有機會改變隊列中的對象渲染。這個機制對于開發和維護復雜程序都相當有用。
六　健壯的材質系統
Ogre 的材質由一個或多個 technique 組成， technique 是 pass 的集合。 Pass 是材質級別的渲染單元，導致一次圖形硬件的 ”draw” 調用。可以有多個 pass, 每個 pass 是一次全新的渲染操作，包括硬件渲染狀態改變。
最吸引人的特性是 automatic fallback 。 Ogre 自上向下地（ technique 列出的順序）尋找最適當的 technique.Ogre 還能盡力地重新組織 technique 中的 pass, 以迎合最小的技術需求。例如，當前硬件只支持單紋理單元，而你程序中最小復雜度的技術，需要至少兩個紋理單元，那么 ogre 會把一個 pass 拆分成兩個，通過混合兩個單元紋理的方式達到同樣的效果。
Ogre 材質系統也支持 schemes 的概念。 Schemes 可以理解作為普遍的“非常高，高，中，低“不同等級的圖形設置。在這種情況下，可以定義四個 schemes , 并為每一個分配 techniques( 復數 ) 。這樣就可以 ogre 的所謂 technique fallback 查找那些屬于特定 schemes 的 techniques 。使得材質管理更容易點。
用材質腳本完成的事，同樣也可以用代碼的方式完成。代碼的方式也支持 schemes 與 technique fallback 。
七　本地優化的幾何與骨骼格式
Ogre 使用它單獨的 mesh 與骨骼格式。不能直接加載第三軟件包生成的數據。社區中有轉換第三文件格式的工具，但它不是 Ogre 庫的一部分。 Ogre 使用自己的格式是為了效率。
八　　多種類型的動畫
Ogre 支持三種類型的動畫：骨骼動畫，變形動畫， Pose 動畫
骨骼動畫，把頂點綁定到骨骼上。對象的每個頂點可以受到四個獨立的骨頭影響。每種影響被賦于一個用數量表示的權重。骨骼動畫只在關鍵幀上執行前向運動學模式。 Ogre 當前不支持逆向動畫 .
Morph 動畫是一種頂點動畫技術，他儲存關鍵幀上的絕對的頂點位置信息，在運行時在兩個關鍵幀之間插值。這與 Pose 動畫不同， Pose 動畫存儲的是偏移數據而不是絕對位置。 Pose 動畫可以混合以形成復雜動畫。 Morph 動畫比 Pose 動畫功能有限，因為他存儲的是絕對值，因此難以與其他 Morph 動畫混合。 Morph 動畫與 Pose 動畫之間也不能混合 .
所有的動畫類型都可以與骨骼動畫混合使用 .
所有動畫類型都可使用軟件執行或是利用 GPU 硬件執行。
Ogre 動畫是基于關鍵幀的，內插方式有線性與立方樣條這兩種選擇。
九　 Compositor Postprocessing ( 怎么翻譯 ~?)
用來在一個視口中創建二維的，全屏的后處理效果 . 例如模糊，黑白電視，等等效果（ Ogre 有個很好的示例） Compositor 也有類似于材質系統的 technique 與 pass 的概念。在視口最終被輸出前，多個計算與渲染可被執行。像材質的 fallbacks,Compositor framework 提供了 fallback 處理，例如，當輸出的像素格式無效時。理解 compositor 最容易的方法是把它當成片段程序（像素渲染）的擴展。不同之處在于：傳統的圖形管線每個材質 pass 只充許一個片段程序，而 Compositor framework 則可以像打乒乓球一樣來來回回好多次。 Compositor 腳本掃行在 ViewPort 上，因此它可以面向任何的 render target, 可以是可渲染紋理，主，副渲染窗口。與材質系統一樣，它除了利用腳本實現，也可以使用代碼實現。
十?? 擴展資源管理
在 ogre 中，資源定義為：渲染幾何體到可渲染目標上用到任何東西。很明顯包括： mesh, 　 skeleton, material , overlay script , font , Compositor script, GPU program , texture 。
每種資源都有自己的 manager, 它主要負責控制特定類型資源在內存中的占用數量。換句話說，它控制著資源實例的生命期。不過僅僅在一點上控制：首先，它只能儲存同樣多的實例，取決于這種類型的資源所分配的內存。第二， ogre 不會刪除正被其他部分引用的實例。
資源本身實際負責加載自己。這是資源系統的一個設計特性：手工資源加載。手工加載意味著資源加載，處理，是利用一個方法調用實現的而不是從文件系統中隱式地加載。
資源在 ogre 中有四種狀態：未定義，　聲明，未加載，　加載。
未定義，說明 ogre 對它一無所知。
聲明，它已經在檔案中進行了索引。
未加載，已經進行了初始化（腳本，已經被解析過了），引用已經被創建
加載，已經在它的資源 manager 所管理的內存池中占用空間了。
可以用“組”來管理管理各類資源。組中資源之間的關系是任意的，完全取決于程序員：創建 GUI 的所有資源可以分為一組，以 A 字母開頭的資源也可以分為一組，等等。有個 缺省的組：General
在 ogre 中查找某個資源實例時，不會考慮，資源所在的組。有時，我們可以將資源組命當成某種的 ” 命名空間來用“。
Archives 中的資源是非手動加載的。 Archives 是普通文件容器的簡單抽象。它包括文件系統與 ZIP 檔案。用戶可以實現自定義類型的 archive 。