關於 OGRE 與 OSG 的簡單比較
1 前言
我曾經細致閱讀過 OGRE 和 OSG 官方提供的文檔，有《Pro OGRE 3D Programming》、OGRE自帶手冊（manual）、王銳老師等翻譯的《OpenSceneGraph Quick Guide》，同時在網絡上查閱了大量的 OGRE 架構源碼分析的文章。簡單使用過 OSG，對 OSG 的場景管理器設計和編程風格有所了解，而在近期的項目中大量使用 OGRE，相對於 OSG，對 OGRE 的認識比較深刻一些。目前 OGRE 的最新版本是 1.7，OSG 的最新版本是 2.9.7。
本文是對 OGRE 和 OSG 這兩大三維圖形繪制引擎的一個不全面的個人比較，主要簡單介紹它們在運行效率、平台支持、資源管理、場景樹管理、功能支持、可擴展性、易用性和相關支持方面的異同，而不是評論誰優誰劣（當然本人也沒這資歷），通過了解差異后，根
據不同項目要求做出不同選擇。
因為本人使用這兩個繪制引擎的時間不長、運用的功能特性也不全，所以有些比較結論可能不合理，歡迎指正，通過交流，共同進步。
2 繪制引擎簡介
2.1 OGRE
OGRE 是 Object-Oriented Graphics Rendering Engine（面向對象的圖形繪制引擎）的簡稱，是一個用 C++開發的面向對象且使用靈活的 3D 引擎，是一個被廣泛使用的開源三維圖形渲染庫。它成功地被應用於諸多三維仿真領域，其中包括網絡游戲和一些商業的三維仿真項目。
它的目的是讓開發者能更方便和直接地開發基於 3D 硬件設備的應用程序或游戲。引擎中的類庫對更底層的系統庫（如：Direct3D 和 OpenGL）的全部使用細節進行了抽象，並提供了基於現實世界對象的接口和其它類。OGRE 的主要特性有：
效率特性
簡單、易用的面向對象接口設計使你能更容易地渲染 3D 場景，並使你的實現產品獨立於渲染 API（如 Direct3D、OpenGL、Glide 等等）。
可擴展的程序框架（framework）使你能更快的編寫出更好的程序。
為了節省你的寶貴時間，OGRE 會自動處理常見的需求，如渲染狀態管理，空間裁剪，半透物體排序等等。
清晰、整潔的設計加上全面的文檔支持。
在很多商業產品（特別是電子游戲）上得到應用，並被證實是一個穩定的引擎。
平台和 3D API 支持
支持 Direct3D 和 OpenGL。
多平台支持，支持 Windows（所有版本）、Linux 和 Mac OSX。
在 Windows 平台上可以使用 Visual C++或 Code::Blocks 編譯。
在 Linux 平台和 Mac OSX 平台（使用 XCode）上可以使用 gcc 3+編譯。
材質、Shader 支持
強大的材質聲明語言使你可以在代碼之外維護材質資源。
支持頂點和像素着色器（Shader），同時支持低級的匯編着色器和高級的着色器，如Cg、D3D 中的 HLSL 和 GLSL，並為許多常用的常量提供自動的綁定的，如世界視點矩陣、光照狀態、視點世界坐標等。
支持固定渲染管線的全部功能，如多紋理、多遍繪制融合、紋理坐標生成和修改、為低端的不可編程顯卡提供獨立的顏色融合操作。
支持多個材質技術，你可以設計不同顯卡配置的不同技術，OGRE 自動選擇最佳的技術。
支持材質的 LOD；你的材質可以在它們遠離視點時減少資源消耗。
支持從 PNG、JPEG、TGA、BMP 或 DDS 等文件中加載紋理；支持不常見的 1D 紋理、立體紋理、立體盒紋理和壓縮紋理（DXT、S3TC）。
可以通過插件實時提供及更新紋理，如從視頻上。
支持透射紋理映射（Projective Texturing）。
網格 Meshes
靈活的網格數據格式支持，獨立於頂點緩存、序號緩存、頂點聲明和緩存映射。
支持漸進的網格 LOD，可以自動或手動生成。
支持用 Bézier 樣條實現的曲面。
靜態幾何分批繪制。
動畫
支持復雜的骨骼動畫
靈活的形狀動畫支持
支持場景節點動畫，並提供樣條插值
普通動畫路徑支持可插入的物體適配器（不是很清楚，詳見官網說明）
場景特性
擁有高效率和高度可配置性的場景管理器，並且支持多種場景類型。使用系統默認的場
景組織方法，或通過親自編寫插件使用自己的場景組織方法。
提供的 BspSceneManager 插件是快速的室內渲染器，它支持加載 Quake3 關卡和 shader腳本分析。
多等級的場景組織體系；場景結點支持物體的附屬（attach），並帶動附屬物體一起運動，實現了類似於關節的運動繼承體系。
特效
粒子系統包括可以通過編寫插件來擴展的粒子發射器（emitter）和粒子特效影響器（affector）。通過腳本語言可以不用重新編譯就設置和更改粒子屬性。支持並自動管理粒子池，從而提升粒子系統 的性能。
支持天空盒、天空面和天空圓頂，使用非常簡單。
支持公告板，以實現特效。
自動管理透明物體（系統自動幫你設置渲染順序和深度緩沖）
其它特性
資源管理和文檔加載（ZIP、PK3）。
支持高效的插件體系結構，它允許你不重新編譯就擴展引擎的功能。
運用“Controllers”你可以方便地改變一個數值。例如通過生命值動態改變一個飛船的防護罩的顏色值。
支持內存泄露檢測的內存調試管理器
通過 ReferenceAppLayer 例程了解如何讓 OGRE 與其它庫協同工作，如做碰撞可信度的ODE 庫。
可以用 XMLConverter 讓二進制格式文件與 XML 相互轉換，方便交流和編輯。
2.2 OSG
OSG 是 OpenSceneGraph 的簡稱，是一個開放源碼、跨平台的圖形開發包。它為諸如飛行器仿真，游戲，虛擬現實，科學計算可視化這樣的高性能圖形應用程序開發而設計。它基於場景圖的 概念，它提供一個在 OpenGL 之上的面向對象的框架，從而能把開發者從實現和
優化底層圖形的調用中解脫出來，並且它為圖形應用程序的快速開發提供很多附加的實用工具。
它完全是由標准 C++程序和 OpenGL 寫的，充分利用 STL 和設計模式，發揮開源開發模型的優勢來提供一個免費的開發庫，並且重點集中在用戶的需求上。隨着使用一個全特性的場景圖 OpenSceneGraph 的關鍵優勢在於它的性能、可擴展性、可移植性和快速開發
（productivity），更具體的來說：
性能
支持視圖投影剔除（view frustum culling）、隱藏面剔除（occlusion culling）、小特性剔除（small feature culling）、細節層次節點（LOD）、OpenGL 狀態排序（state sorting）、頂點數組、頂點緩沖對象（vertex buffer objects）、OpenGL 着色語言和把顯示列表（display lists）作為場景圖內核的一部分。它們共同使 OpenSceneGraph 成為一個高性能的圖形庫。OpenSceneGraph
也支持繪制流程（drawing process）的定制，比如場景圖的連續細節層次（CLOD）的網格（參見虛擬地形項目和 Delta3D）。
快速開發
場景圖的內核封裝了包括最新擴展的大部分 OpenGL 功能，提供諸如剔除和排序的渲染優化功能，同樣提供能快速開發高性能圖形應用程序的一整套補充庫。應用程序開發者可以更關心實質性內容和如何操控這些它 們，而不再是底層的代碼通過學習已有的場景圖，比如：Performer 和 Open Inventor，把它們同像設計模式這樣現代軟件工程理念聯合起來，加上早期開發周期中的大量反饋信息，設計一個清晰的可擴展的庫已經成為可能。用戶可 以很簡單的適應 OpenSceneGraph 並且把它集成到自己的應用程序中
數據裝載
為了讀入和寫出數據庫，數據庫支持庫（osgDB）支持動態的插件機制，從而支持大量數據格式，目前的發布版本有 55 種單獨的插件支持 3D 數據和圖像格式的裝載。
支持的 3D 數據格式包括 COLLADA、LightWave (.lwo)、Alias Wavefront (.obj)、OpenFlight (.flt)，多線程頁面調度支持的 TerraPage (.txp)、Carbon Graphics GEO (.geo)、3D Studio MAX (.3ds)、Peformer (.pfb)、AutoCAd (.dxf)、Quake Character Models (.md2)、Direct X (.x)和 Inventor Ascii 2.0 (.iv)/ VRML 1.0 (.wrl)、Designer Workshop (.dw)、AC3D (.ac) 和自帶的.osg ASCII 文本格式。
支持的圖像格式包 括.rgb、.gif、.jpg、.png、.tiff、.pic、.bmp、.dds (包含壓縮的一系列Mip 貼圖影像)、.tga 和 quicktime (在 OSX 環境下)，全范圍的高質量、抗鋸齒字體也能通過freetype 插件支持，基於字體的圖像也可以通過.txf 插件支持。
用戶也可以通過與一個同盟項目（VirtualPlanetBuilder）生成大規模地形空間數據（multi GB），使 用 OpenSceneGraph 的自帶數據分頁調度支持來查看這些數據。
節點工具箱
這個場景圖同樣有一套節點工具集，它們是可以在你的應用程序中編譯或者在運行時裝載的獨立庫：
osgParticle——粒子系統
osgText——高質量抗鋸齒文本
osgFX——特效框架結構
osgShadow——陰影框架結構
osgManipulator——交互控制
osgSim——虛擬仿真相關的效果
osgTerrain——地形繪制
osgAnimation——動畫
osgVolume——體繪制（通過 Dicom 插件支持醫學數據）
可移植性
場景圖的內核已經被設計成盡量少的依賴具體的平台，很少的部分 超出了標准 C++程序和 OpenGL。這就使得這個場景圖可以快速移植到大部分系統中——最開始在 IRIX 開發，然后移植到 Linux，接着 到 Windows，再后來就是 FreeBSD， Mac OSX，Solaris，HP-UX， AIX 甚至是 PlayStation2！
完全獨立與窗口操作系統的場景圖內核庫使得用戶在它上面可以增 加他們自己的指定窗口庫和應用程序，在發布版本中 osgViewer 庫提供自帶窗口支持，可支持 Windows (Win32)，Unix (X11) 和 OSX (Carbon)。osgViewer 庫也可以輕松的和你的窗口開發包集成起來，作為OpenSceneGraph-2.0 發布版本的一部分，有例子演示了如何在 Qt, GLUT, FLTK, SDL, WxWidget, Cocoa and MFC 中的使用。
可伸縮性
場景圖內核的可擴展性使得它不僅僅可運行在便攜式設備，甚至高 端的多核、多 GPU的系統和集群上。這可能是因為場景圖內核為 OpenGL 的顯示列表和紋理對象支持多重圖形渲染環境（multiple graphics contexts），剔除和繪制的遍歷過程被設計成隱藏渲染數據為局部變量，這樣可以以幾乎只讀的方式使用場景圖內核。這樣就允許多對剔除—繪制過程運 行在多個 CPU 上，CPU 則是綁定在多個圖形子系統之上。對多圖形設備渲染環境和多線程的支持可以在 osgViewer 中方便使用，發布版本中所有的例子都可以以多線程和多 GPU 的方式運行。
多語言支持
OpenSceneGraph 以社區項目的形式支持多種語言，比如 Java，Lua 和 Python。
3 OGRE 與 OSG 的異同
通過上一節的簡介可以大致了解到這兩大 3D 繪制引擎的功能特性，同時也容易察覺到兩者的異同。下面就兩者的具體說明：
設計和體系
如果你曾經使用傳統而基本的方法進行過 3D 應用程序開發（換句話說，就是有使用OpenGL 或者 Direct3D 這種底層 API 的經驗），你會了解到它們有一些相似而且繁瑣的過程：
通過調用 API 設置渲染狀態；通過調用 API 傳送幾何體信息；通過調用 API 通知 GPU 渲染；清理；返回到第一步，直到渲染完一幀進入下一幀。這個過程會讓你陷入紛雜的 API 操作之中，相對於真正的應用，可能你會被浪費在基本的幾何體操作中去。如果使用面向對象的方法來渲染幾何體，就可以從幾何體級別的處理工作中抽離出來，轉 而處理具體的場景和在場景中的物體。其中的物體包括：可活動的物體、靜態物體組成的場景本身、燈光、攝像機以及其他。你只需簡單的把物體放到場景之 中，OGRE 或 OSG 繪制引擎可以幫助你完成雜亂的幾何渲染處理。也是為什么我們在開發 3D 應用程序時不直接使用 OpenGL 或 D3D 的原因。
OGRE 和 OSG 在架構設計上存在着許多共同之處，都是為了兼顧系統的高效性、可移植性和可擴展性，采用了以下設計理念和工具進行系統的設計和構建：
ANSI 標准 C++
C++標准模板庫（STL）
設計模式（Design patterns， Gamma95）
通過設計模式的一些模式如 Abstract Factory、Listener、Adopter、Singleton 等，提高程序庫的擴展性並易於與其它庫協同工作。如 OSG 和 OGRE 庫都有大量的功能強大插件支持，並可以同第三方界面庫（如 Qt、MFC、WxWidget 等）分工合作。
但兩者也存在着一些明顯的不同之處。OGRE 從它的命名上可以直接看出，它是一個面向對象的三維繪制引擎。相比 OpenGL 和 D3D 的顯明帶有面向過程特征的 API，經過抽象的面向對象 API 更簡明，使用更方便。而 OSG 是在 OpenGL 基礎上提供了很多使用方便的功能包，並沒有對底層圖形接口（OpenGL）進行抽象。下面《Pro OGRE 3D Programming》中關於面向對象的優勢所在的論述：
嗯，現在的圖形引擎就像任何龐大的軟件系統。在一開始很苗條， 但很快變成驚人復雜的怪獸，讓人難以理解它。這樣大的系統難於管理，任何對系統的修改都可能影響其可靠性。而在這樣一個不斷出現新技術和手段的領域，修改 又是必不可少。大量的使用 c 函數調用也無法對這一情況有任何改善 —— 即使所有的函數都是同一個人寫的。通常會發現，幾個月以后，一小段代碼也會變得復雜難懂；該如何組織這些函數也會變成一個難題。
面對對象是解決復雜性問題的一個常用手段。它逐步的把代碼分解 到函數中，把函數和表示狀態的數據用類組織起來，以表示現實中的各種概念。它能讓你把復雜性隱藏在容易確定的代碼包當中，只暴露出簡單易用的接口。這樣你 就有了可以搭建在一起的“建築材料”。你也可以通過組織這些材料使它們有一致的外部接口，而在內部，實現這些接口的方法卻各不相同。這同樣減少了復雜性， 因為開發者只需要學習一種接口。
同時，OGRE 只專注於繪制，不負責其它模塊，如用戶界面、聲音、網絡、碰撞檢測等，其它模塊都是以插件的形式存在。而 OSG 提供了更多的功能，如前者所沒有的功能，如虛擬仿真、體繪制、分頁地形加載（最新 OGRE1.7 也引入了部分相關功能）等。所以如果是要利用現有成熟模塊的項目可以使用 OSG，而需要開發更成熟更商業化的產品可以使用OGRE。
平台支持
從前面的特性分析可以看出，OGRE 與 OSG 對平台的支持的側重點有所不同，如 OGRE側重於成熟的商業化的平台，如 D3D 及主流圖形操作系統，從而可以。而 OSG 強調支持多個操作系統，如 FreeBSD、Solaris、HP-UX、AIX 等，只要是支持 OpenGL 的平台，OSG 就有可能支持。由於大部分游戲及商業軟件是基於 D3D 的，而 OGRE 對 D3D 提供了很好的支持，所以如果是開始游戲，OGRE 是一個很好的選擇。
資源管理
不管地形、紋理還是字體等一切對象，繪制它們都需要不同的資 源。如何加載、重用、卸載這些資源是非常重要的，因此，有專門的一批類來完成這些事情。OGRE 提供了一個功能完美的資源管理系統，包括對材質、Shader、粒子系統等一系列資源的分離於代碼外的管理。OGRE 定義了功能強大的材質聲明文件，可以在文件中直接定義紋理、繪制狀態、Shader等信息，從 OGRE1.6 起還支持簡單的變量和聲明繼承等，極大的方便了資源管理工作，更代碼思路更清晰。
在圖形引擎中，有大量的狀態管理和上下文相關操作的代碼。封裝 能把這些代碼放在獨立的資源聲明文件中，這樣以來代碼就更容易理解。而且由於封裝避免了復制代碼方式的重用，也使得程序變得更可靠。且這些資源聲明文件也 是獨立於平台的，這是 OGRE 作為一個成熟的 3D 繪制引擎的一個重大特性。
場景樹管理
OGRE 與 OSG 都有一個場景樹在管理整個場景的相關信息，通過場景樹可以方便的管理場景物體，並且在向底層接口提交繪制操作前進行一些軟裁剪和繪制順序調整工作。同時OGRE 與 OSG 的場景樹上每個節點所代表的內容是不同的。
首先，Ogre 對場景圖的操作維持在接口級別；它並不關心去操作圖形的具體算法實現。換言之，Ogre 只是通過 API 來操作場景圖，進而忽略了具體的算法實現。其次，Ogre 的場景圖接口只負責維護場景結構。節點中沒有包含任何固有的內容和管理方法。具體的內容被
放置到一種可渲染（Renderable）對象之中，它提供了場景中全部幾何圖形（包括活動的的或者其他所有的）。它們的渲染的屬性（也可以說是材 質）被包含在實體（Entity）對象中，在實體對象里面同樣包含着一個或多個子實體（SubEntity）對象，這些子實體才是是真正可
以被渲染對象。
場景圖形樹結構的頂部是一個根節點。從根節點向下延伸，各個組節點中均包含了幾何信息和用於控制其外觀的渲染狀態信息。
ORGE《Pro OGRE 3D Programming》中提到：
雖然沒有得到權威的論證，但我還是堅信場景圖和場景內容的分離的設計一定是整個Ogre 項目中最亮眼的地方。雖然看起來它是一個如此的簡單易懂，不過對於那些仍然堅守“傳統的設計方法”來完成場景圖設計的人仍然會難以理解。
在傳統設計中（就是很多商業和開源 3D 引擎所采用的）將場景內容和場景結構放到一個繼承體系中，並將場景內容生硬的作為場景節點的子類。我斷言這是一個極其失敗的設計方案。如果不修改所有的子 類，基本上是沒有辦法更改或者擴充圖形算法的，因此讓修改基類的接口非常困難，進而導致以后的維護工作變得舉步維艱。此外這種“所有節點源自同一節點類 型”的設計思想會讓整個程序變得凝固且難以復用（至少從維護的觀點看）：
當增加新的基類功能方法或者屬性的時候，不管是否真的需要，這些都強迫的塞入所有子類。最后導致哪怕是對基本功能做很小的修改，都會牽一發會動全身, 導致開發維護最終變得難與控制。這種糟糕的設計理念讓陷入的人們痛苦不堪，從而希望擺脫這種邏輯采用全
新的設計方法。
可以看出 OGRE 是出於可維護性和可擴展性才選擇這種場景樹管理方式的。配合 OGRE強大的代碼資源分離功能，及可擴展的多場景管理器支持能力，這種簡明的場景樹管理設計取得了重大成功。
易用性
為了使代碼可以支持 D3D 和 OpenGL 引擎，OGRE 編程中不推薦直接使用 D3D 或 OpenGL的 API，且繪制流水線與底層的 API 有一定區別，這就提高了入門難度，加大了學習曲線的陡峭程度。而OSG 只是基於OpenGL 單個底層API 的，所以可以直接在OSG 工程中加入 OpenGL的 API 調用，且一般情況下只也是唯一方案，如要使用 OSG 所沒包括的新的 OpenGL 擴展。
從這點來看 OSG 比較適合要用到新的顯卡技術的項目，而 OGRE 比較適合技術通用、成熟且要求使用更適合游戲的 D3D 引擎的項目。如前面提到的 OGRE 有一個強大的、功能齊全的資源管理器，可以大大減輕資源管理復雜度，提高資源加載、分配和利用效率。這有助於把美工、效果與代碼分離，使編程時邏輯更清 晰。這是程序設計的一個主流方向，如 Nokia的 Qt 用戶界面庫就是一直朝這個方向發展的。
相關支持
OGRE 與 OSG 在對一些資源和功能的支持上也存在這差異，如 OGRE 沒有提供像 OSG 那樣廣泛的 Mesh 文件格式支持。其實 OGRE 只支持自身特有的.mesh 文件支持，而其它模型只能通過轉換到這種格式才可以載入。同時 OGRE 也沒有提供輸入輸出相關支持，需要通過獨立模塊 OIS（Object Oriented Input System）來支持輸入輸出操作。總的來說，OGRE 專注於 3D 繪制，而 3D 應用程序所需要的其它功能可以由插件或其它庫完成。相對而言，OSG提供的支持會多些，如體繪制（osgVolume）、仿真模擬（osgSim）、聲音 支持（osgAL）等模塊。
4 小結
本文簡單介紹了一些 OGRE 與 OSG 的一些特性及之間的功能對比，在簡化 3D 圖形編程在設計理念下，兩者又保持着自己獨特的設計路線。OGRE 的特色在於成熟的設計模式、出色的資源管理方式和良多的跨平台性（特別是支持 D3D）；OSG 的特色在於豐富的相關開源項目和文檔、很多現成的功能模塊。
同是開源項目，OSG 由一個超過 200 人的大規模開發隊伍，而 OGRE 卻擁有一個精小強悍的開發團隊（現在共 7 人）。OGRE 相對而言比較活躍，功能更新頻繁，這對於技術變化快速的圖形繪制領域是重要的。至今，已有多款商業游戲使用了 OGRE 圖形繪制引擎，如國內的網絡游戲“天龍八部”、近期流行游戲“火炬之光”（Torchlight 2009.10）、網游“Zero Gear”等。OSG 偏向於虛擬仿真領域，強調庫的功能勝於程序設計理論。兩者都擁有着強大的開源社區，並是開源項目，隨時可以方便的查看源代碼，這對於開發應用程序是很有幫 助的。
5 參考文獻
[1]. OpenSceneGraph Quick Start Guide，Paul Martz[美]，王銳 錢學雷 譯，2007
[2]. Pro OGRE 3D Programming，Gregory Juker，邸銳 李旭東 譯，2006
[3]. OGRE Manual v1.7 ('Cthugha')，http://www.ogre3d.org/docs/manual/
[4]. OGRE Features，http://www.ogre3d.org/about/features
[5]. OSG Introduction，http://www.openscenegraph.org/projects/osg/wiki/About/Introduction