上文我們說(shuō)到了?Pipeline?需要管理的數(shù)據(jù)和元數(shù)據(jù)，以及它們的特點(diǎn)和管理方式。

一個(gè)資產(chǎn)有不同組成部分，每個(gè)部分都有文件數(shù)據(jù)和元數(shù)據(jù)，海量的資產(chǎn)就組成我們資產(chǎn)管理系統(tǒng)。

那么，要搭建資產(chǎn)管理系統(tǒng)，從哪里著手呢？

莫急，我們來(lái)觀察一個(gè)（主要是影視）美術(shù)的一天。

一個(gè) Artist 的日常

實(shí)際上，并不是“導(dǎo)出下游資產(chǎn)文件”，任務(wù)就完成了，完事大吉了。

首先比如模型任務(wù)并不是必須100%完成，才能給到綁定；其次哪怕模型任務(wù)通過了，也有導(dǎo)演/總監(jiān)想法又變了，或者模型文件有質(zhì)量方面的問題，都需要重新進(jìn)入制作，然后導(dǎo)出下游資產(chǎn)文件。

從上圖中，我們可以看到明顯有三類文件：

• 工程文件，我們?nèi)€(gè)代號(hào)叫?workfile：美術(shù)工作的文件，通常是 DCC 的 project file，比如 ma、mb、max、hip、 psd、spp

• 圖片或視頻文件，我們?nèi)€(gè)代號(hào)叫?dailies：可以通過review 系統(tǒng)進(jìn)行查看的文件，比如 mp4、mov、avi、png、jpg，如果 review 系統(tǒng)支持3d 資產(chǎn)查看，那么也可能是fbx、obj 等格式

• 上下游交接文件，我們?nèi)€(gè)代號(hào)叫?element：比較“干凈的”，通常是第三方格式，比如三維資產(chǎn)的 obj、fbx、abc、usd等，二維資產(chǎn)的 png、jpg、tga、exr

舉個(gè)例子，現(xiàn)在有個(gè)工業(yè)化廚房，你的工作環(huán)節(jié)是切土豆絲：

你從 A 窗口拿到一個(gè)削好皮的土豆（上游的element）

你的?workfile包含了你的案板、你的刀、切的土豆絲、切下去的邊角料；

你的?dailies?就是你干著活，老板想看看你的工作成果，有沒有切成他喜歡的形狀，這時(shí)候你就拿手機(jī)拍了照或者拍了視頻發(fā)給老板，老板說(shuō)我喜歡那種波浪狀的土豆絲，于是你換了個(gè)刀片，開始切波浪狀的土豆絲，再拍照發(fā)給老板，老板說(shuō)沒問題了。

然后你把切好的，大于4cm的（經(jīng)過質(zhì)檢）土豆絲，這就是你導(dǎo)出的element，放在另一個(gè)窗口，Pipeline 會(huì)自動(dòng)把它送到下一個(gè)環(huán)節(jié)的 A 窗口。

題外話：影視有更細(xì)分的環(huán)節(jié)TD，負(fù)責(zé)幫你把切菜的刀改進(jìn)得更鋒利一些、或者引進(jìn)更先進(jìn)的切菜手法、研發(fā)更多方便提升效率的刀片.....

我們把文件分類好了，就可以根據(jù)他們的特點(diǎn)，以及應(yīng)用場(chǎng)景，分而治之，逐個(gè)擊破。

在此之前，我們還需要對(duì)文件什么時(shí)候，在哪里放，做一些說(shuō)明。分別提到影視的文件共享方式（比如NAS）和游戲的中心化版本管理系統(tǒng)（比如P4V）

工作區(qū) vs Publish區(qū)

這里會(huì)涉及一個(gè)?workspace（工作區(qū)） 和文件管理系統(tǒng)服務(wù)器（publish區(qū)）

如果是?P4V?這樣的管理系統(tǒng)，則工作區(qū)就是你在客戶端里面看到的workspace，它是你本地的一個(gè)目錄，而?publish?區(qū)就是?P4V的服務(wù)器

特點(diǎn)：文件不下載到本地電腦里，就不能引用。

首先我們最好要求美術(shù)的workspace，都設(shè)置為統(tǒng)一個(gè)位置，比如d:/my_workspace，這樣，d:/my_workpace/....../char_goblin_rig.ma就可以引用d:/my_workpace/....../char_goblin_model.ma文件，Submit到?P4V服務(wù)器時(shí)，把 rig 文件依賴的 model 文件路徑信息，保存到數(shù)據(jù)庫(kù)里，其他人下載了該 rig文件時(shí)，從數(shù)據(jù)庫(kù)讀取到依賴的 model 文件，則把 model 文件也一同下載了，打開 rig 文件，引用關(guān)系正確無(wú)誤，文件沒問題。

如果美術(shù)的workspace位置五花八門，則文件的引用需要使用相對(duì)路徑，如果跟被引用文件層級(jí)相差較遠(yuǎn)，則會(huì)帶來(lái)閱讀的不方便，想想看../../../../model/char_goblin_model.ma。

NAS的方式：工作區(qū)和?publish區(qū)，都在NAS服務(wù)器上，只不過分成了兩個(gè)文件夾：

這種方式，美術(shù)無(wú)需本地有額外硬盤空間，而是直接就在NAS服務(wù)器上進(jìn)行制作，無(wú)需上傳下載。

首先需要美術(shù)把NAS映射為同一個(gè)盤符，比如?x:/。一般影視公司 IT 可直接全域推送，無(wú)需美術(shù)手動(dòng)連接。

美術(shù)的綁定文件?x:/workspace/artist_xxx/....../char_goblin_rig_v002.ma引用的是?x:/publish/....../char_goblin_model_v002.ma

美術(shù)在NAS上的個(gè)人workspace文件夾中，只存放他自己的工程文件即可，無(wú)需拷貝相關(guān)引用文件到他的workspace下。

publish區(qū)的文件一般有嚴(yán)格的權(quán)限管控，不允許普通用戶刪除和修改，如果文件需要更改，則要升級(jí)一個(gè)版本，比如從v002升級(jí)（另存為）為v003，并且提交（拷貝）到publish區(qū)。

誰(shuí)能提交什么類型文件，是由該美術(shù)的任務(wù)決定的，也就是說(shuō)，一個(gè)動(dòng)畫師，沒有model任務(wù)，該動(dòng)畫師根本就無(wú)法去提交一個(gè)model文件。

注意：上述提到的“另存為”“拷貝”，并不是美術(shù)手動(dòng)操作的，是由Pipeline 系統(tǒng)操作的（類比一下P4V客戶端對(duì)于的按鈕）。

如果你家的NAS各方面性能承受不住這么用，丐版NAS可以是這種工作方式：

首先美術(shù)需要把?NAS映射為同一個(gè)盤符，比如?x:/。

美術(shù)的rig文件，引用的是NAS上的model文件，做完之后上傳（拷貝）到NAS的publish文件夾，其他美術(shù)下載（拷貝）rig文件，打開也是沒有任何問題的。

上述提到的“上傳”“下載”“拷貝”，并不是美術(shù)手動(dòng)操作的，是由 Pipeline 系統(tǒng)操作的（類比一下P4V客戶端對(duì)于的按鈕）。

這個(gè)話題結(jié)束，我們繼續(xù)討論三種類型文件。

工程文件 Workfile

通常是?DCC?的?project file，是美術(shù)制作的文件。

這里?Pipeline?主要就是解決：

• 跟項(xiàng)目管理系統(tǒng)中，Task進(jìn)行關(guān)聯(lián)。尤為重要！Asset > Task > workfile

• 標(biāo)準(zhǔn)命名：美術(shù)僅提供文件命名的描述部分descriptor，命名的其他部分則由Pipeline?系統(tǒng)來(lái)完成。比如 goblin 的某個(gè)動(dòng)畫文件，美術(shù)需要提供類似walk這樣的描述，則該文件會(huì)被自動(dòng)命名為char_goblin_ani_walk_v001.ma，文件命名規(guī)范需要根據(jù)項(xiàng)目資產(chǎn)特點(diǎn)來(lái)制定。

• Publish（升級(jí)）：將?workspace文件進(jìn)行升級(jí)，并上傳到文件管理系統(tǒng)中。此處也需要上傳適當(dāng)?shù)?metadata 到 Pipeline 數(shù)據(jù)庫(kù)里，比如它的上個(gè)版本是誰(shuí)，比如它依賴引用了哪些文件。

• Checkout（下載）：從文件管理系統(tǒng)中下載指定版本文件到?workspace下，原因可能是自己workspace刪除了，或者是A的任務(wù)交給B做了，B需要從文件管理系統(tǒng)中下載A提交的文件。

• 版本回退：把文件回退到某個(gè)之前的版本，基于之前的版本繼續(xù)制作。

• 質(zhì)檢：文件在publish之前，需要做一些檢查，以防文件有垃圾節(jié)點(diǎn)之類的，造成文件打不開。

此部分的工作，跟用哪個(gè)DCC，相關(guān)度很小，主要是跟文件管理系統(tǒng)有關(guān)，基本就使用了DCC?的?new、open、save、save_as?這幾個(gè)?API。

所以，我們可以得出結(jié)論：

workfile類型的文件，跟行業(yè)、公司、項(xiàng)目類型、環(huán)節(jié)，基本無(wú)關(guān)，Pipeline?系統(tǒng)可以輕松管理。

媒體文件 Dailies

通常是視頻或圖片，體現(xiàn)工作內(nèi)容，用于給導(dǎo)演、總監(jiān)、主美、組長(zhǎng)等進(jìn)行 Review/監(jiān)修/審查。

這里?Pipeline?主要就是解決：

• 標(biāo)準(zhǔn)命名：一般跟對(duì)應(yīng)的?workfile?名字一致。

• 標(biāo)準(zhǔn)化圖片、視頻：統(tǒng)一的水印、分辨率、色彩轉(zhuǎn)換、編碼方式等等

• 最好附帶輔助工具，如三維軟件拍屏工具、截圖工具、錄屏工具、拼圖工具......

• publish 到 Review 系統(tǒng)中，并且記錄該文件依賴的?workfile?信息到?Pipeline?數(shù)據(jù)庫(kù)中。

此部分的工作，跟用哪個(gè)DCC，相關(guān)度很小，主要是跟 Review 系統(tǒng)有關(guān)。

所以，我們可以得出結(jié)論：

dailies 類型的文件 ，跟行業(yè)、公司、項(xiàng)目類型、環(huán)節(jié)，基本無(wú)關(guān)，Pipeline 系統(tǒng)可以輕松管理。

交換文件 Element

通常是第三方格式，用于不同DCC之間、不同人員、不同環(huán)節(jié)之間進(jìn)行資產(chǎn)交換。

這個(gè)同時(shí)也是流程千變?nèi)f化的主力部隊(duì)，是跟行業(yè)、公司、項(xiàng)目類型、環(huán)節(jié)，大大相關(guān)。

影視的 DCC 除此之外還有：Hiero、Clarisse、Katana、Mari、ZBrush、Modo、SP、SD、Photoshop、Pftrack、SynthEye... ...

這里還沒扯上環(huán)節(jié)，如此排列組合，也是大家經(jīng)常說(shuō)的“我們項(xiàng)目不一樣”。

這里?Pipeline?主要就是解決：

• 導(dǎo)出：不同DCC的不同環(huán)節(jié)導(dǎo)出不同的第三方格式文件。記得要記錄?workfile?的信息。

• 質(zhì)檢：很容易理解，我們不能把有問題的資產(chǎn)引入系統(tǒng)中。

• 導(dǎo)入：不同DCC的不同環(huán)節(jié)導(dǎo)入不同的第三方格式文件。

• 更新通知：當(dāng)有新版本element導(dǎo)出時(shí)，可以通知到使用了此element?的workfile（的擁有者）

• 更新：有新版本element時(shí)，用戶可以更新，最好是一鍵，同時(shí)用戶也可以切換到任意舊版本element。

• 導(dǎo)入、導(dǎo)出的腳本是一對(duì)，最好也有版本控制，這樣制作中途element有變動(dòng)，比如參數(shù)不同了，舊版本導(dǎo)出腳本導(dǎo)出的element，可以使用舊版本的導(dǎo)入腳本進(jìn)行導(dǎo)入，減少了腳本要各種兼容歷史遺留的問題。

下一篇文章，我們展開討論一下，如何應(yīng)對(duì)千變?nèi)f化的element

緩存文件 Cache

咦？怎么冒出了一個(gè)你沒有分類出來(lái)的文件？！

在影視，一般是一種自產(chǎn)自用的文件，比如把 houdini 一大堆的節(jié)點(diǎn)，解算出緩存，然后再導(dǎo)入回houdini 中，用結(jié)果繼續(xù)進(jìn)行節(jié)點(diǎn)連接。這種文件的特點(diǎn)是占用空間大，刪除可再次生成，在項(xiàng)目結(jié)束進(jìn)行打包的時(shí)候，完全不需要備份。

游戲還有一種 cache，中間轉(zhuǎn)換文件，例如 fbx 導(dǎo)入八猴進(jìn)行烘焙，再把烘焙出來(lái)的文件導(dǎo)入到 sp 等進(jìn)行其他貼圖繪制。

八猴文件我們可以直接通過其 python api 動(dòng)態(tài)生成，這個(gè)八猴文件可以考慮到底留不留下，留下的話方便萬(wàn)一標(biāo)準(zhǔn)參數(shù)下烘焙效果不理想，可以手動(dòng)調(diào)整。推薦根據(jù)實(shí)際情況。

和影視不同的地方：

游戲行業(yè)制作環(huán)節(jié)大大縮減，一個(gè)人需要負(fù)責(zé)多個(gè)環(huán)節(jié)，比如有些項(xiàng)目動(dòng)畫師也得做綁定。需要我們幫助美術(shù)減少修改操作步驟，跨軟件 Live Link 進(jìn)行數(shù)據(jù)實(shí)時(shí)傳遞。

其次，各環(huán)節(jié)資產(chǎn)最終都是要在引擎里看效果的，所以要盡可能拉近美術(shù)和引擎的距離，依舊需要各種 Live Link。

依賴關(guān)系

element、dailies?都是從workfile產(chǎn)生的，那么有一個(gè)原則，只要有?dailies/element?一個(gè)版本，就必須保存產(chǎn)生該文件的workfile，因?yàn)?code>dailies會(huì)被別人（總監(jiān)）看到，element?會(huì)被別人（其他美術(shù)）用到，但凡涉及到文件被其他人“觀察”了，就要保存其源文件，以便“還是覺得半個(gè)月前看到的那個(gè)版本更好”“我用的xxx版本是沒問題的”時(shí)，可以找到源文件，branch 出去繼續(xù)做。

還有一點(diǎn)：

當(dāng)：只是導(dǎo)入engine 時(shí)，參數(shù)設(shè)置需要更新，那么?element不用重新出，只需重新導(dǎo)入engine 即可，如果導(dǎo)入時(shí)已經(jīng)記錄過了引擎資產(chǎn)<->element的關(guān)系，那么此時(shí)就可以對(duì)涉及到的引擎資產(chǎn)，自動(dòng)化批量重新導(dǎo)入。

當(dāng)：element內(nèi)容不夠了（雖然已經(jīng)盡最大可能確保內(nèi)容無(wú)損了），workfile不用變，美術(shù)無(wú)需打開文件修改，只需重新導(dǎo)出?element，再導(dǎo)入engine，這兩步，大概率也可以自動(dòng)化批量處理。

當(dāng)我們記錄完備了這幾種文件的依賴關(guān)系，那么我們很容易就可以繪制出如下的關(guān)系圖：

引擎資源

整個(gè)項(xiàng)目的所有資源都需要導(dǎo)入到游戲引擎中，它同時(shí)也是最末端，由它最終打包出成品。

這個(gè)特性非常類似影視的?Finishing System，DaVinci Resolve 軟件。

DaVinci Resolve is the world's only solution that combines editing, color correction, visual effects, motion graphics and audio post production all in one software tool!

最近版本增加了遠(yuǎn)程協(xié)作工具和基于云的工作流程，這簡(jiǎn)直就是真·大型·多人·在線·實(shí)時(shí)協(xié)作（MMO-DCC???）

進(jìn)入到了引擎的美術(shù)資產(chǎn)，后續(xù)就在引擎里自產(chǎn)自銷，項(xiàng)目的引擎工程會(huì)有真·版本管理系統(tǒng)如P4V、SVN等，所以針對(duì)引擎里的美術(shù)資產(chǎn)管理，我們就只管理 metadata。

Messiah 這點(diǎn)非常爽，二進(jìn)制數(shù)據(jù)和metadata完全分離，metadata全部存放在 xml 里面，這讓我們的提取工作量和難度減少了個(gè)數(shù)量級(jí)。（但是拆分和寫入不合理，移動(dòng)下資產(chǎn)就有十幾文件被修改了你是認(rèn)真的嗎，這是要了美術(shù)協(xié)作的命?。?/span>

但一點(diǎn)都不簡(jiǎn)單，復(fù)雜度非常高，要跟引擎里的各種模塊編輯器打通，比 level editors, animation blend-tree authoring tools, state machine editors 等等，確實(shí)是一個(gè)非常艱巨的工作。

一個(gè)動(dòng)畫師修改了一段動(dòng)畫的時(shí)長(zhǎng)，它會(huì)影響到游戲的很多地方，那到底是哪些地方？

并不是說(shuō)太復(fù)雜了太艱巨了所以我們就不做了，而是因?yàn)樘珡?fù)雜了太艱巨了，所以我們才去做。

當(dāng)然沒必要非得要萬(wàn)事俱備才開始做，而是邊做邊解決，能解決多少就解決多少。堅(jiān)定不移的做難而正確的事。

在這個(gè)方面我還是一個(gè)新手，求求各位游戲大佬，多多分享些經(jīng)驗(yàn)出來(lái)。

當(dāng)我們把各種類型文件、各種環(huán)節(jié)文件都安排得井井有條，相應(yīng)的metadata都搜集完備，資產(chǎn)管理系統(tǒng)，這不就已經(jīng)完成了七七八八了嗎？

接下來(lái)，就是怎么展示給用戶的事情了。我們需要一個(gè)：

資產(chǎn)瀏覽器

可以獨(dú)立運(yùn)行版的，不打開任何DCC、不開游戲引擎、暫時(shí)不用下載任何資產(chǎn)文件，就可以瀏覽資產(chǎn)的?Asset Browser！

找到資產(chǎn)

這個(gè)瀏覽器，它必須具備花式條件搜索、模糊搜索、收藏、打tag等常見資產(chǎn)庫(kù)的功能。

可以根據(jù)用戶的需求，有多種瀏覽方式：

• 陣營(yíng) -> 種族 -> 性別 -> 資產(chǎn)

• 發(fā)布版本 -> 英雄 -> 皮膚 -> 資產(chǎn)

• 地圖 -> 區(qū)域 -> 城市 -> 興趣點(diǎn) -> 建筑 -> 資產(chǎn)

• ...

把玩資產(chǎn)

當(dāng)定位到具體的資產(chǎn)后，我們要展示這個(gè)資產(chǎn)方方面面的信息：

• 查看它的原畫設(shè)計(jì)

• 它的模型、模型的工程文件最新是哪個(gè)版本

• 總共提交過多少次?Review

• 綁定是哪個(gè)美術(shù)做的，什么時(shí)間完成的

• 它有多少面、有無(wú)骨骼、貼圖幾張

• 它被放置在了哪些關(guān)卡，哪些位置，被放置了多少次，能在游戲地圖中標(biāo)識(shí)出來(lái)

• 可以用DCC打開它的任意環(huán)節(jié)的工程文件（此時(shí)才需要下載該文件）

• ......

這里能做的事情太多太多了，一定要留有API接口，方便其他TA、TD，或者自己，隨時(shí)新增更多功能，因?yàn)殛P(guān)于資產(chǎn)的所有信息都在，你可以對(duì)它為所欲為。

這個(gè)?Asset Browser，最好是可以在DCC 和引擎里打開；選中DCC 和引擎中的某個(gè)資產(chǎn)，可以獲取該資產(chǎn)的詳細(xì)信息；可以根據(jù)上下文和某些規(guī)則，比如是哪個(gè)城市，自動(dòng)推薦合適的建筑物。發(fā)揮你的腦洞，發(fā)揮美術(shù)的腦洞。

好了，篇幅夠長(zhǎng)了，今天就先到這里。

我們前幾篇文中，一直提到，Pipeline?在這里要做什么、那里要做什么，感覺零零散散的，可能大家腦中還是拼不起來(lái)，能不能系統(tǒng)說(shuō)一下，Pipeline?到底要有哪些功能？

敬請(qǐng)期待下一篇。