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