今天才寫，有點晚了。
一月十五日，老妹生了第二胎，是個3240克的健康胖小子。
本來，還想著要他跟姐姐一樣過完年才出來，不過這小子的確跟姐姐一樣，也是大約37週就把媽媽的營養吃完，準備出來。
也好，兩人的生日都是正月十五，姐姐是農曆，弟弟是國曆。
看起來黑黑的，似乎又是個小黑皮。
這個胖小子，也是妹妹的夫家期盼了很久的男丁，上頭已經有三個姐姐了。
昨天老妹家裡在幫小娃娃取名字，剛好在MSN上撞見，我就跟著參考了意見。
「宗」: 不要，太菜市場了。
「宸」: 網路上查了字典，這個字好。辰是龍，屋頂下的龍，表示這個字是帝王的住所，也可以引申為帝王的意思。
「菘」: 看起來不錯，仔細一查，哇咧，原來這個植物就是「白菜」。算了，還是不要這個字吧。
「瑋」、「瑜」、「瑄」: 都不錯，都是「美玉」。不過就是有點像女生的名字，轉念一想，周瑜也用這個名字啊，還好啦。
最後選了「宸瑋」兩個字。很不錯吧，帝王的美玉。
小娃娃才出生一個星期，會不會對他期望太高了? 哈....
老妹照了幾張照片，不過都有點糊，還是小小張的看就好，放大看會更糊。
前一陣子發現計算OBB的演算法，研究了幾天，本以為大致都了解了，但深入去思考推導之後，卻才發現，原來我是錯得離譜，Totally Wrong!! (翻譯叫做 "一整個錯!!")
於是又從頭開始，一步一步從數學的角度來看。
觀念還是一樣，把美術模型的每一個頂點，都當做是取樣點，然後用Least Square Fit的方法，找出OBB需要的中心點以及三個軸向。
OBB的中心點取得，根據的是偏微分取極值的方法，三個軸向呢，則是用Principal Axis的概念，從Eigen vector來取得。
底下是兩個參考資料。
http://mathworld.wolfram.com/LeastSquaresFitting.html
http://www.geometrictools.com/Documentation/LeastSquaresFitting.pdf
這個推導，背後的數學有點小複雜，不過，大概都是些矩陣向量的運算概念。
最後呢，得到一個取得OBB的步驟。
1. 先建立一個可以解出Eigen value, Eigen vector的函式庫(或者去抄一個)
2. 把所有頂點座標加起來，找出平均值，就是OBB的中心。
3. 對於每一個頂點，計算與中心點在 x,y,z 三個方向的誤差值 X,Y,Z ，取得兩兩相乘的值，XX, XY, XZ, YY, YZ, ZZ，把每個頂點所算出來的這六個值，全部加起來平均。然後塞到一個3x3的矩陣內。
4. 把這個矩陣丟給Eigen System求解，拿回三個Eigen vector。
5. 用這三個Eigen vector得到的座標系統，轉換原來的頂點，找出在這個座標系統中的Box長寬高。
話說，元旦連續假日，大家都放假了，我還要上班。
把Code拿出來看看，想說處理一下引擎裡Bounding Box的計算。
找了一些Open Source的參考Code來看，想看看有沒有什麼比較有效率的演算方式來計算Bounding Box。
然後，我就愣住了。
眼前的這個演算法，把所有頂點的資料拿去算一個covariance matrix，再用這個matrix求解eigen vector以及eigen value，然後....就算出了包圍所有頂點的最佳的Oriented Bounding Box。eigen vector是OBB的三個軸向。用找到的三個軸向，來計算OBB的軸半徑。
我傻眼了。
eigen vector有那麼神嗎? 連這個都能算。還有covariance matrix究竟是什麼東西啊?
開始研究了幾天，總算是比較清楚整個運算的來龍去脈。
有時間整理出來的話，再拿來分享好了。
簡單的說，covariance matrix計算(x,y,z)數據的變異量以及彼此之間的影響，例如，x軸方向的數據，在y軸數據變動時，所受到的影響，這東西可以從最小平方差的總和，以偏微分取極值的方式導出類似的計算。
接下來這樣想，假設我們已經知道了OBB的三個軸向，我們就可以將所有的頂點(x,y,z)，轉成在OBB座標系中的頂點(x',y',z')，而以(x',y',z')所計算得的covariance matrix，兩個不同的軸向(x'與y'或是 y'與z'等等...)之間的互相變異量應該是最小的，滿足這樣條件的三個軸向，就是最佳的OBB軸向。
這些計算一直演算下來，就出現了eigen value problem，所以最後eigen vector又出來幫忙，解決了問題。
好，結論。
結論就是....
數學才是王道啊!!
==========================================
Update: 原來還是看錯了，對應eigen vector的eigen value並不是軸半徑，covariance matrix只用來取得OBB的軸向。
前幾天看了一部片子，片名是 "The Bucket List"，意思是死前的願望，中文把片名翻譯做「一路玩到掛」，很聳動，但是我覺得很糟糕，所以，還是用英文片名來記錄這部片子。
傑克尼克遜演的是一個億萬富翁，艾德華柯爾，事業很大，擁有好幾家醫院。摩根費里曼演的是一位汽車技工，卡特錢伯斯，雖然是個藍領黑手，但是知識淵博。
這兩人的相遇，是在癌症病房裡，兩人同住在一間病房中，就在艾德華擁有的醫院。
卡特曾經擁有很多夢想，卻因為生活現實無法實現。艾德華則是沒有夢想，只知道經營龐大的事業。兩人同住一間病房，相處久了自然發展出一些友誼。
就在一天，當兩人知道自己的生命已經來日無多，準備面對死亡時，卡特寫下了"The Bucket List"，像是"大笑到流淚", "開古董跑車", "登喜馬拉雅山看景觀"這些人生願望。平常遊戲人間的艾德華，也寫下了"高空跳傘", "刺青", "親吻一個全世界最漂亮的女孩"的願望。
卡特問說，「這個願望你要怎麼達成?」
艾德華說，「找很多漂亮的女孩來各親一下。」
於是兩個只剩下六個月生命的病友，結伴旅遊，在生命的最後的一年半載，為自己而活，實現他們最後的人生願望去。
兩人四處旅遊，埃及金字塔、中國長城、泰姬瑪哈陵都走了一遭。唯獨喜馬拉雅山山頂因為天候的關係而放棄。
電影海報中的兩人笑得很燦爛，不光是因為實現了願望與夢想，也因為在這旅程中找回了一生中最快樂的時光。
卡特回到了家人的身邊，回到了平凡的生活，在平凡的家庭中拾回了他的快樂與人生。
艾德華幾經掙扎，也終於與久未聯絡的女兒見上面，擁抱親吻了第一次見到的外孫女，親吻了一個「全世界最漂亮的女孩」。
電影的結局，也是最後一個願望。
兩人的骨灰共同放在了喜馬拉雅山的山頂。
昨天晚上開始，電視播放魔鬼終結者的電視影集。
故事是從電影第二集之後開始，莎拉康納解決了終結者，同時天網的設計者(我真的忘了他叫什麼名字啦，只記得是一個黑人演的)也自我犧牲了之後，過了幾年平靜的生活，莎拉還嫁了人。
然後故事繼續。電影第三集告訴我們，天網還是會存在，所以天網派了其他的終結者前來，繼續殺掉約翰康納的任務。未來的約翰康納也不甘示弱，派了一個少女外型的機器人保鑣回到過去保護他自己。
(我覺得這樣真好，如果是我，我也會派個美女來，而不是像阿諾的那種肌肉男....)
昨天看了兩集，還滿好看。
只不過我有一事不明，電影的第二集，終結者不是已經進化到液態金屬機械人了，為什麼後來派的還是像阿諾那種型號的機械人啊? 天網也是越來越退步了喔?
啊....電視影集成本比較小咩....
抓了幾張海報圖片當作紀念....
在過去，我們將遊戲中的特效，分為兩種類型。一種我們稱之為「模型特效」，基本上它就是個美術製作出來的3D模型，只是我們將它用為特效物件上。另外一種，就是「粒子系統」所呈現出來的特效。
過去我們在設計的時候，「粒子系統特效」交給誰來設計製作，一直是一個很困擾的問題。粒子系統沒有一個固定的3D模型，只有一堆的運算參數。程式設計師根據這些參數，去計算每個粒子隨著時間的變化，所以裡面牽涉到不少的數學運算。
程式設計師非常清楚這些參數在數學上的意義，也明瞭調整這些參數對粒子系統的影響，所以，似乎交給我們來設計各式各樣的粒子特效是個不錯的主意。
但這樣一來，這個特效就很可能不好看。例如上面那張單調的煙火特效。畢竟，程式設計師並不是美術設計師。
可是交給美術設計師來製作設計的話，我們要做的第一件事，並不是設計一個很好用的粒子系統編輯器工具，而是 -- 教他們「數學」。
不要鬧了。
所以，有一段時間，我們的粒子系統特效一直是程式設計師在製作。不過，只是做些小特效，比較炫麗、華麗的魔法招式特效，還是交給美術設計，用模型特效來做。
最近我們發現，我們的美術設計師在3dsMax這些建模工具裡，也能夠把粒子系統摸索得很熟練，呵，這是個好機會，讓我們脫離設計難看的粒子特效的好機會。
於是我們做了一些研究，修改3dsMax exporter plugin，將美術在3dsMax中設計的粒子系統輸出，取得一些參數，然後運用這些參數，在遊戲中想辦法模擬出3dsMax的粒子運算。
這麼一來，所有的魔法招式特效，都可以交給美術設計師來製作設計，甚至於，還能夠設計一個華麗的模型特效，再搭配一些粒子特效做點綴。遊戲中的特效就會變得很吸引人。
==============================================
其實，遊戲中還有第三種類型的特殊效果，是運用「Shader」所做出來的效果，例如場景光暈、光線的散射、折射、反射等等。還有像底下這張圖，在「魔獸世界」裡，掛點以後所看到的畫面。
這類型的特殊效果，就真的必須由程式設計師來設計了。
遊戲中，隨著劇情跟內容的進行，遊戲場景也會一場一場的變化。遊戲場景大大小小不同，龐大的遊戲場景，可能會有數千個物件在其中，而在網路遊戲的場景中，除了物件之外，可能還會有數百個玩家在其中。
但是我們視野所見的範圍，只是龐大場景中的一角，我們所見到的物件或是玩家，也只是附近的一小撮而已。數字上來說，可能只有十幾二十個物件、七八個玩家，相較於整個場景，只是一小部分。其他大部分場景中的物件與玩家，不管他們發生了什麼事，都是千里之外的事情，我們看不見，也不需要知道。
所以，我們需要場景管理(Scene Management)。
場景管理的最大用處，是能夠用很快的方式，找出視野範圍內的物件，也就是我們需要關心的物件。一般來說，會先將一個場景空間分割成小區塊，把每個物件放在它隸屬的小區塊中，然後再用一個樹狀結構將區塊組織起來，像是二元空間分割(Binary Space Partition, BSP)、四元樹、八元樹等等。
接下來的動作就是，我們可以知道視點在哪個區塊中，視野包括了哪些區塊，然後就只需要處理這些區塊中的物件就好。
通道(Portal)系統則是另一個在場景管理中的工具。
我們在場景裡有一棟房子，我們站在房子外的時候，房子內發生了什麼事，我們是不需要知道的，同樣的，在房子內的人，也看不到房子外。只有門打開的時候，透過大門，房子內外的人可以彼此看見。這個大門，就是所謂的「通道」。
房子是場景中的一個封閉空間，也是一個獨立的區塊，我們站在房子外，除非透過「通道」，否則看不見房子內部。也因為這樣，只有在「通道」進入我們的視野內的時候，我們才需要處理房子內的人和物。
這麼一來，繪圖效能與計算效率都可以提昇。
請看取自「魔獸世界」的這張圖。我站在旅館的外面，左邊站了一個衛兵，右邊有另一個女性NPC，當然旅館內的物件跟NPC是看不見的。這個旅館的造型設計也是完全為了通道而設計的，門口進去一點點，就橫著一道牆，所以我們就算是這樣面對著門口，也還是看不到裡面的狀況。
第二張圖，是在旅館內，身後站了兩個女NPC。我們看不到外面。
我在這兩個情形下，抓了兩張線框模式的圖。
線框模式下，看得很清楚，在旅館外面的時候，旅館內的NPC，完全沒處理。在旅館內的時候，更簡略了，連外面的場景都沒處理。
