改做背景地圖的架構

在上次的 SceneNode 測試中，得出了一個結果，就是在 OGRE 中如果有很多 SceneNode 的話，速度便會快速地下降。後來我想想，我的 Ogng'3D 中的背景地圖的 Portal 處理，每個背景物件都使用了一個 SceneNode，這樣便用了很多 SceneNode 來定義 Sectors，就以那個「多 SceneNode 便慢下來」的情況下，我便決定重新去想想，如何改善現在的 Portal 地圖架構，改變處理方法來減少 SceneNode 使用量。

改動已有的系統需要不少工程，因為從 Load 入 Portal、載入每個背景物件的 3D 資料，以致測試 Portals / Sectors 的等等步驟都牽涉到。

在今天 ( 星期六 )，用了一整天的時間 ( 真的超過 12 個小時呢 ... )，從兩晚前草草訂下的計劃中，完成了改造。改造後的背景地圖仍以 Portals / Sectors 為主，在背景地圖組成方面就改了「 以 Material 來做組別 」，使用同一個 Material 的背景物件，都用同一個 SceneNode 及 Entity 組合起來，就是說 SceneNode 數量和 Material 數量掛勾，而每一個背景物件就是一個 SubEntity。因為在我設計的地圖的資料中，已有各個背景物件的資料，在測試 Portals / Sectors 方面的改動，只是在測試後，改變相關 SubEntity 的 Visible 值便可。

這樣使用 SceneNode 量便可以減少，從而可減少 OGRE 中的 Drawcall 數量，增加 Render 背景地圖的速度。希望這個改動工程真的有效吧，因為我還未有一個有很多背景物件做測試的地圖 ......。

目標 : Vertex Animation 功能

對了，Vertex Animation 會是我下一個目標。

Vertex Animation 是個很久遠的技術，在早期的 3D 遊戲中已有使用，那時候 3D 角色的動畫全部都是用 Vertex Animation 做的。後來 Skeleton Animation 的興起，便代替了這個技術，但它並未就此被忘掉。

其實在現時的 3D 遊戲中，Vertex Animation 的用途在哪裡呢？主要是 Facial Animation。而我想開始做 Vertex Animation 的原因，就是因為想在 Ogng'3D 中，加進 Facial Animation 的功能。


還可以做一大堆的手部動作，代替手部大量 Skeleton 動畫。 正在努力中，謝謝。

OGRE 的 SceneNode 挑戰

究竟 OGRE 這個 3D 圖像引擎，是慢還是快呢？這個沒有確實的定論，因為每一個圖像引擎都有它的特點 ( 牆頭草言論 :D )。

今天聽到同事們說，OGRE 中的 SceneNode 在更新方面未盡善盡美，一多起來便會很慢。我也不知道當中的問題在哪裡，因為我從來沒有了解過她的內部運作。今晚回家後，便想試試如果 SceneNode 真的有很多，那麼會慢了多少？

下圖是我用了之前測試新 Sprite 系統的 Demo，轉為直接每個 Sprite 都用一個 SceneNode 來控制，總共有 256 個 Sprites，同時在畫面中從左到右不停的移動，而且還用了我新加入的 SpriteGroup 系統，另外再畫出 500 個 Sprites ( 只用一個 SceneNode，但很難看得到，因為前面說的 256 個 Sprites 已經很密集 )。

Demo 的整體速度當然是下降了，但在百分點上，大約是慢了 30%。我不太清楚這個數字是不是很差，但在於我來說，它能夠保持在 60 Frames per second 的速度，已經很不錯的了。

Animation Blend Mask 測試

昨天說過，會嘗試用用 OGRE3D v1.6 中的 Animation Blend Mask，並整合到我的 Ogng'3D 遊戲引擎中。我用了大約 10 個小時，有了一點點的成果，看上去真的很利害 ( 這個是很重要的 f(^_^') )，當然要給大家看看了。

這個還是在測試中，大家看到片段中，從 Single-Animation 轉到 Multi-Animation，或 Multi-Animation 轉回 Single Animation 時會有 smooth transition，但這功能很難搞，仍有不少問題，還要努力測試。

自己的假期

明天開始，便會放幾天大假，但沒有甚麼出遊計劃，那麼做些甚麼好呢？還未有決定，但相信還是會待在家中，寫一點程式。

其中有一樣技術一直想試驗一下，在 OGRE 1.6 開始，新增了一個 Animation BlendMask 功能，透過這個新功能，一個 Entity 中的動畫可以重疊使用，例如上身在用鎗射擊，下半身在跑著。總是覺得，動作遊戲有這些多重動畫結合，真的很有用。

另外，看到自己的 Ogng3D 中，Actor ( 角色控件 ) 物件方面太多 Functions 集中在一起，看上去真的很巨形，自己希望嘗試將這部份分拆成小件，做點 Refactoring。加上上面說的試驗 Animation BlendMask，這個自己的假期也算是充實吧。

Billboards 與 2D Sprites

在兩個星期前，我嘗試重新製作 Ogng3D 遊戲引擎中，用 OGRE 中的 Billboard 來做 2D Sprite 的方案，未改做前的 2D Sprite 是充滿著問題，而且還不能控制 Z-Order。這個重新製作用了不到一天時間便完成了，因為在測試期中發覺只需改一些地方，便能夠做到控制 Z-Order 的方法，對於 2D Sprite 系統來說，控制 Z-Order 是非常重要的事情。

今晚決定要試一試這個新的 2D Sprite 系統的速度上會是如何，我的家中有兩部電腦，它們的硬件是：
● AMD Athlon XP 1600+ 及 NVidia 6600 LE (AGP)
● Intel Pentium 4 3Ghz HT 及 NVidia 7600 GT (PCI-E)

我的測試是，Demo 會從畫面的正中央，不停地放出一個已隨機 Rotate 了的 Sprite，移動到畫面邊緣會停下來，不會刪除掉，總共放出 1024 個 ( 或而上 )，看看會不會出現明顯慢下來的情況。下面左圖是 AMD 的測試畫面 ( 以 Fullscreen 測試 )，右圖是 Intel P4 的畫面 ( 以 Windowed 測試 )，兩部電腦的測試速度上對我來說確實是很高，感覺不到速度有被拖慢。

新的 Sprite 系統是用了 BillboardSet + SceneNode 完成，初時還以為有這麼多的 Billboard，可能會令遊戲引擎慢下來，但結果是慢下來的情況非常低，甚至有點感覺不到 ( 相信是 3D card 還夠強勁 )。這次成功的改做了 Sprite 系統，那麼便可以真正地在 MilkShape3D 上，製作對應 Sprite 工具了，而且還可以嘗試製作 GUI 工具呢。

Street Fighter IV

雞巴 4，繼 1998 年的 雞巴 3 之後，最新的正統續作。

還記得在 2008 年初次看到那個 Teaser 片段時，打從心底裡說「 Capcom，我不要 3D！」；後來驚訝遊戲真的是 3D ，失望了一段短時間，後來看多了 Capcom 不斷發放的遊戲相關資料後，覺得越看越順眼。在數日前公司有同事買來了 PS3 版本，就馬上的要試試了。

因為之前一直也沒玩過 Arcade 版本，所以還是不懂得用 Saving Attack，只好用老舊的技術玩玩。確實還真的佩服了 Capcom，遊戲性和 2D 的遊戲沒分別，而且表現方法在感覺上也很自然，3D 和 2D 融合得非常的好，Capcom 真有一手，GamePlay 萬歲。順帶一提，Zangief 的 「立 Screw 」超容易使出，信心大大回復。

p.s. 「立 Screw 」一詞源自日文，立為日文漢字站立的意思，Screw 為 Zangief 的絕招 Screw-Pile Driver 的簡稱，意指在地上站著不跳躍使出 Screw-Pile Driver 絕招。

九型人格，我 ... 人格分裂？

九型人格分析

第九型	和平型、和平者、和諧型、維持和諧者 15%
第五型	智慧型、觀察者、思想型、理性分析者、思考型 14%
第四型	藝術型、浪漫者、自我型、憑感覺者 14%
第七型	快樂主義型、豐富型、活躍型、創造可能者、享樂型 13%
第六型	忠誠型、忠誠型、尋找安全者、謹慎型 10%
第八型	領袖型、能力型、挑戰者、保護者、權威型 9%
第一型	完美主義者、完美型、改革者、改進型、秩序大使 9%
第二型	助人者、全愛型、助人型、成就他人者、博愛型 8%
第三型	成就者、事業型、成就型、實踐型 8%

我的九型人格分析？

看來我還是做個藝術家比較好。XD

玩遊戲的迷思

在 2D 遊戲的時代，遊戲都是簡單的操控：十字掣移動，A按鈕是跳躍，B按鈕是攻擊；關卡設計也是簡單的，在設計上就是要你不停地做出指定動作，如果玩家做不到，只是他不夠熟練，一旦玩家熟練後就可以駕輕就熟地完成。Sprite 也是充滿想像空間的，因為記憶體不足的問題，背景或是人物的 Animation 往往都是有限的，但這種有限也給與了玩家的想像空間。整個遊戲除了給玩家遊玩之外，也做就了玩家的一些正面心智成長。

在現今 3D 遊戲設計的道路上，已經很難看到一些和以前 2D 相比的例子。曾經和同事們討論過，究竟為什麼會有這種情況出現？那些簡單但令人中毒很深的遊戲，現在的 3D 遊戲中真的很難找到些例子，究竟問題出在哪裡？有同事的意見是，我年齡增長了，見識和玩過的遊戲也增多了，在要求上變了，但是我卻不太完全同意。

我喜愛玩的遊戲的模式，其實是很簡單的，我做的事情就是：攻擊 ( 連續攻擊 )、跳躍 ( 雙重跳 )、跳躍攻擊、抓住敵人再攻擊 ... 等等。加一點點攻擊或武器的強化工具，遊戲的進程速度爽快，變化慢慢增加 ( 不是難度 )。

想一想，玩遊戲就是想跳出現實，玩樂一會兒，但是歐美大型 3D 遊戲卻以「 真實 」作為賣點，在玩遊戲的時候要跳入另一個「( 偽 ) 真實環境」，究竟哪裡能帶來一些正面的心智成長？

相關網頁：
● Opinion: How Mega Man 9 Resembles… Real Life ?
● 那些洛克人教我們的事

Retained 和 Immediate Mode 程式編寫

這幾天農曆新年假期，都沒有特別編寫程式，只是將 Ogng3D 由 Ogre 1.4.9 正式轉到 1.6.1。今天反而想說說一個程式編寫的念頭，就是 Retained 及 Immediate Mode 程式編寫的題目。

就電腦程式編寫方面，很多時都會看到 Retained Mode 的程式，例如 Windows 的程式就是最好的例子，每個程式都是以 Messages 及 Callback 形式執行，這樣的做的原因，在我的理解上，是要 De-couple 程式之間的關係，令程式與程式之間互相不需要倚賴，也能夠完成工作。但是 Immediate Mode 的程式就剛剛相反，程式在需要的時候直接地呼叫另一個程式來完成一個小工作，之間的倚賴性是很強的，如果分開了它們，程式便不能夠完成工作，甚至連 Compile 也不可以呢。

但是兩者之間，除了上面所說的編程風格外，還有甚麼其他分別呢？就我自己而言，是「難度」的分別：Retained Mode 比 Immediate Mode 困難。

在製作遊戲方面呢，會不會有特別的分別？有的，遊戲的設計及前期工作上，就是最主要的分別。以歐美及日本市場為例，歐美喜歡一邊製作同時一邊更新及改善遊戲設計 ( 更甚者會改變設計 )，而日本就很不一樣，很多時候一開始便已經有了遊戲的定案，製作上只要依設計定案完成便可。歐美的情況用 Retained Mode 就會比較好，因為程式設計都是分開的，遊戲設計需要改動的話，換個程式便可以 ( 但卻很花時間 )。後者就多以 Immediate Mode 製作了，因為遊戲設計是不會大改的，所以程式都不太需要重寫。

以上所說的，是以 Game Play 編程為背景，在 Game Engine 方面，其實是沒有特別設定了，為什麼呢？原因是製作 Game Play 的編程員，多是不需要理會 Game Engine 的架構，只要 Game Engine 方便使用，速度高便可以的了。

恭喜發財，萬事勝意

Network 遊戲的學習進展

上週末努力試過使用 network library，成功地將兩部 PC 連上了 ( 只是以 LAN 形式 )，這幾天用了點時間，繼續在嘗試。

這一次我在一部 PC 上，運行兩個單一 Program 來完成連線 ( 這個太普通了吧 ... )。然後便嘗試在一個遊戲軟件中，實現 P2P 的連線遊玩，其實我的目標是，先製作一個簡單的「一對一」連線遊戲。

流程大致完成了，現在的情況會是：
● 進入 Splash Screen 及 Main Menu 畫面
● 選擇 Connect to ( Client ) 或 Start Host ( Server )
● 進入 Game Room 畫面：
　○ Client 需要玩家輸入 Host 的 IP 或名字
　○ Server 只需等待另一玩家連線
● 成功連線後，Server 回傳訊息確認連線
● 確認後，Server / Client 同時進入 Game Play

在 Game Play 中的資料傳送方面，使用了一個 Timer 加入 Callback 控制，定時傳送 / 接收資料，因為都是以 Local Host / LAN 作為試驗，所以更新資料次數可以來得比較多 ( 每秒十次或以上，packet size 為 29 byte )。Game Play 方面可說是最麻煩的，所以還未完成，現時只是成功進入 Game Play ，及傳送接收資料而已。

我在用 C 編寫遊戲嗎 ?

有看過我的 Blog 的朋友都知道，我是很喜歡用 C Language 寫程式的，除了製作 Ogng3D 引擎是用 C++ 外，自己的遊戲或 Demo 都是用 C 編寫的。

前幾天正在用 C 編寫程式，來試驗 Network 連線時，突然有一點感受，就是我完全感覺不到自己在編寫 C 程式。那一刻的我覺得自己，就好像在編寫 Script 程式一樣，感覺很神奇。為什麼會有這種感覺呢？後來我想了一天，終於想到了，就是因為我在用 C 寫遊戲時，已經不需要再考慮遊戲引擎的問題，可以很專注地對付 Game Play 的程式設計。

雖然 Ogng3D 引擎是用 OGRE 及 C++ 製作，但是在設計上，已經不需要直接使用 OGRE 的任何部件，而且引擎是用 C 及 DLL 做接口，基本上用任何程式語言也可以使用。就好像一些遊戲引擎支援 Python 或 LUA 一樣，製作遊戲的人員是不需要理會遊戲引擎內部運作，可以專注地製作遊戲內容。

現在的我，可以用一句經典說話形容：
「 Write Games, Not Engines ! 」

那當然了，若果在引擎方面真的需要新功能，才能夠完成某些工作的，加強 Ogng3D 還是免不了的。

Happy Net Year

在 2008 年，曾經將一個免費的 network library "ENet" 套入到 Ogng3D 中，那時候也是初接觸 network library 及程式編寫，但是並沒有再深入地研究下去。而這個沒有繼續的工作，在這兩天便投入了時間去繼續了。

ENet 是一個提供一種銜接層面的 network library，當中一些 network 中的管理還是要自己做的。在這兩天週末的時間，就是嘗試製作一些 network 資料的管理 Functions，例如：起動 Server、起動 Client、那個 Client 已連接上 Server 及 Server / Client 之間的資料傳送。其中最令我煩惱的，可以說是 memory 管理，因為在 network 之間的資料傳送，通常都是很嚴格的，最好沒有一個 Byte 是浪費的。而且 ENet 只是一個銜接層，沒有限制使用哪種方案，就是說用家要自訂 Protocol 及 Data 等資料型態，這些都是我的弱項，到了剛才 ( 踏入零晨時分 ) 才可以說是暫時測試完成。

Network 程式編寫確實是很煩瑣，為什麼會這樣的呢？

祝大家 2009 年比 2008 年更開心、更健康。

Technical Artist ?

大家有沒有看過這個職銜呢？Technical Artist，中文直譯的就是「 技術美術員 」，那究竟這個職位是做甚麼的呢？

在兩年前，認識了一位在美國遊戲業工作的人員，他的職銜就是 Technical Artist。雖然說是 Artist，但是他卻一點畫作也不懂，他每每也會開動 MAYA 來做一些測試，他曾經說過，他的工作是非常困難和獨特的，那時候有點令我摸不著頭腦。昨天我在閱讀一本有關遊戲製作的雜誌，其中一篇文章講述了這個職位的工作範疇。

在那文章初，說了一個有趣的情況：製作遊戲時，Artist 都會向 Programmer 要求工具支援，過一會兒後，Artist 就會收到 Programmer 做好的工具，但是對 Artist 來說，這些工具都是不容易使用的。另外在製作後期，因為 Artist 做出來的東西，令遊戲運行速度表現差，Artist 和 Programmer 在這時候又會開始一場拉鋸戰了。

Technical Artist 的職位就在這個情況下出現的了。在遊戲製作整個過程中，不斷在 Artist 及 Programmer 中周旋，抓取一個在他們之間的平衡點，不失遊戲的運行速度，而又可達到 Artist 要求的效果，並與以執行。

我所閱讀的雜誌：程序員 遊戲創造 ( 2008 年 12 月下 )

IMGUI

在 2008 年期間，因為要做製作遊戲的工具，所以接觸了很多有關 Win32 API 的資料，它雖然很強大，但在實際製作工具的時候，仍覺得它頗為麻煩的，常常要處理一些 Message，而且沒有一個好用的 GUI Design 工具 ( 或是可以自訂 Skin 的工具 )，對我來說寫這類 Program 時感覺就是不太順暢。

今天閒來在 Web Surfing 時候，發現了一個 GUI 的 Concept：「 IMGUI 」( Immediate-Mode Graphical User Interfaces )，看了一些簡介之後，頓時發覺這個就是我想做的東西，所以便開始看多一點這方面的資料。IMGUI 很簡單，不需要處理煩瑣的 Messages 及 States，只需要處理 UI Context 及 Widgets 便可以。在數個月前我確實想過類似的東西，只是在開始上出了點問題未能解決而放下了，那時候還未得知這個 IMGUI 的存在。

這個 IMGUI 方案，我覺得很適合在遊戲製作上使用，而下是幾個有關這個方案的資料：

• IMGUI seminar with Jetro Lauha at Assembly 2007 Summer
• Immediate-Mode Graphical User Interfaces (Video)
• Sol on Immediate Mode GUIs (IMGUI)

p.s. 其實可能很多 GUI 的方案都是使用這個 Concept 的，只是沒有說明罷了，而上面的資料卻引起了我的輕趣及注目呢，而且 ... IMGUI 的設計上是 Anti-OOP 的，我喜歡！ :D :D

聖誕節的願望

在 2008 年期間，有個遊戲一直都想玩的，但是因為日本的保護主意 ( 我覺得是我國某些 Online game 玩家的行為引致的 )，令我不能正常地體驗，那遊戲就是熱烈的「 Monster Hunter Frontier 」( PC 版本的 Monster Hunter )。能夠玩到這遊戲，可能是我在今年聖誕節中的願望。

從未試過有一隻 online game 是可以「如此」吸引我的，以前曾經覺得「 Phantasy Star Online 」是好玩的，但 Monster Hunter 的 Action 度卻是比 PSO 高很多。以往曾玩過 PS2 版本的 Monster Hunter，但那時候未有 Online 或合作模式版本，所以覺得不太好玩，但有了 Online 及合作模式後卻變得吸引我了。

以前曾經想在家中，能夠玩到類似「 SpikeOut 」的遊戲，但 SEGA 一直都沒有移值這遊戲到 Console 機或電腦上 ( 很多年後才在 XBox 上出現 )，所以我才搞一個「 Final Spike 」出來給自己玩。那麼我可能要自己搞一個叫做「 Behemoth Slayer 」，來滿足自己對 Monster Hunter 的興趣了。

工具製作，2008 回顧

一年容易又到年尾了，在今年年初時，決意要製作一些遊戲製作工具，在這裡要回看一下，究竟做了些甚麼出來。

Material Editor (1) (2)
雖然 OGRE 有一個很不錯的資源管理系統，但要用於製作工具時卻是非常困難的，而 Material 的管理是其中的致命傷。因為那個 Material 是以一個 Script 來儲存的，要製作好一個 Material script 和觀察它在 OGRE 中的表現是頗為困難的。這個工具可以製作一些簡單的 Material script，亦同時可以看到在 OGRE 中的表現。

Character Editor (1) (2) (3)
在 2007 年尾時開始接觸 Event / Data driven 的編程技術，從中學懂了一些相關的理念，所以就利用製作這工具的機會同時實踐 Event 系統。工具主要的功能是管理 Animation 的速度和 Event 的發放，這個工具只要配合 MilkShape3D Animation Splitter 工具及 OGRE Mesh Exporter 就能順利完成相關工作。

OLM MilkShape3D Plugin
這個是從朋友的 OLM ( Open Light Mapper ) 工具衍生出來的，因為覺得它的功能強大而且易用，所以便在一個短時間內，將我常用的 MilkShape3D 及 OLM 整合起來。


雖然只是製作了三個工具，但功能上絕對是紮實的，而且 Bugs 量更是極少 ( :-P )。其實在我的心目中，有一個工具一直都很想做的，就是一個類似 Scene Builder 的工具，之前在製作 OLM MilkShape3D Plugin 時學懂了一點東西，希望能夠在 MilkShape3D 中，完成類似的功能，而這個 Scene Builder，可能是最後一個需要製作的工具呢。

經濟衰退的遊戲

經濟又再進入衰退，香港在十年間遇過數次經濟危機，可以說是難得一見，所以我也來發發牙痕。

有人說，電影業與遊戲業在經濟衰推時，多數都不會受影響，因為現實上很不高興，人們都會到電影院或待在家中看電影，又或者慳來不出外用晚餐的洗費，換來一隻電子遊戲留在家中遊玩。

以上所說的，都好像確切地出現過，每每所謂的經濟衰退，都不太聽過遊戲業受牽連，但究竟事實是否如此？多年前日本曾經試過一次頗利害的經濟衰退，日本是其中一個遊戲業界大國，當年有多個遊戲業界新聞，說某某遊戲公司裁員，某某遊戲公司結業，其實如今的一間遊戲母公司，拆散做多間子公司，就是在那時候出現的。簡化架構，精簡人手，就是要做到減省開支，而不失質量。

這次的經濟危機乃全球性問題，而現時的次世代遊戲，往往開發時間長及成本龐大，相信對遊戲製作公司有一定的壓力。而日本作為其中一個遊戲業界大國，近幾年各大遊戲商都將遊戲「國際化」，但同時卻犧牲了日本遊戲獨有的遊戲性，回看 PS One 或 SEGA Saturn 時期的遊戲，比現時 PS3 或 XBox360 的遊戲更好玩更好賣，難怪日本業界近年只專注於「炒冷飯」或「Remake」。

經濟衰退不是一年半載能夠輕易復甦，近年歐洲是個新興的遊戲發展市場，究竟下一年這市場能否保持著那分熱鬧，就要看看到時的國際環境變成如何了。

Move to MinGW + Code::Blocks

常常看到網上的 Programmer 說道 M$ DLL Hell，雖然我對 DLL 一向都沒有好感，但總是沒有特別的機會體驗一下，終於在上星期遇到過了，情況就是我用 Ogng3D 做好的一個小遊戲，不能在其他電腦上執行，因為 M$ 的 VC Runtime DLL 問題，原因是 Ogng3D 是用 VC++ 2005 Express 製作的，其所用的 VC Runtime 是要超複雜的工序才可以 Deploy 的。

沒錯這個 DLL 問題是可以用 VC++ 2005 Pro 解決，我想要保持著「低成本」的原則，決不採用這個昂貴的方案，所以我便將注意力方在 MinGW + Code::Blocks 上。安裝 MinGW + Code::Blocks 不是件難事，因為 Code::Blocks 的裝件已經簡化了整個過程，下載回來執行安裝便可以。在這時候旅程才只是剛剛開始，我下載 OGRE3D 的 MinGW 的套件，安裝後發現裡面沒有 .a 檔案，初時以為要自己重新 Compile，但看看那些 Sample 後才發現，原來 MinGW 可以直接拿 DLL 來 Import 的。

安頓好 Code::Blocks、MinGW 及 OGRE3D 之後，當然就是要在 Code::Blocks 中 compile 我的 Ogng3D 了，過程也頗順利，沒有特別的問題便成功做好了 MinGW 版本的 Ogng3D，再將其用 PellesC 的工具 dump 出 LIB，嘗試用 PellesC 的遊戲程式 Link 來用，成功了！

在 Code::Blocks 上 Debug 絕對不是一件容易事，因為它用上了 GDB，試過了數次也不能成功啟動 Debugger，後來改動 Workspace 的架構和用較新版本的 GDB，才能夠成功在 GBD 中啟動 Ogng3D 來 Debug。就這樣，兩天的週末時間就沒了三分之二了。

後記：世上沒有免費午餐，免費的東西就要付出時間和努力，要駕馭 MinGW + Code::Blocks 也是一樣，同時 3rd Party 的 DLL 也多了，但總比其他電腦不能執行較好。雖然成功地建立了 MinGW 版本的 Ogng3D，VC++ Express 版本仍是會同步使用的，主要原因是因為 MilkShape3D 的 Plugin 是一定要用 VC++ 來製作的，這點比較可惜。

後記二：終於有機會在一部不能執行的那個小遊戲的電腦上試過了，遊戲成功啟動及運作，真的很感動，而且很高興有辦法逃離 M$ DLL Hell。(11-Nov-2008)

MilkShape3D + Open Light Mapper

今天要介紹一個工具，這個工具是專門做 Lightmap 的「 Open Light Mapper 」( OLM )。這個工具的好處是，它是個 Open Source 的 Project，而且能夠同時建立 Lightmap 及 Ambient Occlusion Map。OLM 是個 command-line 程式，用法就是先將 Geometry 及燈光等資料，寫做一個 OLM 格式檔案，然後執行 OLM，予以之前寫出的檔案，它就會自動建立一個 Lightmap 圖像檔案。

在大約一個月前，試過這個工具在 3DS MAX 中的表現後，就決定做個 MilkShape3D ( MS3D ) 的 Plugin 版本。但首先要解決的是，我需要一個能夠自動完成 Texture UV Unwrap 的工具，試過多個 Unwrap 工具後，便決定試用 RoadKill ( 因為只有它能夠將做好的 UV，完好地 import 到 MS3D )。經過一輪 GUI 程式編寫後，大約完成了 70%，現在的工序大約是：
● MS3D 做好 3D model
● 放到 RoadKill 中 Unwrap Texture UV
● Import 回到 MS3D
● 在 MS3D 中啟動及執行 OLM Plugin 工具

下面有兩幅在 MS3D 中執行 OLM 工具，及建立好的 Lightmap 和 AO 的效果 ( 看上去好像有點問題，那是因為 RoadKill Unwrap UV 之間空間太少，這個要再想辦法 ..... )，第三幅圖是在 Ogng3D 測試 Demo 畫面。

Open Light Mapper 很強的呢 ！ ( 因為我認識它的創作人嘛 :-D )