清源游民　 gameogre@gmail.com

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

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

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