Unity は完全に自動的なアセットパイプラインを持っています。アセット元となるpsdファイルやfbxファイルが変更されたら,Unityは自動的に再インポートします。ファイルからインポートされたデータはすぐに内部フォーマットに変換され保存されます。
このアセットパイプラインのいいところは,実用的な逐次の再読み込みする点と,目に見えているアセットのゲーム内の同期が保証されている点です。ただ一方でこの機能にはいくばくかコストがかかります。どのアセットも修正されたら,すぐに必ず再インポートされます。長い間隔が空いてSCMから最新のデータを取得した後になると,他のチームメンバーの修正または作成した全てのアセットを再インポートするために長時間待つことになります。また,他のプラットフォームへ移動する度に,多くのアセットを再インポートすることになります。
このアセットをインポートする時間を,Cache Server でインポートされたアセットデータをキャッシュすることで,ドラスティックに縮めることができます。
それぞれのアセットインポートは以下に基づいてキャッシュされます。
以上のどれかが変更された場合,アセットは再インポートされるか,キャッシュサーバからダウンロードされます。
PreferenceでCache serverをオンにすると,複数のプロジェクト間のアセットインポートもシェアすることも可能です。
気をつけていただきたいのは,いったんCache Server を設定すると,この過程は全て自動的になり,追加のワークフローはありません。何ら手間を必要とせずに,インポートするための時間を単純に短縮してくれるでしょう。
キャッシュサーバを設定する方法はかぎりなく簡単です。やることはPreferencesの「Use Cache Server」をオンにすることと,ローカルマシンの Unity Editor にどこに Cache Server があるのか教えてあげることです。
この項目はMacでは
,PCでは にあります。もしローカルマシンにキャッシュサーバがホスティングされているなら,サーバーアドレスは localhost にして下さい。ただ,ローカルPCではハードディスクサイズの制限があるため,キャッシュサーバは他のマシンにインストールすることをおすすめします。
管理者は キャッシュされたアセットを置いておくための Cache Server マシンの設定する必要があります。
以下の通りにしてください:
Cache Server はとても大きいストレージを持つ信頼できるマシンが必要です(複数のバージョンのインポートされたリソースを保存しておくため,プロジェクト自体のサイズ以上に大きいでしょう)。 もしハードディスクが Cache Server でいっぱいになったらパフォーマンスは落ちるかもしれません。
Unityが提供している .sh
や .cmd
のスクリプトはサーバーでサービスとしてセットした方が良いでしょう。
そうすることで,いつでもキャッシュサーバは安全に中断や再起動ができます。
スクリプトをダブルクリックで単にCache Serverを起動すると,スクリプトの同階層に “cache” ディレクトリが作られ,そこにデータが保存されます。キャッシュディレクトリは50GBまで大きくなることが許可されています。このサイズの設定やデータの場所は以下のコマンドラインオプションで変更できます:
./RunOSX.command --path ~/mycachePath --size 2000000000
–path はキャッシュのパスで, –size は最大キャッシュサイズ(byte)です。
最高のパフォーマンスを得るために,インポートされたプロジェクト全体が網羅できるだけの十分なメモリ容量が必要です。加えて高速なハードディスクと高速なイーサーネット接続があるのがベストでしょう。ハードディスクは十分に空き容量がある方がより良いでしょう。ただ一方キャッシュサーバはCPUパワーはほとんど必要ではありません。
Cache Serverのバージョンコントロールとの主な違いは,キャッシュ化されたデータはいつもローカルでリビルドされたもの,ということです。これは単純なパフォーマンス改善のためのツールということです。この理由でキャッシュサーバはインターネットでの利用は役に立ちません。分散しているチームならば,それぞれのロケーションでキャッシュサーバを立てるべきでます。
Linux か Mac OS X マシンでキャッシュサーバを走らせるべきです。キャッシュサーバがデータを保存する際にファイルロックが引き起こされる問題があり,Windowsのファイルシステムはあまり最適化に良くないのです。Linux や Mac OS Xではそのようなことがありません。
キャッシュサーバは自動的に一定周期に使われなくなったアセットを削除します(もちろん再度必要になれば,次に使われる間に再び作られるでしょう)。
キャッシュサーバはソースバージョンコントロールと切り離してデザインされているので,Unityの Asset Serverに制限されることはありません。
Unity は一つのアセットをインポートしようとする際,元となる全てのデータのMD5ハッシュを生成します。
例えばテクスチャでは,以下のように成り立っています:
もしCache Serverに保存されているハッシュが違っていたら,アセットは再インポートされるか,キャッシュ化されたバージョンをダウンロードされます。クライアント側の Unity editor は必要な時にサーバーからアセットをプルする(持ってくる)だけです。つまりアセットはそれぞれのプロジェクトにプッシュすることはありません。
キャッシュサーバ は依存関係を関与しません。Unityのアセットパイプラインは依存関係のコンセプトを扱いません。アセット間の依存は避けるように作って下さい。AssetPostprocessors はアセットインポートを自分用にカスタマイズする共通のテクニックです。 例えば,fbxファイルの決められた名前やタグで,GameObjectにMeshColliderを追加したりできます。
AssetPostprocessors を使って,依存関係を明示的にすることは簡単にできます。例えば,テキストファイルからインポートされたゲームオブジェクトにコンポーネントを追加するデータを使います。これはCache Serverではサポートされません。もしキャッシュサーバを使いたいなら,プロジェクトフォルダの他のアセットへの依存関係を排除しなければなりません。キャッシュサーバは自分用のPostprocessorでの依存関係について何も知りませんので,古いバージョンのアセットをそのように変更しても知ることができないのです。
実践的な話で言えば,キャッシュサーバで動かすためのアセットポストプロセッサを走らせる方法はたくさんあります。 例えば:
マテリアルを変更するには既知のトラブルあります。キャッシュサーバを使っていると,Unityはマテリアル参照を維持します。しかしポストプロセスがpostprocessing で呼ばれないので,キャッシュサーバを通してインポートされたモデルでは,マテリアルの内容は変更されることはありません。そのため,キャッシュサーバがある場合とない場合とで違う結果を得ることになるでしょう。これを避けるにはディスクに既に存在するマテリアルは修正しないことです。
サーバーにキャッシュされないいくつかのアセットの種類はあります。キャッシングスクリプトによって作られたものは,サーバーでは無視されるので,キャッシュされません。(Maya, 3D Max等の)3Dモデリングソフトで使われているネイティブのファイルはそのアプリケーション自体を使ってFBXにコンバートされます。現在サーバーでは,ネイティブのファイルとインポートプロセスで生成されたFBXファイルのどちらもキャッシュ化しません。しかし,モデリングソフトからFBXにエクスポートされたファイルをUnityプロジェクトに追加することでキャッシュ化が可能になります。