Drake's Weblog

1 minute read

最近一直在閱讀,吸收來不及吸收的各種知識,重新審視過去我視為理所當然的觀念,哪裏需要修正,哪裏需要以不同的角度重新解釋一番,其中之一,是 animatin studios 裏頭 RD/TD,或再泛稱一點,所謂的技術人員,他們應該怎麼自處,應該在工作心理與技術能力上學習些什麼。

Coding for love 這個 blog 的主人翁,是一位在動畫產業工作的工程師,裏頭的 Stupid Things That Should Be Fixed 很好笑,雖然只有短短的三篇:

Securing Failure in Tools Development 這一篇來說:

如果,你是一位在動畫公司工作,有負責(間接或直接)開發一些工具的 TD/RD 的話,你常常會遇到你的使用者,也就是非程式設計師們,對你說:「怎麼這個程式這麼難用呀;他好像一下子就當了也;可以幫我看一下,你的程式好像不聽話唷;能不能加個什麼功能呢…」相信我,這些話你應該常常聽到的。

程式設計師的最終目標之一,是寫出一種非常酷的程式,可以把一些工作,幾乎全部給自動化,不需要任何人的界介入,就是「自動化的極致」。打開我們寫過的清單:preview render, final render, attach prman shader, create spot light through camera, auto rigging setup, auto convert textures between low res & high res, auto fix texture uv seamness, auto make animation curve’s end infinity, … what else? you name it.

然後呢,我們也常常失敗在這個「自動」上頭。使用者假設你的程式真的很「自動化,百無一失」,你也慢慢被要求成要寫出這樣的程式,但時間的壓力,加上不完善的程式開發環境,導致你永遠寫不出這樣的程式來;另一方面,比女人還要善變數百倍的動畫製作流程朝令夕改(這是種非常誇大,但很容易貼切人心的說法),讓你的程式永遠趕不上變化萬千的流程。於是呢,使用者繼續遇上問題,繼續質問你的工具的可信度,然後你繼續覺得很悶,覺得有修不完的程式,不健全的程式…

原作者舉個有趣的例子:

如果你在非常好的動畫公司,那動畫人員會坐下來,認真地看待開發工具這件事,並且有打算長時間和你一路一起研究,找出一種在各方條件下,最折衷的工具樣貌出來,並且與你做某種程度上,盡量完整的測試與試驗,然後再把它的限制與優點記下來,最後教給他的其它組員們。如果你在一家非常爛的公司,那動畫人員不覺得開發工具與他們有啥關係,所以工程師你自行開發,最後再自行推銷。如果你在一般的公司,那可能動畫人員會幫你做點測試,然後偶爾和你聊一聊,接下來還都是你的工作。

最遭的情況,應該是「一般的公司」,因為前兩者很乾脆,工具開發起來反而單純。很棒的公司下,會慢慢磨出很棒的工具來;而很爛的工作環境,那就是程式寫出來,美術人員只有聽話使用的份,也沒什麼好挑三撿四的。最有趣的是第三種情況,不上不下,於是雙方有不一致的預期,然後災難就來了。

我看到這,忍不住想到處找人聊聊這件事,實在太有趣,也太貼切了。

回過頭來,我可能無法一直持續擔任只鑽研技術的技術人了,只好把這份榮耀與成就感委託其它更優秀的技術人員,然後呢,我要去好好想想怎麼做好「技術的形而上」的問題去了~

comments powered by Disqus

Recent posts

Categories

About

You're looking at Drake's words or statements. All opinions are my own.