官順暉（B86/R91/D99，太極影音研發部經理）
為什麼會留在台灣發展3D
其實沒有特別為什麼,跟家人討論完後,因為家裡因素就決定留在台灣了。我是CMLab畢業,歐陽明教授的學生。大學時候, 我們一群人在當時的計中主任林一鵬教授的協助下,成立了Game Lab。剛開始就四個人而己,我們有自己的硬體設備,自己的書籍採買基金與程序,一間頗大的實驗室,幾張很棒的電腦桌椅,還有一張非常舒服的沙發。教授不太盯我們,但會適時的給與進度上的“關心“,後來我們的團隊還有來自外文系的同學擔任故事企畫,幾位它校的美術天才兒童,還有學聲優的人加入...整個團隊就在混亂中成長,我們目的其實只是為了要寫遊戲。
在這之前,我曾和另一位同學去過昱泉intern了約兩年,是在什麼都不會的前提下去打工、寫程式的,然後自己開始看起了SIGGRAPH的proceedings,一開始都看不懂,只能先看看圖片。雖然你看不懂可是有些地方你會覺得看起來很酷,會覺得有興趣,我覺得這和我最後會留下來做3D有關,我大學到研究所都在接觸3D,或說是電腦圖學(Computer Graphics)可能來得更正確些,如果可以繼續做,我會覺得蠻開心的。
最後碩士畢業時,我選擇了太極影音(Digimax Inc.)的國防役,其他幾位同學則是去了昱泉。我沒有選遊戲公司,單純是因為我想要稍微有點不一樣未來,看看CG在遊戲產業之外的發展。當時太極可能全台灣80%的廣告都經過他們的後製,是個很有規模與歷史的公司,後來決定轉型朝CG動畫發展,我其實算是接近第一、第二批加入製作電腦動畫的技術人員。
為什麼會回來讀博士
其實當時,我沒有完全確定一定要回去讀博士,我的情況有點像是半推半就出來的,太極的黃董事長和我的主管吳博士(真巧,他也是畢業自CMLab的圖學組),他們希望與建議我去攻讀Ph.D.,這樣子以後對公司有幫助。一個Ph.D.的身分對公司來說影響力還蠻大的,如果你是Ph.D.,你的名片不會寫你是經理什麼的,而是標上Ph.D.;公司可以對外說我們有幾位Ph.D.,這對公司經營有一點影響,系上六樓不是也有一家動畫公司,他們公司可能就有4位Ph.D.,包括老闆自己,這個公司可能就會很有說服力,很多小公司的確是沒有或是只有一位。Ph.D.可以增進雙方的信任,但做過什麼作品也是很重要的一環。
其實Ph.D.比較重要的是教職有關,我有回去向幾位老師請益過,他們覺得我很適合回去唸,我就報了。Ph.D.畢業的比例其實不高,很多唸Ph.D.是唸到一半就離開,有一個原因是它會在你最黃金的時期而你要唸書,大部分人都在這時候工作,所以你可能會慢慢去改變你的決定。我目前是在公司工作,但可以請公假回學校,所以這對我來說算輕鬆,比較沒有心理壓力,我算是很幸運的一位。我沒辦法每次做的research都跟公司有關係,這蠻難的,學術研究要的是brand new idea,因為已經有太多東西被做掉了,奇怪的點子很常一開始是沒有商業價值的。我記得,我們在Game Lab時,有一位教授就說,他覺得80%~90%的research paper都沒用的,他鼓勵我們盡早接觸社會,從中了解需求與機會。我覺得他講的有部分是對的,可能十年內那些research都沒有用,譬如說,kinect技術其實很早就有了,沒有很複雜,可是你要商業化時,已經不是research的問題了,是偏工程、市場的問題,我主管也是CMLab的Ph.D.畢業,所以我覺得他了解這狀況,他不會要求說我在學校做的所有事情都要對公司有立刻的好處,所以我目前沒有什麼問題。
太極裏頭,台大資工畢業的還不算多,也有來自清大、交大、政大畢業的優秀人才,我現在的團隊大概十幾位,最多時有快20位。擔任team manager時,你的工作有50%~80%都在開會,所以當團隊變很大的時侯,我覺得管理能力是最關鍵的。最重要的是溝通,你可能有了一個半年的計劃過三個月就要改了,這時你就要跟大家溝通讓大家接受,你一個人可能管十幾個人,十幾個人下面再管十幾個人,所以我覺得這很重要。
太極還稱不上是超大公司,所以十幾位研發部同仁裡,其實真正偏research的人只有個位數,其他人都在執行業務所需的技術任務,聽起來簡單可是有很多事情要做。這種人會佔大多數,大家剛開始會不太想做那種工作,會覺得很遜,其實絕大多數的問題都會在這裡,聯發科有成立一個Lab只有做research,Lab裡只有十幾個人,所以我覺得偏research導向的team應該都很小,其他一兩百人的團隊應該還是以執行production相關的任務為主才是。
我學生時候跟老師的關係非常好,所以隨便話題都可以聊,與老師的互動不會覺得陌生,我想說回去問教授順便聊一聊,他們說可能你唸完Ph.D.會想要從事教職,我說那之後再說吧,他們說我蠻適合唸的,我猜老師當然會說你很適合啦,不過還是聊一下聽聽他們的看法。
我國中就會寫一些程式,那時候流行BASIC,後來就變C語言了,那時的電腦是386、486,我大學是推甄進去,像programming的課就很少去上課,我覺得我自修的速度可能比去上課還快,教授也很直接,你考試過了就可以整學期不用來,學期末時交期末報告就好,所以其實我們是合法翹課。
學生時代自學了哪些工具
我跟你們一樣,大一就開始玩ptt了。後來軒田可能是在大二還大三左右,加入ptt站長團隊,我比他晚一點,我沒記錯的話,好像是他介紹的,哈。我們是偏programming的站長。
那時候,大學院校間很流行自己架bbs,幾乎所有宿舍到處都有bbs,有的搞不好註冊人數只有100人,同時上線人數有5個就很了不起了,連我的數學系室友都會架bbs,你就知道有多熱門了。反正就是沒有原由的流行,所以我很早碰BSD、Linux,我們還有自己架文學網站,那些人還有在裡面寫小說,裡面唯一的文盲應該就是我吧,其他人都超厲害。然後,我們當然就開始用vim作為 programming editor 啦。那時也在學長的要求下,開始使用CVS來協同開發ptt bbs的程式,同時要熟習一些unix administrator應該要會的事, python是後來工作之後才碰的。
我下班後做的事情有時候跟我上班時做的是很像的,有一天我發現其實學computer science沒有那麼神奇,你就像木工一樣,他們其實就是有一些很熟悉的工具,而且有時候那些工具還蠻原始的,然後跟你講說這是最好用的,所以他們就是用他們熟悉的工具一直做事情,然後他就會更熟悉,更知道怎麼用工具,他們還會有一些個人的偏見,就他們來說那是一種專家的意見,其實把computer science想成你是一個工匠的話,你會需要有非常熟悉的工具,我也發現,你用什麼樣的工具幾乎會決定你想事情的方法,我的意思是說,如果你只會用visual studio跟IDE,你只會寫C++、C#,你大概就是那個樣子,所以我就會去看別的,然後我就碰到python,發覺它的邏輯蠻有趣,它認為你程式設計出來必須要readability非常高,那才是有價值的,有人說,我們寫出來的程式,要讓電腦能夠執行是很容易的,可是要讓人看得懂那是一件非常難的事,你要花非常多effort才能讓人看得懂,就算你是原來的作者,一年後去看你寫的東西,其實絕大部分你都很難立刻看懂你在幹麻,我們也發生過很多這種case,python是它建議你去寫可讀性比較高的code,所以我就開始用它,並把它導入公司,可是要導入公司蠻困難的,我覺得要有人先做,然後證明它可以,大家才會跟著寫,後來我轉變心態去看functional programming,我覺得那是有一點迷人的東西,雖然結果我還是寫不出什麼叫做functional way的程式,因為我覺得好像很難寫。
我editor用vim最多,現在還在用,還有用git。公司則用svn,因為我覺得教會他們用git大概太慢了,用svn就好了,譬如說你很忙的時候,我叫你用什麼東西的話,你必須要第一時間感受到它的好處,要不然你會覺得那再說吧,所以其實不是那麼容易,我用git沒有很久,同事也只有幾位用而已,學生時期我有學design pattern,UML則是看一看就放棄了,我覺得是因為我不懂欣賞它的優點,它應該有很多地方很厲害,但可能我沒有辦法吸收,所以我就沒有繼續碰。
HOWTO: From Thoughts to Workable Program
我可能不會有你們覺得很棒的答案。我覺得大部分都是執行的細節。
譬如說,有人透過關係跟你說,我們一起來試個新作法,雖然你也不是很懂,而且可能有一定的風險,可是因為我們平常關係很好,就說「好吧,我們一起來玩吧!」這可能是一種做法。或是說,我說服了你,我的方法有多好,原來的方法有多爛,然後講到最後你也真的我說服了,於是我們就從想法進展到執行了。有可能是這樣子,所以這答案不是很有趣,我還沒有辦法想出一個我做過的事情跟這有關,然後是很酷的作法之類的。
你合作的同事可能不是你部門的,你做的東西有一部分可能需要別部門的資源,他也要能接受你的工具可能有bug,用一用會當掉,接受你的工具沒有文件說明,他會一直跟你互動,你的介面搞不好還沒有UI,還要自己打指令,所以他可能還要學點指令,然後最後他可能需要做出比原來好看的東西。現實的情況,其實比較接近我現在說的這樣。
所以當我們有個idea時,我們會先聚集一群人,不是只有工程師,我們會跟大家講說,這是一個共同的project。這點很重要,決定了你的想法有沒有機會最後被落實到成功。
如果你現在是一位engineer,開發了點什麼,然後找了幾位可能的客戶,請他們來幫你測試一下,他們會說「好,我就幫你測一下」,玩了幾分鐘後,然後跟你講說他覺得哪不太好,可不可以改成怎樣會比較好用之類的,會講很多這類的建議,然後重點是,他講完後,他就覺得這不是他的事了,就閃人了。
你就會很苦惱這些意見要怎麼處置,於是你改了其中的一半,改了之後請他再來,他又跟你繼續講別的,然後就一而再,一而三這樣下去,永無止盡。
所以走這樣的testing,是註定會失敗的。尤其在小公司,你想出來的點子他不一定要接受,他會覺得他只是幫你測試。所以我們一開始就聲明說,這是個共同合作的project,你們兩個是一組的,這個案子跟你們兩個都有關,你會覺得這個project是你的,他也會覺得是他的,然後我們會讓你們坐在一起,讓你們互動加快;如果你們離很遠,你就會想說改天遇到他再跟他講一下,或者e-mail隨便寫個兩句話跟他說,或者就下禮拜主管meeting的時候你再抱怨他,但其實這樣沒有幫助。所以最好,你們就坐在隔壁,你就直接抱怨給他聽,他會告訴你原因,你也會稍微比較能接受一點,這樣就比較會成功,這個已經不是workable而已,已經到了要production proven 的階段。
另外,我覺得我們的職業病之一是,喜歡講英文。如果你跟其他人互動你就會發覺,我們很喜歡講英文、技術名詞,可是他們不是這樣,他們喜歡講白話一點,喜歡講中文就好,不要一直創新的名詞,這樣比較好溝通,最好的情況是你promote這個project,你知道怎麼跟他們溝通,在太極工作有一個哲學,就是人的重要性大於點子的重要性,就算你的點子真的很爛,點子可能指技術的點子或執行的點子,只要我們三個人溝通很順利,我們就自然可以把很爛的東西變得很好,因為我們溝通很清楚,我們三個人想的點子很糟的地方是一樣的那我們自然就會把他解決,假設你跟我做一樣的事情,可是你發現我做得比你快比你好,你就願意信任我的方法,例如我們都在217寫程式,我就坐在你旁邊用vim,你就會覺得想要試試看,這比用講的快太多了,我就直接給你看。
我們的董事長他本來是做廣告後製的,他慢慢覺得revenue沒那麼高,他去參觀了一些studio之後,發覺其實這也是有機會做business,所以他就回台大資工給了個talk,是給CMLab的,那時候我可能大一而已,所以沒參與到,他吸引到2個學生,那2名學生其實就是我現在的主管,他們兩個都是Ph.D.,他們加入後做了一個重要的決定,就是不要走代工路線。
這蠻神奇的,也挺需要勇氣與膽識的,我覺得如果是我的話,當時很難有這麼大的把握做這樣的決定。他們想要自己生content,可是這蠻困難的,失敗機率可能九成九吧,所以他們需要的是好萊塢的做事方法,他們就去找好萊塢的人,有點像請他們來建廠房,教一些人,跟你講說我們要用什麼設備,廠房要多大,大概像這樣。所以我進太極第一年的工作根本沒有做動畫,我們第一年在寫工具,那時主管是用Red Hat,然後我說我們應該要用Ubuntu或是Debian體系的,主管就說Red Hat比較好啊,有商業support,我說那有商業support,我們就給他一些機會來support好了。後來證實台灣Red Hat support不太行,所以就不管它了,後來那位主管又推 SUSE,不過一樣以support不如預期放棄掉了。推Ubuntu的原因是因為它是Debian體系,而且GUI客製得比較親切,除此之外,其實不見得是比較好的Linux Distro,只是我們要的是它源生自Debian的住點那一塊,原因就這樣而已。所以其實第一年都在做這些事情,不是coding就是MIS,但第二年開始做動畫,就覺得蠻好玩的。
太極厲害的地方是,它工作環境還蠻歡樂的,讓你想一直努力做下去,站在老闆角度,他當然希望你的壓力大一點,這樣產能才高,不過他也讓環境保持歡樂,所以還不至於出現無法承擔的壓力。我們中間還是有做一些性質很像的代工,我們並沒有擁有全部的device,所以就一步一步慢慢成長。
On collaboration, version, management and bug trace
認真說我們應該算沒有bug trace,跟訊連比起來的話,我們沒有像他們那麼嚴肅,不過我還是覺得有會比較好。
對於你做東西有什麼要求要有一個機制,我們不可能永遠透過e-mail或嘴巴講,那很可怕,如果100個人用嘴巴講或e-mail應該會瘋掉,而且會參差不齊,溝通會產生障礙,如果我覺得這個方向可能是錯的,你會覺得很奇怪,因為e-mail上說的是另外一個,這很容易發生,因為人很不可靠。
業界看paper與學生看paper的不同
大家都覺得paper大部分不能用,而且跟外國人聊過後,我發覺並不是只有我們這麼認為而已,很多studio的engineer都覺得一直有新的方法提出很棒,可是都會發覺這新的方法只能解決某個小問題。
我們做paper、research都會先對情況做一個假設,可是常常你是不能有這些假設的,所以它根本沒有用,永遠不會成立,即使它結果真的很棒,問題是它不在我的環境裡面成立,所以它根本不能用。
舉個例子,Pixar很有名的renderman裏頭,shadow map的實作,其實還是十幾年前提出來的方法的改進而已,並不是最近這幾年新的方法,因為新的方法只符合某些情況可用,搞到最後其實你還是覺得用舊的方法比較好。如果你是engineer你只負責實驗一小塊,你可以用新方法,對其他人來說他不在乎你用什麼方法,他只在乎結果,很多時候用一般的方法是它可以假設大家都會。
我喜歡新聞業,喜歡知道世界到底發生了什麼事,這跟我工作有關,我是主管,主管工作之一就是要知道大家在幹麻,就是你不能只知道公司裡面的方法,你還要知道有什麼新方法,所以我還是會看paper,也會鼓勵大家看,有新的paper出來的時候大家都會看,也會share,可能share完後會笑笑說這方法根本不行,但我們都先看過了,搞不好明年我們就發覺這方法可以拿來用,至少已經先看過會有印象,如果你都沒看過你就不知道,因為你的題目是業界看paper跟學生看paper的不同,我不知道學生看paper是怎樣,大概是學生看會覺得非常厲害,還有比較不考慮導入實際用途,工作之後會看整體,像是可不可以導入我們的公司,有沒有符合我們公司的budget,或是engineer開發要幾個月,跟我直接用舊的方法哪一個比較快,或哪一個比較有效率,類似這種的。
Thoughts on Optimization of Code
我們來先看個例子:我們之前做的”面對台灣的真相”是3-D立體的,所以必須有人搞清楚怎麼做立體動畫,還有哪些東西怎麼處理,我們有些案子是它一開始只有平面圖,他會希望你把它變立體的,接小案子一部分是為了增加經驗,你才會知道原來2D轉3D可以怎麼做,它有它的極限,轉一秒的電影也許要幾個小時,假設一部電影一小時好了,86400秒,它可能就要幾十萬個小時,這時,有沒有效率的影響,非常可觀與明顯。
有一說法是說,因為你在工作的時候你要的是很快把產品丟出來,所以你就先做prototype就好,不用管performance,如果是在動畫界的話我覺得可能兩面都要照顧,performance不能太差的情況下你要寫出prototype,所以有一點不容易,這並不是所有人都會處理的事情。
動畫公司有一些engineer叫TD,大家都很喜歡擔任TD,因為聽起來很酷,叫技術指導(Technical Director),他們寫的東西常常是把一些元件黏在一起,可能就不用考慮performance,不用optimize,因為真正核心的計算是演算法做的,他只是把它合起來,這裡效能不好的狀況就很少,就是它不是最花時間的那段。
雖然我們在談code 的optimization,其實很多時候是在談人的optimization,如果你的人流動率沒有很高,等到你知識累積夠深厚的時候,其實你就知道code optimize該怎麼執行才對,如果你的team每一陣子就要換,或者你的主管一直在換,其實你大概很難optimize到多好,因為你必需很多時候都要重來,這會是很嚴重的問題,所以執行的時候都要以年為單位,你可能覺得你今年執行的效率很好了,可是過兩年你就會發現其實沒有想像中那麼好,於是你就開始會改。
我之前看一位外國人講做太空梭,太空梭不是很複雜嗎,至少要花的錢很多,所以他們也要做各種optimize,他說你根本不可能一開始就預先想到那太空梭要多棒,你就是邊做邊試然後發覺爛掉了再改,所以他們才會花這麼多錢,就是邊做邊試然後一直失敗一直重來,他說這才是最好的方法。
我們沒有很嚴肅的UML,我一開始就承認其實我不懂UML,如果有人用UML在溝通你會聽他說,可是我們自己在討論的時候就沒有用到UML,我們幾乎是邊做就邊改的,這是太極的工作方法,比較naive,某種程度上naive不一定不好,邊做邊用對大家來說壓力比較小,因為大家都知道我們是邊做邊來的,所以都承認我們問題很多,就會想辦法讓它變好。
如果是軟體公司,你的產品就是軟體,很直接對不對,可是我們的產品不是軟體,是電影和動畫,所以我們不太像軟體公司,但我們用軟體公司的方法來做事情,這是非常有趣的一點。engineers習慣用有效率的方式來執行,如果我們公司沒有engineer會很可怕,會亂七八糟,他們會不能解決大規模的問題,例如說加個燈光進去就要重算,他們不會想說有沒有更好的方法,他們可能會去想怎樣比較好看,怎樣比較生動,而我們的任務就是讓你做事有效率。
給學弟妹的話
好好玩樂,為了可以好好玩樂,享受生命的美好,你做事就會好好做,拼命做,你會選擇愉快又效能不錯的方式完成工作,不會把它想成只是工作,這樣你就會做得很開心。
我覺得我目前是這樣,為了解決問題你要試試看新的東西,你會覺得還蠻好玩的,那你自然就有機會有好成果。譬如說你們應該都認識in2對不對,in2是一個很好的例子,非常正面的,她太喜歡做這種coding optimization,也真的很厲害,很認真,她讓optimize bbs變成是一件趣事,所以她們一群人一直在玩這個,一直亂試,ptt才變成可以同時十幾萬人telnet進去,這是件很奇妙的事,但她辦到了,我覺得關鍵是玩得很開心,那自然什麼事都OK。
我跟我主管說我本身還是喜歡當engineer,目前還沒老到不想寫程式,所以我希望我的management effort可以少一點,不要花太多力氣,他說你要有心理準備,這樣你會覺得有些事情參與感比較少,可是我覺得這樣沒關係,這是自己決定的,我不喜歡用一堆meeting討論怎麼解決問題,所以我的部門meeting我會希望一個小時能結束,要求盡量所有人都能參與發言,你如果覺得這此meeting跟你沒有關係,就不要來,我不會在意,我覺得這不是重點,重點是有沒有效率,如果這個小時想不出結論來那就算了,就等下一次。我所知道工作之後還有在活躍的,真的是把他的工作做得有趣的人,可是我覺得這跟興趣不太一樣,我不太相信把興趣跟工作結合的人,我比較相信的是把工作變有趣,這兩件事是不一樣的,把興趣跟工作結合有時會很糟,因為你就會非常堅持一些事情,就會失去焦點,把工作變有趣是另外一件事,你可以接受工作很多地方很糟,可是你還是可以把它做得好,這樣比較好。
