上一篇我們講了?Production Management，提到讓大家投票選擇可以滿足要求的軟件，投票五花八門，我們收斂一下，在影視行業(yè)，體量大點(diǎn)的公司，選用的基本是ShotGrid?或?Ftrack，而中小型公司市場，則基本被?CGTeamwork?所壟斷（壯哉我大國產(chǎn)軟件?。。?，當(dāng)然，據(jù)后臺(tái)留言，也有用 excel 管的（在此聲明，我絕對沒有看不起 Excel 的意思，我認(rèn)為?Excel?是人類最偉大的發(fā)明之一，我開發(fā)的最多的、且最受歡迎的插件，都是關(guān)于?Excel?的?。?。

今天我們來討論數(shù)據(jù)管理，是我鴿了你們嗎？不，是我在寫著寫著，還沒提到具體的美術(shù)流程，就又三千多字了。簡略一筆帶過吧，又怕沒解釋到位，造成信息不對等。想想我沒必要非得立什么必須三篇寫完這種目標(biāo)，盡量說明白才是目的，所以您受累，再等等下一篇資產(chǎn)管理。

以下是正文。

我們從一個(gè)我最近被問道的問題說起：

那我的工程文件，是上傳到?ShotGrid?里嗎？

這個(gè)問題，簡單地回答是或不是，遠(yuǎn)遠(yuǎn)不夠。所以這篇索性就說個(gè)明白。預(yù)警一下，這篇確實(shí)有點(diǎn)枯燥乏味。

快搬小板凳，聽我說，謝謝你，因?yàn)橛心?.. 很久很久以前.....

Data vs Metadata

Data?，在我們討論的上下文中，指的是我們能在硬盤上看到的具體文件，比如?.max?、?.mb?、?.hip?文件.

這些文件有的是二進(jìn)制文件，可以理解為用記事本打開，里面都是亂碼，人根本就看不懂；

有些是非二進(jìn)制文件，常常是類似?xml?、?json?、?yaml?等，可以理解為用記事本打開，里面都是人類可讀的單詞符號(hào)，偶爾你還能“喲這不是我的節(jié)點(diǎn)名字嘛”

Metadata?，元數(shù)據(jù)，是描述數(shù)據(jù)的數(shù)據(jù)。

比如說?data?是你這個(gè)活生生的人，?Metadata?就是你的簡歷內(nèi)容，什么身高、體重、身份證號(hào)等等，在沒看到你這個(gè)人站在我面前之前，我通過你的?Metadata?（從你簡歷上看到的），就可以掌握個(gè)大概，有時(shí)候就能判斷出你是不是我要招的人，等我具體想深入了解你的時(shí)候，再把你喊過來當(dāng)年交流（就是用相應(yīng)軟件打開文件）。

玩攝影的朋友可能更熟悉，Data?就是你拍的圖像文件，Metadata是這張照片的 ISO、焦距、光圈、拍攝時(shí)的地點(diǎn)、曝光......

在我們討論的上下文中，一般是這幾類：

• 文件本身的信息：創(chuàng)建時(shí)間、修改時(shí)間、大小、創(chuàng)建者、存放路徑、文件格式

• 文件內(nèi)容的信息：面數(shù)、有沒有UV、有沒有骨骼、多少根、在level 里的世界坐標(biāo)、燈光的亮度、相機(jī)的景深

• 人為添加的信息：“這個(gè)文件我增加了地面模型”、“這個(gè)版本把角色的腿拉長了一些”

• 文件的依賴關(guān)系：模型文件依賴的貼圖文件們、動(dòng)畫 reference了哪個(gè)綁定文件、關(guān)卡里面放置的資產(chǎn)們

一定要根據(jù)你們的需要，選擇真的要經(jīng)常查看的?Metadata

存放方式

這兩種 data，存放方式有所差別。

Data

Data?通常會(huì)比較大，毫無疑問，是存放在文件存儲(chǔ)系統(tǒng)，比如我們的硬盤、?NAS?、百度網(wǎng)盤、?P4V?、?SVN?、?Git?等等地方。

在視效行業(yè)，Data?文件的存儲(chǔ)，基本采用?NAS?。

存儲(chǔ)是影視公司的頭等大事，它涉及訪問速度、寫入效率、快照系統(tǒng)、日志系統(tǒng)、權(quán)限管理、吞吐量、存儲(chǔ)帶寬、協(xié)議延遲、冷熱數(shù)據(jù)分層、分布式存儲(chǔ)等等，總而言之，不是簡簡單單的找個(gè)地方放文件就行了，是個(gè)很花錢的東東，這一塊是我的知識(shí)盲區(qū)，我 IT 野哥當(dāng)年是跟我科普的：

IT 大哥：要不是咱們公司咬咬牙買了?isilon，舊存儲(chǔ)根本扛不住《上海堡壘》項(xiàng)目啊。

（你別笑... ...《上海堡壘》視效量很大的）

我：為啥呀，多買幾百塊硬盤不就行了唄！

IT 大哥：咱們舊存儲(chǔ)服務(wù)器相當(dāng)于老式火車，車廂全靠火車頭帶，能掛載多少節(jié)有極限，不是想擴(kuò)容就無限擴(kuò)的；剛買的這個(gè)是復(fù)興號(hào)，每節(jié)車廂都自帶動(dòng)力，想擴(kuò)容多少都沒問題。

而游戲這邊，美術(shù)資產(chǎn)分為：

• 進(jìn)引擎之前的，就是.max?、?.fbx?、?.mb、?.spp?等等文件。這跟影視的沒有任何區(qū)別。

• 進(jìn)引擎之后的，就是游戲引擎項(xiàng)目工程了。

進(jìn)引擎之前的文件

我在游戲這邊見過的管理軟件有?P4V?、?Git?、?SVN?、Alienbrain?以及，emmm....沒有[攤手]，只存放在美術(shù)本地硬盤上... ...

就算是使用了上述的存儲(chǔ)管理，也并不是每個(gè)工程文件版本都上傳的，大部分還是項(xiàng)目組強(qiáng)制要求，必須至少傳一個(gè)最終版，上下游交接的文件倒還是有上傳的。

提示！影視公司的理念：Artist 制作的所有文件，都是公司的數(shù)字資產(chǎn)，必須 publish 到存儲(chǔ)服務(wù)器！

當(dāng)然啦，這是缺少文件夾放置規(guī)范和自動(dòng)化工具，換位思考一下，沒有一鍵無腦上傳工具，你讓我每個(gè)版本都上傳，我也覺得很煩。

進(jìn)引擎之前的文件存儲(chǔ)方式，建議使用

• NAS?，推薦指數(shù)，五顆星，下面一個(gè)段落專門講一下。

• P4V?，推薦指數(shù)，三顆星。專門給游戲行業(yè)設(shè)計(jì)的。尤其是，如果引擎工程也使用?P4V?了的話，我不清楚它的收費(fèi)模式，但從美術(shù)角度講，可以減少一個(gè)需要理解的系統(tǒng)。如果有人能說服我游戲公司真的不能用?NAS?，那么?P4V?可以提升到四顆星。

• 云儲(chǔ)存?，推薦指數(shù)，一顆星。類似百度網(wǎng)盤，但不要用百度網(wǎng)盤！如果你不知道為什么就證明你根本不適合它。對象存儲(chǔ)這塊，影視有強(qiáng)大的、專業(yè)的、專門服務(wù)TD 的 IT，都還沒敢全換，只敢稍微嘗試一下（跟外包進(jìn)行文件交接），除非你能找來阿里云、騰訊云存儲(chǔ)的核心開發(fā)者專門來給你服務(wù)。

• SVN?、?Git?，推薦指數(shù)，零顆星。這倆就不是干這個(gè)事的！相當(dāng)于你讓一個(gè)模型師去設(shè)計(jì)汽車的發(fā)動(dòng)機(jī)，原因是他們都用3ds Max來建模。就我上面提到的存儲(chǔ)要涉及的功能特性，他們兩位能有的寥寥無幾。

單獨(dú)介紹一下 NAS

使用方式：每個(gè)美術(shù)，把?NAS?服務(wù)器映射為統(tǒng)一的一個(gè)盤符，比如?x:/?,相當(dāng)于美術(shù)插了一塊“移動(dòng)”硬盤，跟 D 盤一樣。只是這塊盤，每個(gè)人都有，而且都是同一個(gè)。

入門：美術(shù) A 創(chuàng)建了個(gè)?x:/aaa/bbb.txt?，美術(shù) B 那里馬上也有了?x:/aaa/bbb.txt

高級(jí)：美術(shù) A 建了個(gè)模型?x:/prop_desk_model_v001.mb?，然后里面引用了幾張貼圖?x:/prop_desk_normal.tga?x:/prop_desk_diffuse.tga?，保存。美術(shù) B 此時(shí)打開x:/prop_desk_model_v001.mb，不會(huì)有任何問題，全程沒有上傳下載的步驟。(這里只是簡單舉例，影視并不是這么粗暴使用的，但就是這個(gè)理兒哈。)

在第一篇文章?中提到，不能責(zé)怪游戲TA 工具部署那么繁瑣。

影視的工具、Pipeline系統(tǒng)代碼直接部署在NAS?上，把?NAS?上的代碼文件更新了，工具就更新了（ps：工具里不要長時(shí)間 open 一個(gè)代碼里面的文件，要及時(shí) close），然后這個(gè)文件夾權(quán)限鎖死，只有自動(dòng)部署的CI 機(jī)器有權(quán)限寫入，防止美術(shù)誤刪誤改。

另外有一點(diǎn)，因?yàn)槲募挤旁诹?NAS?上，如果網(wǎng)速夠快，美術(shù)直接在?NAS?上制作，本地的硬盤就不會(huì)被占了，只需擴(kuò)容?NAS?即可。

對比一下?P4V?，美術(shù)制作過程中的文件都在本地，要是跟其他人交換文件，首先需要?jiǎng)e人上傳（這個(gè)上傳過程可不簡單），還得把別人的文件下載到他本地，也就是說，同一個(gè)文件，出現(xiàn)在了多個(gè)硬盤里，不浪費(fèi)嗎？我見過一個(gè)項(xiàng)目才是初期，打開美術(shù)的資源管理器，一片紅彤彤的硬盤空間告警，然后每個(gè)人都去再次申請?jiān)黾觽€(gè)人硬盤，不浪費(fèi)嗎？

P4V?主打的版本管理，在 DCC 這里，它沒用啊，二進(jìn)制文件它 merge 不了，就算是非二進(jìn)制文件，它也 merge 不了，你讓美術(shù)去解決兩個(gè) sd 文件的沖突？美術(shù)打爆你的狗頭！

你可能說，那我就喜歡我依賴的文件，一直都叫?prop_desk_model，可以自動(dòng)更新 ，你說的?NAS?存儲(chǔ)，它今天叫?prop_desk_model_v0002?，明天又多出一個(gè)新版本叫?prop_desk_model_v0003?，我還得手動(dòng)更新呢。

這位客官請留步，首先，誰告訴你?NAS?不能搞文件一直叫?prop_desk_model?，而且永遠(yuǎn)是最新版。?symbolic link?了解一下。

其次，這個(gè)更新的確有自動(dòng)更新，和手動(dòng)更新兩種，但你?P4V?也不是自動(dòng)更新的呀（不二次開發(fā)的話），也得點(diǎn)一下更新按鈕。

最后，我們不使用?symbolic link?是因?yàn)榈暨^坑。美術(shù) B 用了美術(shù) A 的文件，干的好好的，第二天，文件打不開了，經(jīng)排查，是美術(shù) A 更新的文件導(dǎo)致的。然后有一天美術(shù)C 也要用美術(shù) A 的文件，并提出個(gè)修改，美術(shù)A 修改了，但是美術(shù) B 并不需要這個(gè)修改，又悲劇了......

所以，我們最后選擇了每個(gè)版本都是單獨(dú)的文件，通過文件名里面帶著版本號(hào)來進(jìn)行管理。這個(gè)也符合美術(shù)的直覺。

Pipeline?系統(tǒng)自動(dòng)獲取是否有新版本，詢問美術(shù)是否更新，然后美術(shù)可以一鍵更新，美術(shù)也可以隨時(shí)回溯到任意版本，數(shù)據(jù)隔離美滋滋。

說了這么多，但?NAS?在游戲這邊竟然屬于聞所未聞 ，大公司是有一些 IT 安全方面的考量，中小公司我又完全不了解。

的確，游戲行業(yè)進(jìn)引擎之前的文件，沒有影視整個(gè)公司的多（不能跟項(xiàng)目比，影視有的項(xiàng)目也可小了），那你?NAS?硬盤可以買少點(diǎn)??！

難道是因?yàn)樵L問速度？那我們可以在本地硬盤制作，完成后 publish 到?NAS?上啊。

請明白的人務(wù)必幫我解惑，求求你了。

（2023年2月更新，據(jù)悉，某易已經(jīng)開始使用這種方式了，反饋說確實(shí)香）

進(jìn)引擎之后的文件

游戲項(xiàng)目工程，必須必須必須選擇一個(gè)有版本管理功能的軟件，如?P4V?、?SVN?、?Git?，這一點(diǎn)大家都沒有疑問。

Metadata

Matadata?則存在兩種方式，以?json?或者?xml?文件形式，一般存放在它要描述的?Data?旁邊，看起來可能是這樣：

prop_desk_model_v002.max?

prop_desk_model_v002.json

另一種方式，則是將?Metadata?存入數(shù)據(jù)庫里面。

存放在文件中：

優(yōu)點(diǎn)：易用；渲染農(nóng)場訪問不會(huì)擁擠；

缺點(diǎn)：要么是海量小文件（每個(gè)資產(chǎn)的每個(gè)版本對應(yīng)一個(gè)文件）；要么是少量的巨大文件（一個(gè)資產(chǎn)一個(gè)文件）。造成訪問和查詢非常慢，而且風(fēng)險(xiǎn)大，有文件編輯占用等等問題

存放在數(shù)據(jù)庫中：

優(yōu)點(diǎn)：支持?jǐn)?shù)據(jù)量大；查詢超快；可以校驗(yàn)質(zhì)檢，確保數(shù)據(jù)有效性；什么冷備熱備災(zāi)備的，一直可用；隨時(shí)應(yīng)對用戶量的變化，橫向豎向擴(kuò)展都沒問題

缺點(diǎn)：比文本文件復(fù)雜；要是掛了，信息可就丟失了；部署啊，服務(wù)器啊，這些工作都需要做；如果外網(wǎng)能訪問，還要做賬號(hào)權(quán)限管理；還得提供 UI，或者API；

看你們的實(shí)際需求吧。

你非要問我的意見，那我肯定是選擇數(shù)據(jù)庫。

為啥不用“存放在文件中”方式呢，當(dāng)我們要搜索的時(shí)候，比如過濾出模型面數(shù)超過2千的武器，這種方式基本就是去遞歸掃描武器文件夾里面，模型文件旁邊的?metadata文件，打開、讀取，哎呀不符合，下一個(gè).....資產(chǎn)量稍微上去一點(diǎn)，可能幾分鐘、十幾分鐘過去了，突然我覺得，我也不是那么的想知道超過2千面數(shù)的武器有哪些了。雪上加霜的是，如果是存放在了?P4V?、?SVN?、Git?，本地都沒有下載全部資產(chǎn)，還搜索個(gè)雞兒??！

那我就去?P4V?服務(wù)器上搜嘛！

還記得我上篇文章提到過：

ShotGrid?和?Ftrack?都支持?jǐn)?shù)據(jù)庫自定義（可能程度不一樣），一魚三吃，白得一個(gè)數(shù)據(jù)庫！而且還有 UI、API、賬號(hào)權(quán)限管理...存放在數(shù)據(jù)庫方式的缺點(diǎn)，全解決了，還不用額外花錢！

正所謂：此物只應(yīng)天上有，人間難得幾回尋

嚴(yán)正聲明，?ShotGrid?和?Ftrack?與本人無任何交易！

非說有點(diǎn)私心的話就是希望項(xiàng)目用了，就可以省去TD 一大部分工作量，還能拿它去當(dāng)人才庫、資產(chǎn)庫、材質(zhì)庫、日報(bào)管理、Pipeline團(tuán)隊(duì)的開發(fā)管理、各種工具的后臺(tái)。

書歸正題。還有個(gè)問題。

data?和?metadata?有時(shí)候不是那么好區(qū)分，尤其是那種整合拼裝其他二進(jìn)制文件的軟件 ，同時(shí)也不把引用的文件內(nèi)容封裝寫入到自己的工程文件里面的，比如?Nuke Studio、Substance Designer?等。還有，游戲引擎的項(xiàng)目工程！

這時(shí)候，我們就要發(fā)自內(nèi)心地好好想想，到底哪些數(shù)據(jù)，是我們不想開 data 文件就想知道的信息，只提取這部分的。

題外話：這事做到極致的就是達(dá)芬奇軟件（DaVinci Resolve），它的工程文件就是個(gè)數(shù)據(jù)庫??！

命名規(guī)范

這包含文件命名規(guī)范和文件夾規(guī)范。具體如何去制定就再說吧... ...看有沒有人愿意看

這里就提一下它的重要性。

規(guī)范命名主要的目的是，給資產(chǎn)文件提供一個(gè)全局唯一的標(biāo)識(shí)。

• 當(dāng)我們提到一個(gè)資產(chǎn)的時(shí)候，就知道在哪里可以找到對應(yīng)的文件。

• 當(dāng)我們看到文件的名字，就可以確定資產(chǎn)的位置和類型。

• 有了規(guī)范的層級(jí)和命名，Pipeline 工具就可以自動(dòng)化幫你上傳下載、導(dǎo)入導(dǎo)出。

Metadata 怎么記錄

最好是美術(shù)使用?Pipeline?工具，在文件被上傳/同步到服務(wù)器上時(shí)，自動(dòng)提取出來，自動(dòng)上傳到咱們的metadata?數(shù)據(jù)庫里。

額外的也需要用戶輸入，比如本次文件修改的內(nèi)容。雖然我過往的經(jīng)驗(yàn)是，搜集上來的都是“修改了一下”、“1111”這種無效信息。但我們可以在填寫的輸入框里，自動(dòng)填充一下模板，引導(dǎo)美術(shù)大大們寫上合適的內(nèi)容。

講到這里，你的頭腦已經(jīng)有點(diǎn)發(fā)脹，我們該怎么管理??？！沒有頭緒??！從哪兒下手?。?！

敬請期待下一篇“資產(chǎn)管理”。

四千五百多字，辛苦大家閱讀了。鞠躬。

差點(diǎn)忘了.... 開頭的問題，你知道答案了嗎？