時間を節約するための高度なエディタースクリプティングハック（その 1）
開発者が行う作業で、特に新しいアートアセットの組み込みに関する作業が、繰り返しが多く、ミスが起こりやすいものになっているというプロジェクトを私は数多く見てきました。例えば、キャラクターを設定する場合には、アセット参照を何度もドラッグアンドドロップして設定し、チェックボックスにチェックを入れ、ボタンをクリックする作業がよく発生します。具体的には、モデルのリグを Humanoid に設定する、SDF テクスチャの sRGB を無効にする、法線マップ画像を法線マップとして、UI テクスチャをスプライトに設定するなどの作業です。ここでミスがよく起きるということは、言い方を変えれば、貴重な時間を費やしているのに、重要なステップを見逃すことがあるということです。
こうしたワークフローを改善し、次のプロジェクトが前回よりもスムーズに進むようにするためのハックを、今回から 2 回に分けてご紹介します。この記事の内容をさらに深く説明するために、ユニットを集めてできたチームが自動的に敵の建物や他のユニットを攻撃するという、リアルタイムストラテジーゲーム（RTS）に似た簡単なプロトタイプを作りました。それぞれのスクリプティングハックによって、テクスチャやモデルなど、プロセスに含まれるさまざまな点を 1 つずつ改良していきます。
プロトタイプはこのようなものです。
アセットをインポートする際に、開発者が多くの細かい設定をしなければならない主な理由は単純なものです。Unity はそのアセットがどのように使われるかを知らないので、そのアセットに最適な設定が何なのかがわからないのです。これらの作業の一部を自動化する場合、まずこの問題を解決する必要があります。
あるアセットが何のためにあり、他のアセットとどのように関連しているかを知る最も簡単な方法は、特定の命名規則とフォルダー構造に従うようにすることです。例えば以下のようにします。
- 命名規則：アセットの名前そのものに何らかの要素を付け加えます。例えば、Shield_BC.png はベースカラー、Shield_N.png は法線マップ、のようにです。
- フォルダー構造：Knight/Animations/Walk.fbx はアニメーションで、Knight/Models/Knight.fbx はモデルだということが明確にわかります。どちらも同じフォーマット（.fbx）であるにもかかわらず、です。
これの問題点は、一方向にしかうまく機能しないことです。つまり、アセットが何のためにあるのかは、そのパスが分かれば自明なことかもしれませんが、アセットが何をするかという情報だけが与えられても、そのパスを推測することはできないのです。アセット（例えばキャラクターのマテリアル）を検索できることは、アセットのある部分の設定を自動化しようとする場合に有効です。この問題は厳密な命名規則を使ってパスを容易に推測できるようにすることで解決できますが、それでもミスの可能性があります。規則を覚えていても、誤字脱字はよくあることです。
これを解決するための面白いアプローチが、ラベルを使うことです。アセットのパスを解析し、それに応じてラベルを割り当てるエディタースクリプトを使用することができます。ラベルは自動化されているので、アセットに貼られるラベルを正確に把握することが可能です。AssetDatabase.FindAssets を使えば、ラベルでアセットを探すこともできます。
この一連の作業を自動化したい場合、AssetPostprocessor という非常に便利なクラスがあります。AssetPostprocessor は、Unity がアセットをインポートする際に、さまざまなメッセージを受け取ります。その 1 つが OnPostprocessAllAssets で、これは Unity がアセットをインポートし終わるたびに呼び出されるメソッドです。インポートしたアセットへのすべてのパスが示され、それらのパスに何かの処理を行う機会が与えられます。以下のような簡単なメソッドを書いて、処理することができます。
このプロトタイプの場合はインポートされたアセットのリストに注目します。新しいアセットや移動されたアセットを捕捉しようとするためです。結局のところ、パスが変わればラベルも更新したくなってきます。
ラベルを作成するには、パスを解析し、関連するフォルダー、名前の接頭辞、接尾辞、および拡張子を探します。ラベルを生成したら、1 つの文字列にまとめ、アセットに設定します。
ラベルを割り当てるには、AssetDatabase.LoadAssetAtPath でアセットをロードし、AssetDatabase.SetLabels でそのラベルを割り当てます。
ラベルは、実際に変更された場合のみ設定する必要があることを覚えておきましょう。ラベルを設定するとアセットの再インポートが発生するので、厳密に行う必要がある場合以外はこれは行わないでください。
これをチェックしておけば、再インポートは問題ではなくなります。ラベルはアセットを初めてインポートするときに設定され、.meta ファイルに保存されます。すなわち、バージョン管理システムにも保存されます。再インポートは、アセット名を変更したり、アセットを移動した場合にのみ発生します。
以上の手順を完了すると、下図の例のように、すべてのアセットに自動的にラベルが付きます。
テクスチャをプロジェクトにインポートするには、通常、各テクスチャの設定を調整する必要があります。普通のテクスチャでしょうか。法線マップは。スプライトは。リニアでしょうか sRGB でしょうか。アセットインポーターの設定を変更したい場合は、もう一度 AssetPostprocessor を使用します。
この場合、OnPreprocessTexture メッセージを使用します。これは、テクスチャをインポートする直前に呼び出されるメッセージです。これにより、インポーターの設定を変更することができます。
テクスチャごとに適切な設定を選ぶには、どのようなテクスチャを扱っているかを確認する必要があります。まさにこれが、最初のステップでラベルが重要になる理由です。
この情報をもとに、簡単な TexturePreprocessor を書いてみましょう。
このスクリプトは、アートラベルを持つテクスチャ（自分で作ったテクスチャ）に対してのみ実行するようにすることが重要です。その後、インポーターへの参照を取得し、テクスチャのサイズからすべてを設定できるようになります。
AssetPostprocessor には context プロパティがあり、ここからターゲットプラットフォームを決定することができます。そのため、モバイル向けにテクスチャを低解像度に設定するなど、プラットフォーム固有の変更も完了します。
次に、テクスチャが UI テクスチャであるかどうかをラベルで確認し、適宜設定します。
それ以外のテクスチャについては、デフォルトの値を設定します。アルベドが sRGB を有効にする唯一のテクスチャであることは覚えておいてよいでしょう。
上記のスクリプトのおかげで、新しいテクスチャをエディターにドラッグアンドドロップすると、自動的に正しい設定が行われるようになりました。
「チャンネルパッキング」とは、異なるチャンネルを使って、多様なテクスチャを 1 つにまとめることです。一般的であり、多くの利点があります。例えば、Red チャンネルの値はメタリックであり、Green チャンネルの値はその滑らかさで決まっています。
しかし、すべてのテクスチャを 1 つにまとめるには、アートチームによる追加作業が必要です。何らかの理由でパックの内容を変更する必要がある場合（シェーダーの変更など）、アートチームはそのシェーダーで使用するテクスチャをすべて作り直さなければなりません。
ご覧の通り、ここには改善の余地があります。私がチャンネルパッキングに好んで使うアプローチは、「生」のテクスチャを設定し、チャンネルパッキングを施したテクスチャを生成し、マテリアルで使用する特殊なアセットのタイプを作成することです。
まず、特定の拡張子を持つダミーファイルを作成し、そのアセットをインポートする際にすべての作業を行ってくれる Scripted Importer を使います。仕組みは以下のようになっています。
- インポーターには、合成する必要のあるテクスチャなどのパラメーターを設定することができます。
- インポーターから、テクスチャとの依存関係を設定することで、ソースとなるテクスチャのいずれかが変更されるたびにダミーアセットが再インポートされるようにすることができます。これによって、生成されたテクスチャを適宜再ビルドすることができます。
- インポーターにはバージョンがあります。テクスチャのパッキング方法を変える必要がある場合は、インポーターを改造して、バージョンを上げるとよいでしょう。これにより、プロジェクト内でパッキングされたテクスチャの再生成が強制的に行われ、すべてのテクスチャが新しい方法で即座にパッキングされます。
- インポーターで生成すると、生成されたアセットが Library フォルダーにしか残らないので、バージョン管理システムがそれだけで一杯にならないという、良い副作用もあります。
これを実装するには、作成したテクスチャを保持し、インポーターの結果として提供する ScriptableObject を作成します。この例では、このクラスを TexturePack と呼びました。
これを作成したら、まずインポーターのクラスを宣言し、ScriptedImporterAttribute を追加して、インポーターにひもづくバージョンと拡張子を定義します。
インポーターで、使用するフィールドを宣言します。これらは、MonoBehaviour や ScriptableObject と同じように、インスペクターに表示されます。
パラメーターの準備ができたので、パラメーターとして設定したものから新しいテクスチャを作成します。ただし、（前のセクションで示した）プリプロセッサーでは、isReadable を True に設定して、これを実現していることに注意してください。
このプロトタイプでは、RGB にアルベド、アルファにプレイヤーの色を適用するためのマスクが入った「Albedo」と、R チャンネルにメタリック、G チャンネルにスムースネスが入った「Mask」という 2 つのテクスチャがあることが分かります。
この記事の範囲外かもしれませんが、例として Albedo とプレイヤーのマスクの組み合わせ方を見てみましょう。まず、テクスチャが設定されているかどうかを確認し、設定されている場合はその色のデータを取得します。次に、AssetImportContext.DependsOnArtifact を使って、テクスチャを依存関係に設定します。上記のように、テクスチャが変更された場合、オブジェクトの再計算が必要になります。
また、新しいテクスチャを作成する必要があります。そのためには、前のセクションで作成した TexturePreprocessor から、プリセットの制限に沿うようにサイズを取得します。
次に、新しいテクスチャのデータをすべて入力します。これは、ジョブと Burst を使うことで大幅に最適化することが可能です（これだけで記事が 1 本書けてしまうほどです）。ここでは、簡単なループを使用することにします。
このデータをテクスチャに設定します。
さて、別のテクスチャを生成する方法も、よく似た方法で作ることができます。これが出来たら、インポーター本体を作成します。今回は、結果を保持する ScriptableObject を作成し、テクスチャを作成し、AssetImportContext を通じてインポーターの結果を設定するのみとします。
インポーターを書く際には、生成されたすべてのアセットを AssetImportContext.AddObjectToAsset を使って登録し、プロジェクトウィンドウに表示されるようにする必要があります。AssetImportContext.SetMainObject を使って、メインのアセットを選択します。このようになります。
あとはダミーアセットを作成するだけです。これらはカスタムなので、CreateAssetMenu 属性を使用することはできません。その代わり、手動で作成する必要があります。
MenuItem 属性を使って、アセット作成メニューのフルパス、Assets/Create を指定します。アセットを作成するには、ProjectWindowUtil.CreateAssetWithContent を使用します。指定した内容のファイルを生成し、ユーザーがその名前を入力できるようにするものです。このようになります。
最後に、チャンネルパッキングが施されたテクスチャを作成します。
多くのプロジェクトでカスタムシェーダーが使用されています。倒した敵をフェードアウトさせるディゾルブエフェクトのような追加エフェクトのために使われることもあれば、トゥーンシェーダーのようなカスタムのアートスタイルを実装するためのシェーダーもあります。どのような用途であれ、Unity はデフォルトのシェーダーで新しいマテリアルを作成するので、マテリアルがカスタムシェーダーを使用するように変更する必要があります。
この例では、ユニットに使用するシェーダーに、ディゾルブエフェクトとプレイヤーの色（動画中のプロトタイプでは赤と青）の 2 つの機能を追加しています。これらをプロジェクトに実装する場合、すべての建物とユニットが適切なシェーダーを使用するようにする必要があります。
アセットが特定の要件に合致しているかどうか（この場合は正しいシェーダーを使用しているかどうか）を検証するために、もう 1 つ便利なクラスがあります。AssetModificationProcessor です。AssetModificationProcessor.OnWillSaveAssets を使うと、特に Unity がアセットをディスクに書き込もうとするときに通知を受け取ることができます。これによって、アセットが正しいかどうかを確認し、保存する前に修正することができます。
さらに、Unity にアセットを保存しないように「指示」することもできます。これは検出した問題を自動で修正できない場合に有効です。これを実現するために、OnWillSaveAssets メソッドを作成します。
アセットを処理するために、マテリアルであるかどうか、正しいラベルが付いているかどうかを確認します。以下のコードによる検証を通れば、正しいシェーダーです。
ここで便利なのは、このコードがアセット作成時にも呼び出されることです。つまり、新しいマテリアルには正しいシェーダーが設定されることになります。
Unity 2022 の新機能として、マテリアルバリアントも用意されています。マテリアルバリアントは、ユニット用のマテリアルを作成する際に非常に便利です。実際、ベースのマテリアルを作成し、そこから各ユニットのマテリアルを派生させ、関連するフィールド（テクスチャなど）をオーバーライドし、残りのプロパティを継承させることができます。これにより、マテリアルにデフォルトをきちんと設定できますし、必要に応じて更新することもできます。
アニメーションのインポートは、テクスチャの取り込みと似ています。さまざまな設定を行う必要がありますが、そのうちのいくつかは自動化することが可能です。
Unity は、デフォルトですべての FBX（.fbx）ファイルのマテリアルをインポートします。アニメーションの場合、使用したいマテリアルは、プロジェクト内か、メッシュの FBX にあります。アニメーション FBX に付いている余計なマテリアルは、プロジェクト内でマテリアルを検索するたびに表示され、かなりのノイズとなるため、これを無効にしておくことに一定の価値があります。
リグを設定するには、Humanoid と Generic のどちらかを選択し、注意深く設定が施されたアバターを使う場合は、それを割り当てます。テクスチャに適用したのと同じアプローチが適用されます。しかしアニメーションの場合、使用するメッセージは AssetPostprocessor.OnPreprocessModel となります。これはすべての FBX ファイルに対して呼び出されるので、アニメーションの FBX ファイルとモデルの FBX ファイルを区別する必要があります。
先ほど設定したラベルのおかげで、それほど複雑にはならないはずです。メソッドの最初の部分はテクスチャの場合とほぼ同じです。
次に、メッシュの FBX からリグを使用したいので、そのアセットを見つける必要があります。アセットを探すには、もう一度ラベルを使用します。このプロトタイプの場合、アニメーションは「animation」で終わるラベルを持ち、メッシュは「model」で終わるラベルを持ちます。簡単な置換作業で、モデルに使うラベルを作ることができます。ラベルができたら、AssetDatabase.FindAssets で「l:label-name」を指定して、アセットを探します。
他のアセットにアクセスする場合、他にも考慮すべきことがあります。インポート処理の途中で、このメソッドが呼ばれたときにはまだアバターがインポートされていない可能性があるのです。この場合、LoadAssetAtPath は null を返し、アバターを設定することができなくなります。この問題を回避するには、アバターのパスに依存関係を設定します。アバターがインポートされるとアニメーションが再度インポートされますので、そこで設定することができます。
ここまで説明したことのすべてをコードに落とすと、次のようになります。
あとは、アニメーションを正しいフォルダーにドラッグし、メッシュの準備が整えば、それぞれ自動的に設定されます。しかし、アニメーションをインポートするときにアバターがなければ、プロジェクトが作成された時点でそれを拾うことができません。その場合は、アニメーションを作成した後に手動で再インポートする必要があります。これはアニメーションのあるフォルダーを右クリックし、Reimport を選択することで実行できます。
以下のサンプル動画で、ここで説明した手順のすべてをご覧いただけます。
前のセクションとまったく同じ考え方で、使用するモデルをセットアップしていきます。この場合、AssetPostrocessor.OnPreprocessModel を採用し、このモデルのインポーター設定を行います。
プロトタイプでは、インポーターでマテリアルを生成しないように設定し（プロジェクトで作成したものを使用します）、モデルがユニットなのか建物なのか（いつものようにラベルを確認することで）チェックしました。ユニットはアバターを生成するように設定されていますが、建物はアニメーションしないので、建物のアバター生成は無効になっています。
皆さんのプロジェクトでは、モデルをインポートする際にマテリアルとアニメーター（および、他に追加したいものはすべて）を設定するのがよいでしょう。こうすることで、インポーターで生成されたプレハブをすぐに使用することができるようになります。
これには、AssetPostprocessor.OnPostprocessModel メソッドを使用します。このメソッドは、モデルのインポートが終了した後に呼び出されます。生成されたプレハブをパラメーターとして受け取り、プレハブを好きなように変更することができます。
プロトタイプの場合は、アニメーションのアバターの位置を決めるのと同じように、ラベルを照合してマテリアルとアニメーションコントローラーを探しました。プレハブのレンダラーとアニメーターで、通常のゲームプレイと同じようにマテリアルとコントローラーを設定しました。
あとは、そのモデルをプロジェクトにドロップすれば、どんなシーンにも落とし込めるようになります。ただし、ゲームプレイに関連するコンポーネントは何も設定していません。それについては、このブログの後編で紹介します。
これらの高度なスクリプティングのヒントがあれば、ゲームを作る準備は万端です。今回 2 回にわたってお送りしている Tech from the Trenches の記事ですが、次回はゲームデータのバランスをとるためのハックなどをご紹介しますので、ご期待ください。
この記事について議論したり、記事を読んだ後の感想を共有したりしたい場合は、私たちのスクリプティングフォーラムをご覧ください。また、Twitter でも @CaballolD とつながりましょう。