1 、引言
隨着計算機可視化、虛擬現實技術的飛速發展,人們對實時真
實感渲染以及場景複雜度提出了更高的要求。傳統的直接使用底層
圖形接口如OpenGL、DirectX開發圖形應用的模式愈來愈暴露出開
發覆雜性大、週期性長、維護困難的缺陷。爲此國外出現了許多優秀
的三維渲染引擎,好比Delta3D,OGRE,OSG,Unity3d,VTK等。渲
染引擎的做用是要優化遍歷和顯示三維模型。本文主要對OGRE與
OSG這兩個三維圖形渲染引擎作個簡單的比較,介紹他們在運行效
率、場景管理、功能支持、可擴展性等方面的異同。經過了解二者差
異後,能夠根據不一樣的項目需求,選擇合適的渲染引擎。
二、OGRE 與 OSG 渲染引擎簡介及特性
2.1 OGRE
OGRE(Object-Oriented Graphics Rendering Engine)即:
面向對象圖形渲染引擎,是一個用C++開發的面向場景、很是靈活
的3D引擎,誕生於1999年。它旨在讓開發人員更容易、更直接地利
用硬件加速的3D圖形系統開發應用。這個類庫隱藏了底層系統庫
Direct3D和OpenGL的全部細節,並支持多種高級特性,提供了一個
基於現實世界對象和其餘直觀類的接口。目前官網中OGRE的最新
版本爲1.7.3。
OGRE幾乎擁有了商業3D渲染引擎的所有特性,甚至有些方面
超越了它們
[2]
:(1)自動處理渲染狀態和空間剪裁;(2)支持全部紋理
混合和綁定技術,同時支持對GPU編程技術,支持彙編語言和全部
高級語言形式的各類着色語言,其中高級語言包括:Cg,HLSL和
GLSL;(3)強大且成熟的材質管理和腳本系統,能夠不動一行代碼去
進行材質維護;(4)支持多種紋理圖片格式,包括:PNG,TGA,DDS,
TIF,GIF,JPG,同時支持特殊格式的紋理;(5)全面支持對頂點和索
引緩存(vertex and index buffers)、頂點聲明(vertex declarations)
以及貼圖緩存(buffer mappings);(6)給出以插件方式連接不一樣場
景結構的接口,容許你使用適合本身應用程序的場景體系;(7)成熟
且可擴展的資源管理和載入系統,文件系統支持的文件包括zip,
pk3格式等等。
2.2 OSG
OSG(OpenSceneGraph)是一個高性能的開源三維圖形引擎,
是一個開放源碼,跨平臺的圖形開發包,它爲諸如飛行器仿真,虛擬
現實,科學計算可視化這樣的高性能圖形應用程序開發而設計。它
基於場景圖的概念,它提供一個封裝了OpenGL底層細節的面向對
象的框架,從而能把開發者從實現和優化底層圖形的調用中解脫出
來,而且它爲圖形應用程序的快速開發提供不少附加的實用工具。
OSG大概誕生於1997年,發展至今其功能特性涵蓋了大規模場景的
分頁支持,多線程、多顯示的渲染,粒子系統與陰影,各類文件格式
的支持。目前官網的穩定版本爲3.0.1。
OSG的引擎特性:
2.2.1 場景圖
OSG讓全部的人在場景圖技術中受益,不管是商業仍是非商業
的用戶,達到工業級的標準;方便了圖形圖象數據的保存;高性能高
效率;支持視圖投影剔除(view frustum culling),隱藏面剔除
(occlusion culling),小特性剔除(small feature culling),細節層
次節點(LOD),狀態排序(state sorting),頂點數組,頂點緩衝對象
(vertex buffer objects),OpenGL着色語言和顯示列表(display
lists),以上所列都是場景圖內核的一部分。它們共同使OSG成爲一
個高性能的圖形庫變爲可能。OSG也支持繪製進程(drawing
process)的定製,好比場景圖的連續細節層次(CLOD)的網格。
2.2.2 使用了自動記數功能
OSG中使用了智能指針的使用,使得開發人員脫離了繁重的內
存分配與釋放的工做;減小了因爲人爲的緣由形成的內存泄露的狀
況。
2.2.3 快速開發
場景圖的內核封裝了包括最新擴展的大部分OpenGL底層功
能,提供諸如剔除和排序的渲染優化功能,一樣提供能快速開發高
性能圖形應用程序的一整套補充庫,開發者能夠更快地掌握實質性
內容和如何操控這些它們,而再也不是底層的代碼。
2.2.4 強大的可擴展性、移植性、伸縮性
開發人員能夠根據本身的實際須要,對程序作一些必要的擴
展;如讀取插件,能夠根據本身的要求與須要編寫本身的文件格式
讀寫器;也能夠修改內核增長新的節點知足本身的需求;OSG的完
全獨立與窗口操做系統的場景圖內核庫使得用戶在它上面能夠增
加他們本身的指定窗口庫和應用程序,在發佈版本中osgViewer庫
提供自帶窗口支持,可支持Windows(Win32),Unices(X11)和OSX
(Carbon)。
2.2.5 OSG 提供功能強大的模塊,主要包括四個庫
[3]
(1)OSG核心庫(Core Library),主要功能是實現最核心的場
景數據庫的組織和管理、對場景圖形的操做以及爲外部數據庫的導
入提供和接口。主要包括的庫有:osg,用來OSG的內核模塊,主要爲
管理數據的類型與節點;osgDB,用來管理場景數據的讀取與保存,
以及插件的管理等等。
(2)OSG工具庫(NodeKit),是對OSG核心庫的一個補充,實現了
必定特定的功能。好比:
osgFX,用於渲染特效節點;osgParticle,提供了OSG對粒子系
統的支持,如雨、雪、爆炸模擬等;osgTerrain,提供OSG對地形的支
持,用於渲染高程數據(TIF、DEM等高程數據格式)等等。
(3)OSG插件庫。OSG插件庫是OSG一個很是重要的特色。爲了
讀入和寫出數據庫,OSG提供了許多動態的插件歷來支持其餘軟件
建立的3D或2D的數據格式:
支持的2D的文件格式有:bmp,jpg,png,pnm,tif,gif,jp2,pic,
svg,tga,rgb,txf,dd(s包含壓縮的一系列Mip貼圖影像),基於字體
的圖像也能夠經過.txf插件支持等;
LightWave(.lwo),Alias Wavefront(.obj),OpenFlight(.flt),In-
ventor Ascii 2.0 (.iv)/VRML 1.0 (.wrl),Designer Workshop
(.dw),AC3D(.ac)和本地ASCII文本格式(.osg)和本地二進制格式
(.ive)及.osga壓縮包格式,等等。
(4)OSG內省庫(osgIntrospection)
OSG內省庫提供了一個與語言無關的程序接口,確保了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 的主要特性有: app
效率特性
簡單、易用的面向對象接口設計使你能更容易地渲染 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 偏向於虛擬仿真領域,強調庫的功能勝於程序設計理論。二者都擁有着強大的開源社區,並是開源項目,隨時能夠方便的查看源代碼,這對於開發應用程序是頗有幫 助的。