清源游民　 gameogre@gmail.com

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

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

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