YAML クラス ID リファレンス
スクリプトでアセットを変更する

キャッシュサーバー

Unity は完全に自動的なアセットパイプラインを持っています。アセット元となる psd ファイルや fbx ファイルが変更されたら、Unity は自動的に再インポートします。ファイルからインポートされたデータはすぐに内部フォーマットに変換され保存されます。

このアセットパイプラインのいいところは、実用的な逐次の再読み込みする点と、目に見えているアセットのゲーム内の同期が保証されている点です。ただ一方でこの機能にはいくばくかコストがかかります。どのアセットも修正されたら、すぐに必ず再インポートされます。長い間隔が空いて SCM から最新のデータを取得した後になると、他のチームメンバーの修正または作成したすべてのアセットを再インポートするために長時間待つことになります。また、他のプラットフォームへ移動する度に、多くのアセットを再インポートすることになります。

このアセットをインポートする時間を、Cache Server でインポートされたアセットデータをキャッシュすることで、ドラスティックに縮めることができます。

それぞれのアセットインポートは以下に基づいてキャッシュされます。

  • アセットファイルそのもの
  • インポート設定
  • インポートされたアセットのバージョン
  • 現在のプラットフォーム

以上のどれかが変更された場合、アセットは再インポートされるか、キャッシュサーバーからダウンロードされます。

Preference で Cache server をオンにすると、複数のプロジェクト間のアセットインポートもシェアすることも可能です。

気をつけていただきたいのは、いったん Cache Server を設定すると、この過程はすべて自動的になり、追加のワークフローはありません。何ら手間を必要とせずに、インポートするための時間を単純に短縮してくれるでしょう。

Cache Server の設定 (利用者側)

キャッシュサーバーを設定する方法がとても簡単になりました。Preferences の Use Cache Server にチェックして、ローカルマシンの Unity Editor にどこに Cache Server があるのかを指定するだけです。

この項目は Mac では Unity->Preferences 、PC では Unity->Preferences にあります。

もしローカルマシンにキャッシュサーバーがホスティングされているなら、サーバーアドレスは localhost にしてください。ただ、ローカル PC ではハードディスクサイズの制限があるため、キャッシュサーバーは他のマシンにインストールすることをお勧めします。

Cache Server の設定 (管理者側)

管理者はキャッシュされたアセットを置いておくための Cache Server マシンの設定する必要があります。

以下のとおりにしてください。

  • オンラインストア から Pro ライセンスを購入します。
  • キャッシュサーバーをダウンロードします。 Unity ダウンロード アーカイブ ページに移動してください。使っている Unity バージョンのダウンロードを選択し、 Cache Server をクリックするとダウンロードが開始します。
  • そのファイルを展開すると、下記のようになります:
  • OS ごとに違いますが、適切なコマンドスクリプトを走らせてください。
  • 下記のようにバックグラウンドで動いているキャッシュサーバーをターミナルウィンドウで確認できます

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 ではそのようなことがありません。

キャッシュサーバー FAQ

キャッシュサーバーの DB サイズはインポートしたりリソースを保存したりするたびに無限にどんどん大きくなってしまうのでしょうか?

キャッシュサーバーは自動的に一定周期に使われなくなったアセットを削除します(もちろん再度必要になれば、次に使われる間に再び作られるでしょう)。

キャッシュサーバーは Asset Server でしか動かないのですか?

キャッシュサーバーはソースバージョンコントロールと切り離してデザインされているので、Unity の Asset Server に制限されることはありません。

何を変更すると再生成するためにファイルがインポートされるのでしょうか?

Unity は一つのアセットをインポートしようとする際、元となるすべてのデータの MD5 ハッシュを生成します。

例えばテクスチャでは、以下のように成り立っています:

  • 元となるアセット: “myTexture.psd” ファイル
  • メタファイル: “myTexture.psd.meta” (すべてのインポート設定を保存しています)
  • テクスチャインポーターの内部バージョン番号
  • すべての AssetPostprocessors のバージョン番号のハッシュ

もし Cache Server に保存されているハッシュが違っていたら、アセットは再インポートされるか、キャッシュ化されたバージョンをダウンロードされます。クライアント側の Unity editor は必要な時にサーバーからアセットをプルする(持ってくる)だけです。つまりアセットはそれぞれのプロジェクトにプッシュすることはありません。

依存関係のあるアセットはどう扱ったらよいですか?

キャッシュサーバーは依存関係に関与しません。Unity のアセットパイプラインは依存関係のコンセプトを扱いません。アセット間の依存を避けるように作られています。AssetPostprocessors はアセットインポーターを自分用にカスタマイズする一般的なテクニックです。例えば、決められた名前やタグに基づいて、いくつかの GameObject に fbx ファイルで MeshCollider を追加することも可能です。

AssetPostprocessors を使って、依存関係を示すことも簡単にできます。例えば、アセットの次に、テキストファイルから得たデータを使って、インポートしたゲームオブジェクトにコンポーネントを追加することも可能です。これは Cache Server ではサポートされません。もしキャッシュサーバーを使いたいなら、プロジェクトフォルダーの他のアセットへの依存関係を排除しなければなりません。キャッシュサーバーは自分用の Postprocessor での依存関係について何も検知しないので、古いバージョンのアセットをそのように変更しても検知できないのです。

実践的な話で言えば、キャッシュサーバーで動かすためのアセットポストプロセッサーを走らせる方法はたくさんあります。 例えば:

  • インポートされたアセットのパス
  • アセットのすべてのインポート設定
  • 元となるアセット自身か、アセットポストプロセッサー内で生成されたデータ

マテリアルで動かす際に問題がありませんか?

マテリアルを変更するには既知のトラブルあります。キャッシュサーバーを使っていると、Unity はマテリアル参照を維持します。しかしポストプロセスが postprocessing で呼ばれないので、キャッシュサーバーを通してインポートされたモデルでは、マテリアルの内容は変更されることはありません。そのため、キャッシュサーバーがある場合とない場合とで違う結果を得ることになるでしょう。これを避けるにはディスクにすでに存在するマテリアルは修正しないことです。

サーバーによってキャッシュされないアセットの種類はありますか?

サーバーにキャッシュされないいくつかのアセットの種類はあります。キャッシングスクリプトによって作られたものは、サーバーでは無視されるので、キャッシュされません。(Maya、3D Max 等の)3D モデリングソフトで使われているネイティブのファイルはそのアプリケーション自体を使って FBX にコンバートされます。現在サーバーでは、ネイティブのファイルとインポートプロセスで生成された FBX ファイルのどちらもキャッシュ化しません。しかし、モデリングソフトから FBX にエクスポートされたファイルを Unity プロジェクトに追加することでキャッシュ化が可能になります。

YAML クラス ID リファレンス
スクリプトでアセットを変更する