再從核心談3DEngine的設計架構(轉)
再從核心談3DEngine的設計架構(轉)[@more@] 本人對3D也不甚瞭解,譯文動機一則是內容所致興致昂然,二則鍛鍊英譯中技能。由本人水平及經驗有限,文中絕對不乏大量誤解與誤譯,亦懇請讀者指出,得以一同提高。 佳文須共賞,也歡迎大家自由轉載 :) Introduction (簡介) 讓我們們談談你如何撰寫一份提供優雅效能的3D引擎。你的引擎需要提供的包括:曲面(curved surfaces)、動態光線(dynamic lighting)、體霧(volumetric fog)、鏡面(mirrors)、入口(portals)、天空體(skyboxes)、節點陰影(vertex shaders)、粒子系統(particle systems)、靜態網格模型(static mesh models)、網格模型動畫(animated mesh models)。假如你已經知道如何以上所述的所有功能順利工作,你也許便能將那些東東一起置入到一個引擎當中。 等等!在你開始撰寫程式碼前你必須先構思一下如何去架構你的引擎。多數來講,你一定是迫切地渴望去製作一個遊戲,但如果你立即投入便開始為你的引擎撰寫程式碼後,你一定會覺得非常難受,開發後期你可能會為置入新的特效與控制而不得不多次重寫大量的區域性程式碼,甚至以失敗而放棄告終。花一點時間好好地為你引擎深謀遠慮一番,這將會為你節省大量時間,也少一點頭痛。你一定不會急切地去架構一個巨型的工程;或許你也會在引擎未完成時而乾脆放棄它,然後去幹的別的什麼事兒。好了,當你掌握學習你所需知識的方式之前,也許你還不能完成那些事兒。將設計真正地完成確實是件美事,為之你會感覺更好,你將為之而耀眼! 讓我們分析一下具備完整功能的3D遊戲引擎的需要哪些基本部件。首先,這為具有相應3D經驗但且還需一些指引的開發者提供了一些資訊。這是一些並不難且能快速掌握但是你必須應用的內容條目。為將你的工作更好地進行下去,這裡將對關於“把多大的工作量”與“多少部分”置入一個遊戲引擎給出一個總概。我把這些成分稱為 系統(System)、控制檯(Console)、支援(Support),渲染/引擎 核心(Renderer/Engine Core)、遊戲介質層(Game Interface)、以及工具/資料(Tools/Data)。 Tools/Data (工具/資料) 在開發過程中,你總是需要一些資料,但不幸的是這並不象寫文字檔案或是定義一個立方體那麼簡單。至少,你得需要3d模型編輯器,關卡編輯器,以及圖形程式。你可以透過購買,也可以在網上找一些免費的程式滿足你的開發要求。不幸的是你可能還需要一些更多的工具可你卻根本無法獲得(還不存在呢),這時你只得自己動手去寫。最終你很可能要自行設計編寫一個關卡編輯器,因為你更本不可能獲得你所需。你可能也會編寫一些程式碼來為大量的檔案打個包,整天面對應付成百上千個檔案倒是非常痛苦的。你還必須寫一些轉換器或是外掛將3d模型編輯器的模型格式轉換成你自己的格式。你也需要一些加工遊戲資料的工具,譬如可見度估算或是光線貼圖。 一個基本的準則是,你可能要為設計工具而置入比遊戲本身等量甚至更多的程式碼。開始你總能找到現成的格式和工具,但是經過一段時間以後你就能認識到你需要你的引擎有很大的特性,然後你就會放棄以前的撰寫方式。 也許目前非常流行利用的第3方工具輔助開發,所以你必須時刻注意你的設計。因為一旦當你將你的引擎釋出為opensouce或是允許修改,那也許在某天中會有某些人來應用你的開發成果,他們將其擴充套件或者做某些修改。 或許你也應該花大量時間去設計美術,關卡,音效,音樂和實體模型,這就和你設計撰寫遊戲,工具以及引擎一樣。 System (系統) 系統(system)是引擎與機器本身做通訊互動的部件。一個優秀的引擎在待平臺移植時,它的系統則是唯一需要做主要更改(擴加程式碼)的地方。我們把一個系統分為若干個子系統,其中包括:圖形(Graphics)、輸入(Input)、聲音(Sound)、記時器(Timer)、配置(Configuration)。主系統負責初始化、更新、以及關閉所有的子系統。 圖形子系統(Graphics Sub-System)在遊戲裡表現得非常直觀,如果想在螢幕上畫點什麼的話,它(圖形子系統)便幹這事兒。大多數來講,圖形子系統都是利用OpenGL、Direct3D, Glide或是軟體渲染(software rendering)實現。如果能更理想一些,你甚至可以把這些API都給支援了,然後抽象出一個“圖形層”並將它置與實現API之上,這將給了客戶開發人員或是玩家更多的選擇,以獲取最好的相容性、最佳的表現效果。 輸入子系統(Input Sub-System)需要把各種不同輸入裝置(鍵盤、滑鼠、遊戲板[Gamepad],遊戲手柄[Joystick])的輸入觸發做統一的控制接收處理。(透明處理) 比方說,在遊戲中,系統要檢測玩家的位置是否在向前移動,與其直接地分別檢測每一種輸入裝置,不如透過向輸入子系統傳送請求以獲取輸入資訊,而輸入子系統才在幕後真正地幹活(分別檢測每一種輸入裝置),這一切對於客戶開發人員都是透明的。使用者與玩家可以非常自由地切換輸入裝置,透過不同的輸入裝置來獲取統一的行為將變的很容易。 聲音子系統(sound system)負責載入、播放聲音。該子系統功能非常簡潔明瞭,但當前很多遊戲都支援3D聲音,實現起來會稍許複雜一些。 3D遊戲引擎中很多出色的表現都是基於“時間系統”(time)的。因此你需要一段時間來為時間子系統(Timer sub-system)好好構思一番。即使它非常的簡單,(遊戲裡)任何東西都是透過時間觸發來做移動變化,但一份合理的設計將會讓你避免為實現而一遍又一遍地撰寫大量雷同的控制程式碼…… 配置系統(Configuration)位於所有子系統的頂端。它負責讀取配置記錄檔案,命令列引數,或是實現修改設定(setup)。在系統初始化以及執行期間,所有子系統都將一直與它保持通訊。切換圖象解析度(resolution),色深(color depth),定義按鈕(key bindings),聲音支援選項(sound support options),甚至包括載入遊戲,該系統將這些實現顯得格外的簡單與方便。把你引擎設計得更為可設定化一些,這將為除錯與測試帶來更大的方便;玩家與使用者也能很方便地選擇他(她)們喜歡的執行方式。 Console (控制檯) 哈!我知道所有人都樂意去更風做一個象Quake那樣的控制檯(console)系統。但這的確是一個非常好的想法。透過命令列變數與函式,你就能夠在執行時改變你的遊戲或是引擎的設定,而不需要重啟。開發期間輸出除錯資訊它將顯得非常的有效。很多時間你都需要測試一系列變數的值,將這些值輸出到控制檯上要比執行一個debugger速度顯然要快得多。你的引擎在執行期間,一旦發現了一個錯誤,你不必立即退出程式;透過控制檯,你可以做些非常輕便的控制,並將這個錯誤資訊列印出來。假如你不希望你的終端使用者看見或是使用該控制檯,你可以非常方便地將其disable,我想沒人能看得見它。 Support (支援) 支援系統(Support)在你引擎中任何地方都將被使用到。該系統包含了你引擎中所有的數學成分(點,面,矩陣等),(內)儲存管理器,檔案載入器,資料容器(假如你不願自己寫,也可以使用STL)。該模組任務顯得非常基礎與底層,或許你會將它複用到更多別的相關專案中去。 Renderer/Engine Core (渲染/引擎 核心) 哈~是呀,所有的人都熱愛3D圖象渲染!因為這邊有著非常多的不同種類的3D世界渲染方式,可要為各類擁有不同工作方式的3D圖形管道做出一個概要描述也是幾乎不可能的。 不管你的渲染器如何工作,最重要的是將你的渲染器元件製作得基化(based)與乾淨(clean)。 首先可以確定的是你將擁有不同的模組來完成不同的任務,我將渲染器拆分為以下幾個部份:可見裁減(Visibility)、碰撞檢測與反饋(Collision Detection and Response)、攝像器(Camera)、靜態幾何體(Static Geometry)、動態幾何體(Dynamic Geometry)、粒子系統(Particle Systems)、佈告板(Billboarding)、網格(Meshes)、天空體(Skybox)、光線(Lighting)、霧(Fogging)、節點陰影(Vertex Shading)和輸出(Output)。 其中每一個部分都得需要一個介面來方便地實現改變設定(settings)、位置(position)、方向(orientation)、以及其他可能與系統相關的屬性配置。 即將顯露出來的一個主要缺陷便是“特性臃腫”,這將取決於設計期間你想實現什麼樣的特性。但如不把新特色置入引擎的話,你就會發覺一切都將變的很困難,解決問題的方式也顯得特別遜色。 還有一件有意義的事便是讓所有的三角形[triangles](或是面[faces])最終在渲染管道里經過同一點。(並非每次的每個三角形,這裡討論的是三角形列表[triangle lists]、扇形[fans]、帶形[strips]、等) 多花一些工作讓所有物體的格式都能經過相同的光線、霧、以及陰影程式碼,這樣就能非常便利地僅透過切換材質與紋理id就使任何多邊形具有不同的渲染效果。 這不會傷及到被大量被渲染繪出的點,但是一旦你不當心,它可能會導致大量的冗餘程式碼。 你也許最終便能發現,實現所有這些你所需的極酷效果可能只佔了所有的15%左右的程式碼量甚至更少。這是當然的,因為大多數遊戲引擎並不只是圖形表現。 Game Interface (遊戲介質) 一個3D(遊戲)引擎很重要的部分便是------它是一個遊戲引擎。但這並不是一個遊戲。一個真正的遊戲所需的一些元件永遠不要將它包含到遊戲引擎裡。引擎與遊戲製作之間的控制介質能使程式碼設計變得更清晰,應用起來也會更舒服。這雖是一些額外的程式碼,但它能使遊戲引擎具有非常好重用性,透過設計架夠遊戲邏輯(game logic)的指令碼語言(scripting language)也能使開發變的更方便,也可以將遊戲程式碼置入庫中。如果你想在引擎本身中嵌入
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/8225414/viewspace-952119/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 談談UI架構設計的演化UI架構
- 淺談Nginx伺服器的內部核心架構設計!Nginx伺服器架構
- 淺談Nginx伺服器的內部核心架構設計Nginx伺服器架構
- 淺談12306 核心模型設計思路和架構設計模型架構
- 淺談12306核心模型設計思路和架構設計模型架構
- Mongodb架構設計淺談MongoDB架構
- iOS應用架構談:架構設計的方法論iOS應用架構
- iOS應用架構談(一):架構設計的方法論iOS應用架構
- 讀《前端架構設計》 兼談架構與框架前端架構框架
- App架構設計經驗談:業務層的設計APP架構
- App架構設計經驗談:展示層的設計APP架構
- 重構、重新架構、再設計與重寫的區別架構
- Hadoop核心之HDFS 架構設計Hadoop架構
- App架構設計經驗談:資料層的設計APP架構
- App架構設計經驗談:介面的設計APP架構
- 談談從CAP定理到Lambda架構的演化架構
- 從MVC框架看MVC架構的設計MVC框架架構
- 談談如何從資料湖(Data Lake)架構轉向資料網格(Data Mesh)架構架構
- App架構設計經驗談:介面”安全機制”的設計APP架構
- 百萬年薪架構師之路:談應用系統架構設計架構
- 今日頭條:iOS 架構設計雜談iOS架構
- Medium開發團隊談架構設計架構
- 程式設計師,如何從開發轉型做架構師?程式設計師架構
- 從 Etsy 團隊看敏捷架構的設計敏捷架構
- 從點線面體談開發到架構師的轉型架構
- PetShop的系統架構設計(一)(轉)架構
- MySQL架構設計談:從開發規範、選型、拆分到減壓MySql架構
- 遊戲從不孤立存在,談談影響遊戲設計的結構遊戲設計
- 戲說領域驅動設計(十三)——核心架構架構
- 想成為一名優秀的架構師?從架構設計開始架構
- 架構設計之架構的演變架構
- 溫故知新----再談建構函式 (轉)函式
- Java軟體架構設計慨論(轉載)--設計模式和系統架構的關係Java架構設計模式
- Linux核心程式設計實戰經驗談(轉)Linux程式設計
- SOA架構實踐首先從企業級IT架構設計著手架構
- 架構設計思想-微服務架構設計模式架構微服務設計模式
- .NET應用架構設計—重新認識分層架構(現代企業級應用分層架構核心設計要素)應用架構
- 漫談計算機架構計算機架構