Shotgun雜談（三）

題圖來自網路

之前提到過，當前主流的CG項目管理軟體在設計上都很相似，後端資料庫前端網頁操作，同時提供一套API來訪問和修改資料庫。開發人員可以在自己的流程工具中使用API來調用項目數據。在CG行業里的老兵都知道，目前行業內各個公司使用的軟體都是相同的，環節都是高度類似的，人員都是來迴流動的，所以流程上也大同小異。一個TD進入另一家公司，往往需要把以前開發過的工具重寫一遍。所有的TD都會想，難道沒有什麼辦法減少我開發上的重複勞動嗎：「為什麼不能把Pixar的流程（工具）直接拷貝到我的伺服器上，讓我直接生產動畫大片兒？」撇開法律上的原因，我們分析一下技術上的難點。

假設有兩個公司的A和B，它們的流程類似，都有模型綁定材質動畫這些環節，所以它們都需要在模型製作結束後拷貝給下游部門，比如綁定，來進行下一步操作。

A公司的命名規則是這樣的，模型(model)文件放在

<伺服器>/<項目名>/<資產名>/ model/<資產名>.<版本>.ma

B公司的規則下，模型的路徑是

<本地磁碟>/<項目名>/<資產類別>/<資產名>/<資產名>.model.<版本x>.<版本y>.ma

可以看到，即使兩個公司在做同一個項目的同一個資產，它們的工程文件的路徑也是不一樣的。很遺憾，A公司的拷貝模型文件的工具是不能直接使用在B公司的流程里的，因為在B公司的工作環境中找不到A公司規則的文件路徑。

但這有經驗的開發者肯定會想到，解決這個問題無非就是再抽象一層唄。如果A B兩家公司的開發者都按照相同的思路來做抽象，兩家公司的工具不就可以通用了嘛。只可惜在現實中，製作公司山頭林立，少了一個流程上的行業標準，沒有哪家公司願意做這麼吃力不討好的事情。這個需求確實是存在的，讓敏銳的開發者無法忽視，而這個工作由跨製作公司提供項目管理軟體的開發團隊來做再合適不過了。

2013年，shotgun推出了它們的流程工具框架 TANK （之後改名為 Shotgun Tool Kit - SGTK）。在TANK的框架中，伺服器，部門，資產名...這些決定文件路徑的關鍵詞都可以從shotgun的資料庫中獲取，然後用戶再將路徑定義到一個模板文件里。如果我們檢查A公司的模板，可以看到類似這樣的定義：

{模型文件} = <伺服器>/<項目名>/<資產名>/ model/<資產名>.<版本>.ma

之後如果在TANK的框架下開發工具，模型拷貝將不再去尋找 啦啦啦 老長的路徑，而是直接去找 {模型文件} 即可。那麼這個工具放到同樣定義了{模型文件}的B公司的流程里，bingo!，照樣能用。

在 TANK 框架下工具依賴的核心是對CG項目中各個層面概念的抽象，在抽象和映射之後，一個在理念上通用用工具可以真正的成為通用：跨操作系統，跨軟體，甚至跨公司，這真的是一個非常酷的理念。實踐中，在追光動畫成立之初選用了這個方案，幫助我們把流程快速成型，節省了不少流程搭建和項目啟動的時間。

再舉一個實踐中的例子。在公司成立的初期，存儲伺服器方案沒有確定的時候，我們會吧所有的文件都放在一台臨時伺服器上。同時在模板中定義好路徑：

{A類文件} = <伺服器X>/...

{B類文件} = <伺服器X>/...

當製作開始一段時間後，購買的新伺服器 A B 到位，找一個晚上，把伺服器 X上的文件各自同步到伺服器AB之後，修改模板成

{A類文件} = <伺服器A>/...

{B類文件} = <伺服器B>/...

不用修改任何工具，藝術家第二天來到公司直接可以繼續工作，完全感覺不到文件的路徑已經全都改過了。

分割線

好話說完，以下開始講TANK的缺點：

• 首先是配置比較麻煩。雖然和13年時公測版本相比，配置過程已經簡化了許多，但還是需要TD大量的手動操作，修改很多配置文件。
• 對於工作環境的穩定性要求很高。想要在某個任務上啟動TANK標準的工具，模板中所有和這個任務相關的路徑必須已經被創建出來。一旦有一個伺服器掉線，TANK會認為工作環境不完整而無法啟動，那怕實際需要操作的文件與掉線的伺服器無關。而穩定的網路環境和可靠的伺服器是對運維一個很高的要求。
• 啟動工具時有額外的時間開銷，有時候啟動甚至會莫名其妙的卡頓，而原因很難追查。
• 報錯不好排查。TANK開發者的設計讓報錯信息被隱蔽起來，需要一定的技巧才能被捕捉。雖然這讓錯誤顯得「乾淨」，但對開發者很不友好。

儘管還不是一個完美體系，TANK還在這個技術方向上打開了一扇門。TANK的框架名為core，和製作軟體的連接程序定義為engine，軟體中的工具定義為 app（從github上下載），可以看出shotgun在統一流程上的野心。也希望有一天，通用的流程框架（不一定是TANK）能成為業內標準，讓小公司也能享受技術帶來的效率提升。