終於知道什麼是硬碟的S.M.A.R.T了

電腦真的是很有靈性的東西…...應該說是劣根性，它總是會挑你最片刻不得閒的時候出狀況，血淚教訓不勝枚舉。

前幾天NB的狀況就怪怪的，根據經驗法則，應該是硬碟傳輸模式離奇的又變成了PIO MODE(從休眠的時間可以看的出來，明顯變慢)，照例砍登錄重偵測，改回DMA MODE。

一點改善都沒有，重開機的時候居然POPUP出來了一段訊息
"1720-SMART Imminent failure attr:05"
傳說中的S.M.A.R.T真的是有這個東西的!!這個代碼經過翻譯，大意就是「你的硬碟得了癌症，沒人可以保證他什麼時候會突然掛點，能救多少資料就多 少資料吧」。玩了那麼久的電腦，也不是第一次掛硬碟，不過之前都像是意外暴斃，這卻是第一次像醫生跟你說你得了絕症一樣~還沒死，但不知道什麼時候要死~ 保重!感覺總是不太痛快(爆)

其實在五月初就感覺硬碟的運作的聲音怪怪的，已經先GHOST了一次。這顆40G的硬碟雖然又吵又熱，可是TOSHIBA 5400rpm ,16mb buffer的逸品，當初好不容易才入手的，現在掛點邊緣，心情實在不捨~~

我犯了一個很大的錯誤，想說乖乖照比爾大神的指示，使用WINDOWS預設的目錄架構「我的文件」~把我的PC當作MAC在用，40G的硬碟沒有切，系統和資料都放在同一個磁碟裡，造成要修復系統，備份資料的時候都困難重重。

更慘的是NB是1Splane的，所有的周邊都要透過1394或USB2外接(有點後悔沒有買底座了)。想說直接把硬碟dupe回舊的那顆硬碟~外 接GHOST居然偵測不到，外接不吃DVD開機片…….(內接可以呀)，總總種種，造成要回復系統困難重重，最後還是用最笨的方法……..

「重灌」

這下好了，前前後後又去掉我整個週末…...算你狠，真的算你狠………

P.S
資料當然是沒有流失，否則小聖不會心平氣和的把這篇劄記打完…….Yeah，U Know

推薦一本書 人月神話：軟體專案管理之道

下面這段文字，對應到台灣的數位內容產業，也是相當貼切~~尤其是電腦動畫，說真的，現在還沒有原生自這個領域，能夠站的上國際舞台的Producer級的人才，我們只能期待再期

當然，軟體的開發專案和動畫專案是不太一樣的，但是思維是可以做為借鏡的

博客來上的介紹

大型複雜系統的創新管理經驗與智慧

李仁芳

台灣不缺創新人才，供給嚴重不足的是創新管理人才。

我們有世界級的電影導演，但優秀的製作人(Producer)鳳毛麟角。

我們有個人擁有上百個專利的科技怪傑，但很難找到能經營企業研究中心(Corporate Lab)的技術長。

我們也有能寫優美程式的駭客級好手，但能管理一個大型複雜軟體系統開發的專案管理者則遍尋不著。

科技的創新與美學的創新，半靠天份，半靠後天的專注與努力﹔但是創新專案的管理，特別是大型複雜系統創新的管理，其綜覽全局的眼光與對系統產品概念的整體性(Conceptual integrity)的掌控，則非仰賴蓄積的經驗厚度不可。

這種對大型複雜系統創新的管理經驗紋路與智慧奧義非常內隱，很少被彰顯出來。

微軟公司近年來非常重視新產品開發專案開發完成後的「專案稽核」(Project Audit)文件，強制要求未完成此文件的專案領導人不得結案交差。比爾．蓋茲的用意即在藉這些文件，讓複雜軟體開發的管理經驗得以在微軟內部流通，增益 後來的微軟產品創新管理成效。 System/360與OS/360是人類軟體工程技術開發史上非常重要的里程碑，不論在技術成就或商業績效上，都是使IBM公司成為「大藍」(The Big Blue)的關鍵產品。 本書的作者Frederick P. Brooks, Jr.與另一要角Bob Evans（TSMC張忠謀先生好友，曾任行政院孫前院長的科技顧問及世界先進公司總經理）當年即為IBM此大型複雜系統專案的兩位主導人。 他們為System/360規劃了一系列不同的機型：Model 20、Model 30、Model 40、Model 50、Model 60、Model 62、Model 67……等等。 OS/360的創新開發，尖峰時期曾超過1,000人為之工作－－程式設計師、文件編寫員、機器操作員、助理、秘書、經理、支援小組等。從1963到 1966年間，大約有5,000個人年（man-year）的工作量是投入到OS/360系統的設計、建構和文件撰寫工作。 雖然從效能最初階、最便宜到效能最佳、最貴多重等級都有，但這些機型的外觀系統都一樣，操作方式也彼此相容，只是內部的實作方式按等級做了調整。客戶可以 視需要與預算來選擇適當的機型，而且拜單一架構之賜，使用者介面不需改變。因此客戶未來因業務成長想要升級時，門檻也很低——這是當時 System/360 一個很大的軟體工程技術成就與商業賣點。 Brooks的《人月神話》是記述人類工程史上一項里程碑式的大型複雜軟體系統開發經驗的「創新管理」經典之作。 書中揭示了許多大型複雜系統創新管理的經驗紋路與智慧奧義，是為有志於追求創新專案之管理專業人士參考。 創新管理是一極具「領域專屬」(Domain-Specific)特質的知識與技能。 管理大型複雜軟體專案的開發，與管理其他任何大型的專案(登月計畫、隱形轟炸機開發、局端交換機系統開發……)相比，類似的地方固然很多－－比大部分程式 設計師所相信的還要多。 然而，管理大型複雜軟體專案的開發，與其他領域大型專案不同的地方也很多－－比大部分的專案經理所預料的還要多。 程式的創作必須呈現得非常完美，就像哈利波特要施展魔法一樣，咒文中的一個字或一個停頓，只要稍有差池，魔法就施不出來。 人類並不習慣做到這麼完美，人類的活動也很少需要做到這麼完美－－而調適自我及團隊成員習於追求完美是軟體工程創新管理最困難的部分。 這種極致追求完美的大型複雜系統創新管理經驗，是人類智慧寶藏中極為重要、極為寶貴的一個環節，值得看重創新管理的人士仔細咀嚼。 Brooks以內行人的經驗深度與形象化深入淺出的語言，對這段智慧寶藏做出了貢獻。 他所稱的： ‧ （新系統）概念整體性（Conceptual Integrity）； ‧ 外科手術團隊； 約束對（軟體工程開發）藝術而言是件好事（Discipline is good for art）； 形式就是解放（Form is liberating）； 架構（architecture）的外部規格制定出來，事實上反而會增加實作小組創意風格，而非貶損； 架構設計師和實作人員越早進行持續性、充分、仔細而和諧的溝通，可以使架構設計師具有良好的成本概念，而實作人員也會對設計更有信心，不會模糊了各自的分 工； 巴別塔的失敗不是因為缺乏明確的目標與充沛的資源與技術，而是因為溝通（communication）以及隨之而來的組織（organization）問 題！ 這些創新管理的深刻經驗與見解，不只對大型軟體開發的管理十分寶貴，對其他領域的複雜系統之創新管理，也極具參考價值。 像Brooks具備這種經驗厚度的人，寫出《人月神話》這樣的書，是人類知能累積過程中極大的福氣。社會應多鼓勵有這樣成就的人士多寫出類似的著作來。

（本文作者為政治大學科技管理研究所教授兼所長）

[轉貼] CGI Historical Timeline

看到這樣詳盡的資料，我還能說什麼呢，只有叩首叩首再叩首了....... 關於CGI的發展歷史，加上參考資料、相關論文、影像、圖片的連結 非常的具有參考價值，CG人必讀。

http://accad.osu.edu/~waynec/history/timeline.html

[轉貼] 關於Final Gather和Global Illumination的看法

火星上的一篇老文章....沒有特別註明，不過應該是指MR的全局裏面的技術

之前我也被Photon和FG之間的關係搞混了，其實是獨立運作的。

MR在MAX6裡面，整合度上是高了很多，記得在r4外掛的時期，連透空貼圖都沒有辦法正確的轉譯，我個人也很期待MR for MAX的表現，畢竟內建的東西能用就用。

關於Final Gather和Global Illumination的看法

作者：unsound

　　在網上有人說Final Gather是對Global Illumination的類比。這種說法並不正確。在這裏可能是個文字遊戲，在Mental Ray中Global Illumination指的是光子繪圖演算法，而Final Gather屬於輻射照明演算法，類似於FR和LS中的Radiosity。雖然有些人將輻射照明廣義地定義爲計算場景中面之間光和散射反射的一種渲染規 則。基於這種功能定義，光子繪圖可以被看成是輻射照明的一種類型。但是，實際上許多電腦圖形學家對於輻射照明這個詞僅認爲它是一種特定的演算法，而光子繪 圖是另一種演算法。一般來說，當討論所有這些非直接照明過程時，使用綜合術語“全景照明”（Global Illumination）比較合適。

　　那爲何Mental Image要把光子繪圖寫成Global Illumination呢。首先我們知道Final Gather並不是真正的全景照明，它只注重對散射反射進行計算，不考慮別的反射。而光子繪圖計算混合反射，基於這樣的特性，光子繪圖可以很好的類比真實 光線的行爲，可以用於焦散等效果中。相比之下光子繪圖更爲先進，是真正的全景照明。（但這不說明F inal Gather是假的全景照明。它是對光線跟蹤演算法的一種補充，是全景照明演算法的一種，只不過他要和光線跟蹤演算法一起才能達到實際的全景照明。）

　　那既然光子繪圖演算法很先進，那爲何還要保留Final Gather呢？且先不說光子繪圖是否十全十美，就單說Final Gather的優勢就不能被光子繪圖替代。

　　我們知道Final Gather屬於輻射照明，其中光線通過散射反射面上的顔色來傳輸光。輻射照明可以進行逐步運算，這樣可以根據需要確定光的反射次數，從而形成對真實光照 的精細類比。基於這種特點，我們可以用環境貼圖充當光源用以産生非常真實的照明效果，HDRImage也就是基於此發展來的。

對於兩種演算法都有各自的優缺點。

　　Final Gather演算法的缺點是幾何體的解析度(也就是幾何體的多邊形細分度)和全景照明的解析度聯繫在一起。當多邊形較多時，很難計算出一個快而接近的場景光照。如果物體在場景中處於運動狀態，輻射照明方案和幾何形體的分割在每幀動畫是很難計算的。
利用光子繪圖，可以創建一個分開的資料類型，也就是由光子圖（Photon Map）來儲存全景照明結果。一個光子圖填繪結果的解析度和幾何形體的解析度無關。但用光子圖創造細緻精確的光照往往要使用相當多的光子，渲染速度很可能 比用Final Gather産生同樣質量圖像要慢的多。爲了優化渲染時間，需要我們根據實際需要選擇演算法。

下面我談談自己使用Final Gather的一點經驗。

　　在我們渲染大的場景時，建築牆面常常出現汙斑。不知大家注意沒有，往往汙斑出在大的牆面和一些拐角處。爲什麽會出在這些位置呢？大家還記不記得 前面講的F inal Gather演算法是和幾何體的解析度相關的。Mental Ray中的Final Gather精確度參數指的就是從每個多邊形上發射多少光線。也就是說物體劃分的越細，照明精度越高，出現汙斑的可能性越小。

　　我們往往在大的牆面使用很少的多邊形劃分，往往也就更容易産生汙斑。一般的解決辦法是加大精確度參數，但這樣做會極大的增加渲染時間，不是好辦 法。好的方法是，在建模時對牆面和拐角處進行一定程度上的細分（LightScape的對場景多邊形網格的劃分處理，起到的就是這個作用）。

來一套GI算圖引擎吧

前一陣子測試MR，說是測試不如說是體驗

一來MR在影視工業已經有一定的口碑，且是跨平台又是內建的算圖引擎，所以就先選擇了MR，可調整的選項不是很多，還滿單純的，看來要會寫shader才能發揮MR的威力。

老實說我並不是很擅長rendering的部份，也沒有做產品表現的需求，對我來說是想得到GI在Lighting上的方便性與質量感，所以速度與動畫的穩定性是我的重點。

MR算GI的速度太慢，這是我比較在意的地方。

隨後因為tmu兄的簡報，力挺FR，所以這兩天轉試FR

FR的可調整性應該是現在所有的算圖引擎中最大的吧

設定之繁雜令人有一種抓狂的感覺，但另一方面，就是有很大的調整彈性，可以應映不同的狀況做最佳化.............

可是要搞懂這些數字選項之間的交互關係，我總覺得不太像是artist的問題，比較像是programer該處裡的，應該有很大比例的artist在這方面是弱智的吧(不然也不會是artist)，在UI與調校的方便性上FR還有很大的進步空間。

好吧....明天開始是VRay的時間了。