アバター改変プロジェクトの管理とワークフロー
なんとなく気が向いたので普段やっていることを書き出してみようと思います。あくまでも「私はこうしています」という話に過ぎないので正解はありませんし、各自の要望に合わせて何が最適なのかを考え続ける必要があります。
なお、何かのツールの具体的な使い方や手順といったものはほとんど登場しません。世の中に既にあるたくさんの記事の方がずっと丁寧に説明してくれることでしょう。
ワークフローで重視すること
この記事では以下のことを重視して改変ワークフローを考えていきます。
考えることを減らすことを頑張る。
難しいことや複雑なことを考えない。
簡単なことを積み重ねる。刻む。
安定・継続的にアバターをメンテナンスできるようにする。
ワークフローの概要
大まかに以下の順で改変作業を進めていきます。
PCの環境整備
前準備としてPCの状況を見直します。プロジェクトの作成と管理
プロジェクトを作成し、データの管理方針を決めます。Unityでの改変作業
実際にアバターを改変します。Prefab Variantと非破壊ツールを中心にアバターを構成します。Quest対応
最後の工程としてQuest対応をします。
PCの環境整備
Unityでプロジェクトを作成する前に、まずそれを扱うPCについて考えていきます。
ストレージ構成
Unityのプロジェクトでは大量・頻繁なI/O操作があることから、できるだけ高速なストレージを使用することが望ましいです。そのためSSDを使用したいところですが、寿命の観点では頻繁な読み書きを繰り返す動作をCドライブ用のSSDでは使用したくありません。そこで、SSDを別途用意して丸ごとVRChatのプロジェクトとアセット保管用に割り当てます。
Cドライブ: NVMe SSD (Windows, ゲーム本体など容易に復旧できるもの)
Dドライブ: SATA HDD (書類や写真データなど)
Eドライブ: SATA SSD (VRChat用Unityプロジェクト、DL済アセット)
フォルダの整理
大雑把ですが以下のようにフォルダ分けします。たまに古いバージョンや再入手不可のアセットが必要なケースがあるので、DLしたものはすべて保管します。
VRChat
VCC (VCC/ALCOMで管理するフォルダ)
Avatars (アバタープロジェクトを格納)
[各プロジェクト]
Worlds (ワールドプロジェクトを格納)
[各プロジェクト]
Packages (ローカルVPMパッケージを格納)
[各パッケージ-バージョン]
Depot (DL済アセットを管理するフォルダ)
[各Booth名]
[各商品]
[各バージョン]
実際のところBooth名や商品名を正確に覚えられるかといえば厳しいのでもっと視覚的に一覧性の高い手段が欲しいところです。
バックアップ
Unityプロジェクトのバックアップは確かに大事ですが、よく考えてみてください。PCには他にも写真や書類など重要なデータはたくさんあります。そこでPC自体のバックアップを考えます。
とはいえあまり手間をかけたくはありません。以下の要件のために、BackBlazeというサービスを使用しています。
自動的にバックアップされること
PC本体とは別媒体であること
NASなどの管理をしなくて済むこと
いくつか制約こそありますが、PC全体のデータをクラウドに自動バックアップすることができます。幸いまだ復旧機能のお世話になったことはありませんが、明日にも家が吹き飛ぼうともデータを復旧できるという状況になっています。(ここ数年は値上げ傾向なのがネックですが…)
これはあくまでも日々のバックアップであり大雑把なもののため、プロジェクト内での細かな変更管理には別途バージョン管理ツールを使用します。(後述)
プロジェクトの作成と管理
VCC/ALCOMでプロジェクトを作成していくにあたり、管理の方針を決めていきます。
プロジェクトの分割方針
何でもかんでもインポートした大きなプロジェクトを作ってしまうと以下の問題が出てきます。
ツールやアセット間の互換性に問題が出やすくなる
Unityバージョン移行時の失敗リスクが高まる
プロジェクト破損時の被害が全体に及ぶ
Android対応のためのSwitch Platformに非常に時間がかかる
とはいえあまり細かく分けすぎても不便なため、改変のベースとなるアバター単位でプロジェクトを分けています。
改変済みマテリアルやPrefabを複数の改変アバター間で流用できる
把握すべきアセットの量を減らすことができる
(何でも入れる場合と比較して)Switch Platformにかかる時間が短い
プロジェクトの作成
ごく普通にVCC/ALCOMからプロジェクトを作成します。このとき、カスタムのテンプレートは使用しません。管理が面倒になってテンプレートを更新しなくなることが目に見えているのと、その時点でのベストなパッケージを都度検討して導入するためです。現在であれば、MA/NDMFをはじめとした非破壊改変ツールを中心に導入することになるでしょう。
バージョン管理
Gitを使用します。バージョン管理ツールのデファクトスタンダードと言って差し支えないでしょう。変更内容をいつでも記録した地点に巻き戻すこと(実質的なセーブ&ロード)ができるので、プロジェクトをいくら壊しても元に戻せます。プロジェクトを壊し放題であるということは、様々な試行錯誤を気軽に試せるということです。
以下の方針でリポジトリを管理していきます。
リモートリポジトリなし (既にPC全体がバックアップされている)
Git LFSなし (リモートにプッシュしないのと、単純に使い慣れていない)
改変ごとにブランチを切る
アップロード完了したらmainにマージ
ソースコードほど細かく管理する必要性はないので、大まかに以下のタイミングでコミットしていきます。(テクスチャもFBXも丸ごとコミットするので、あまり頻繁にコミットすると容量が嵩むというのもあります)
新しくアセットやパッケージをインポートしたとき
改変してアップロード完了したとき
また、リポジトリには .gitignore を追加してバージョン管理に不要なファイルをコミットしないようにできます。設定済みのファイルがGitHubで配布されているのでこれを使います。
さらに以下の行を追加し、NDMFマニュアルベイクおよびVRCQuestTools手動変換の結果をコミットできないようにすることで実質的に禁止し、非破壊改変を強制する制約を与えます。
/Assets/VRCQuestToolsOutput*
/Assets/ZZZ_GeneratedAssets*パッケージの導入
VPMで導入できるものはVPMで導入します。また、バージョンについてはよほどの重大な理由のない限り安定版(betaやrcなどの付いていないもの)のみを使用します。betaやrcを使うって事はプロジェクトを破壊されるかもしれないという危険を「覚悟して来てる人」ってわけですよね…ということです。(問題が起きたらもちろん報告しましょう)
まあバージョン管理をちゃんとしてればいくらでも復旧できるのですが。
まずアバターや手順によらず使用するパッケージを導入していきます。記事執筆時点では以下のパッケージをよく使用しています。(名称順)
Actual Performance Window (anatawa12’s gist pack for Unity)
アバターの最終的なパフォーマンスランクを確認します。MA/NDMFによる非破壊改変では事実上必須とも言えます。
HierarchyPlus
ヒエラルキーの表示を改善します。コンポーネントのアイコンやタグが表示されて便利です。
Unity Terminal Launcher (自作)
Unityからプロジェクトフォルダに対してターミナルを開くことができます。私はコマンドラインじゃないとGitが使えないので非常に重宝しています。これだけはVCCではなくOpenUPMから導入します。
他、改変対象のアバターや衣装で指定されている必須パッケージ(lilToonやMAなど)を導入していきます。一通りパッケージを追加し終えたら、一度ここでプロジェクトの変更をGitにコミットしておきます。
アバター改変の方針
プロジェクトを作成するだけで既に3,000文字以上使っていますが、今度はアバターをどのように管理していくかを決めます。
アセットの管理方針
基本的に、インポートしたアセットは移動して整理したりしません。そのまま使います。特にUnitypackageで導入するエディタ拡張では、フォルダ等が変わることで予期せぬ動作を誘発する可能性があるためです。
一方、自分の改変アセットは自分用のフォルダを作成して管理します。改変同士でアセットが混ざったり、プロジェクト間でアセットを融通したときに混ざってしまうのを防ぐために、以下のようにフォルダ分けします。
Assets
(自分用のフォルダ)
(改変のベースとなるアバター名のフォルダ)
Base (基準となる改変のアセットを格納)
(各種アセット)
(改変名のフォルダ)
(各種アセット)
シーンの分割方針
改変ごとにシーン自体を分け、1アバター：1シーンにします。1シーンに複数のアバターがあると嬉しくないことが多いためです。
表示するオブジェクトが多くなって重い。
ヒエラルキーを展開したときに、どこを作業しているか分かりにくい。
誤ってアバター間でオブジェクトを移動したり参照を持たせてしまう事故が起きる。
シーンファイル破損時の被害が複数のアバターに及ぶ。
参考のためなど他のアバターを同時に確認したい場合は、複数のシーンをロードして使います。
また、シーンファイル(.unity)自体はAssets/Scenesフォルダではなく前述の改変用フォルダに保存し、改変に関するファイルを1か所にまとめます。
アバターの分割方針
1アバター：1衣装にします。例外的に複数の衣装バリエーションを入れることもありますが、その場合「一緒に使うことが想定されているもの」「衣装同士に明確な関連性があるもの」といった形で最低限の数に絞ります。
最近のアバター容量制限に対応する点で有利ですし、後々Quest対応するという点でもあらかじめ容量を抑えておくことは重要です。
また、衣装をたくさん入れるということはそれを管理する複雑なギミックが必要であり、複雑であるということは壊れやすさに繋がります。できるだけシンプルな構成にすることで壊れにくくします。シンプルであるということは考慮すべきことが少なく、後からのメンテナンスがしやすいです。
Prefab Variantの活用
MA/NDMFの登場のおかげでPrefabをUnpackせずに扱うことが簡単になったため積極的に活用します。具体的には以下の親子関係を持つようにPrefab Variantを作成・利用します。
改変前アバターPrefab (Unitypackgeで導入したもの)
ベースPrefab Variant (全ての改変のベースとなるVariant)
各改変アバター (ベースPrefab Variantに対するオーバーライド)
1アバター：1衣装になることで作成するアバターの数は衣装の数だけ増えることになりますが、すべてPrefab Variantで管理することによってアバター間で共通の設定を楽に流用できます。
ベースPrefab Variantの作成
アバターの作成方針が決まったので、実際にアバターを改変していきます。ここからようやくUnityでの作業になります。
ここでは後の改変作業の共通素体となるベースPrefab Variantを作成していきます。まずは改変ブランチを作成しましょう。
ベースPrefab Variantで作業する範囲
他の改変のベースになるという用途から、最低限の内容にとどめます。主には以下の内容が中心になります。
マテリアル改変・差し替え (色改変)
各種設定変更 (View Pointなど)
表情・体型変更
共通機能 (コンポーネント)
アクセサリ追加や髪型変更といったモデル追加を伴う改変は、ベースPrefab Variantから更なるVariantとして作成した方が使い勝手が良いと思います。
マテリアルの改変・差し替え
多くの場合、既にあるマテリアルをもとに新しいマテリアルを作り、そちらを修正することになります。Unity 2022からはMaterial Variantを使いPrefab Variantのように「元のマテリアルを継承したマテリアル」を作成できます。
一つ一つバリアントを作成するのは面倒なのでKRT Material Tools (自作)のQuick Variantを使用します。アバター内で使用している全マテリアルからバリアントを生成し、さらにアバターのマテリアルを差し替えます。
マテリアル作成後のテクスチャ差し替えではKRT Material Tools (自作)のTexture Replacerを使用します。変更するテクスチャを探し当てるためにインスペクタを探し回る手間が減り、またメインテクスチャだけ変更して輪郭線テクスチャを変更し忘れて容量増大といったミスを防ぐことができます。
共通機能とコンポーネント
どんな改変でも使用する機能を設定していきます。表情や体型を変更するほか、以下のコンポーネントを付与します。
MA Mesh Settings (Modular Avatar)
アンカーオーバーライドとBoundsを統一します。付けて損はないのでとりあえず付けます。MA Convert Constraints (Modular Avatar)
Unity Constraintsを非破壊的にVRC Constraintsに変換します。既存のUnity ConstraintsをQuestに持ち込むためには事実上必須と言えます。付けて損はないのでとりあえず付けます。AAO Trace And Optimize (Avatar Optimizer)
アバターの自動最適化をします。特に近年のアバターの豊富なシェイプキーは非圧縮サイズを増大させてしまうので、それを削除してくれるという点でQuest対応の時には非常に重要です。付けて損はないのでとりあえず付けます。VQT Network ID Assigner (VRCQuestTools (自作))
PhysBoneにネットワークIDを割り当ててPC-Quest間での同期ずれを防ぎます。VRCSDKの自動割り当てよりもオブジェクトの増減に強いです。付けて損はないのでとりあえず付けます。VQT Avatar Converter Settings (VRCQuestTools (自作))
Quest対応のときの変換設定をします。揺れ物がないのが当たり前の環境で育ったのでPhysBoneをバッサリ全カットして必要なところだけ揺らします。
また、必要に応じて以下のツールを使用することもあります。
Quest対応の準備 (いわゆる海苔の対策)
ベースPrefab Variantの時点でQuest対応の準備を済ませておきます。ここでは、PCでは透過マテリアルで表現されている頬染めや青ざめがのっぺりと表示される現象(いわゆる海苔)を対策します。
顔のメッシュにAAO Remove Mesh By BlendShapeを追加します。
「海苔」の発生するシェイプキー(頬染め・青ざめ等)を削除するように設定します。顔のメッシュにVQT Platform Component Removerを追加します。
RemoveMeshByBlendShapeの右側にあるPC列のチェックボックスをオフにします。
上記の設定により、PCビルドのときには通常通りシェイプキーが使用され、Androidビルドのときにだけ海苔の発生するメッシュを削除することができます。
ベースPrefab Variantの保存
改変したアバターをPrefab Variantとして保存します。このとき、Prefab VariantからはBlueprint IDを除去しておきます。後でこのPrefab Variantを使って改変するときに毎回Blueprint IDを削除する手間を減らすためです。
また、ここでバージョン管理の方針にしたがってGitにコミットし、改変ブランチをメインブランチにマージします。
アバターの改変
アバターを改変します。この辺りは既に多数の記事が存在しているので、これといって特別に書くことはあまりありません。まずは改変ブランチを作成しましょう。
シーンの作成
1アバター：1シーンの方針に従い、新規シーンを作成します。ここまでの作業で作成済みのベースPrefab Variantをシーンに配置して改変作業を開始します。
改変作業
ベースPrefab Variantを使って改変をします。また、絶対にUnpack Prefabをしないという制約を入れます。それ以外は特に書くことはありません。世の中に既にあるたくさんの記事が参考になるでしょう。
オブジェクトのオン・オフ程度は手軽に付けたいので、最近は以下のツールを使うことが多いです。
込み入ったギミックになってきたら手作業でAnimator Controllerを組みますが、このときもMA Merge Animatorで導入できる非破壊モジュールとして作成しておきます。MA設定済み衣装を自分で作成するイメージです。
手動での最適化
使わないオブジェクトを明示的にEditorOnlyにしたり、Avatar OptimizerやTTT AtlasTexture (TexTransTool)で最適化をします。ベースPrefab Variantで既に設定したAAO Trace And Optimizeが十分に最適化をしてくれるので、あまり根を詰めずにやります。ざっくりとした目安は以下のようにしています(あくまでも目安)。
テクスチャメモリー: 110MB以下 (Medium)
ダウンロードサイズ: 40MB以下 (50MBを切っていればほとんどの人のセーフティに引っかからないでしょう。たぶん)
その他: 無理しない・面倒でない範囲で軽く (Medium～Poor程度)
アバターの動作確認
動作確認のためにアバターを毎回アップロードするとアップロードの時間がかかってしまい時間の無駄です。可能な限りアップロードの回数を減らし、動作確認と修正作業のサイクルを高速化することを考えます。
Gesture ManagerまたはAv3EmulatorでUnity内で簡単な動作確認ができます。私は両者の違いがよくわかっていないのでVCCに初めから入っているGesture Managerを使用しています。
また、VRCSDKのローカルテスト機能も重要です。VRChat内で実際にアバターを動作させられるので最も確実な動作確認になります。VRとデスクトップを行き来するのは大変なので、基本はデスクトップモードで動作確認し、どうしてもVRの必要なところだけVRで動作確認します。
アップロード
動作確認が完了したらアップロードします。アップロード後、バージョン管理の方針にしたがってGitにコミットしておきます。
Quest対応
一通り改変が終わったら最後の工程としてQuest対応(Android: Very Poor)をします。
Quest対応の方針
よほどの理由がなければ可能な限りQuest対応をしています。
どのアバターがQuest対応済みか把握していちいち一覧から探して切り替えるのがめんどくさい。
Quest対応していないアバターは自然と使わなくなってフェードアウトする。
対応プラットフォームの丸が埋まってないと不完全な感じがする(個人の感想です)。
なお、最適化は大変すぎるのでパフォーマンスランクはVery Poorとします。Fallback対応とメインアバターのAndroid Poor対応はしているのでスマホの対応(Android: Poor以上)は勘弁してくださいってことで。
Switch Platformの方針
Switch PlatformはQuest対応の中でも最も時間のかかる工程ですが、以下の理由でPC用とAndroid用でプロジェクトを分けていません。
片方の変更をもう一方に反映し忘れる
反映のさせ方を誤って変更を巻き戻してしまう
ストレージ使用量が増える
上記を解決する追加の仕組みを考えたくない
Unity 2018以前のSwitch Platformはだいぶ厳しかったですが、Unity 2019でのAsset Pipeline v2導入、Unity 2022でのASTC圧縮の高速化といった改善のおかげで非常によくなりました。普段からAndroid対応をしていれば新しいアセットだけを圧縮するので2回目以降のSwitch Platformは長くて数分程度で終わり、遅いと思ったことはあまりありません(初回はどうしようもないので待つ)。まあ待ってればいつかは終わるので呑気にTwitter(X)でも見るなりゲームやるなりしましょう。
またUnity Acceleratorを導入してアセットのキャッシュをプロジェクト間で共有し、複数プロジェクトで同じアセットのインポートを高速化させています。これはどちらかというと定番アセットを使い回すことが多いであろうワールド制作の方が恩恵が大きそうですが。
残しておくPhysBoneの再設定
改変の内容に合わせてVQT Avatar Converter SettingsのAvatar Dynamics設定を変更し、変換時に残しておくPhysBoneを変えます。
PC-Quest間の同期
Avatars 3.0において同期はExpression Parametersとそれによって駆動するAnimator Controllerによって実現されます。よって、PCとQuestで構成が同じであれば基本的に正しく同期します。
たまに聞く「PCでは正常だがQuestでは服が脱げている」といったことは、Quest側だけ衣装を減らして軽くしようといった「配慮」をしようとすると起きます。中途半端なことはせずにPC側からも衣装を減らして構成を一致させます。1アバター：1衣装の方針を守りましょう。
PhysBoneに関しては、ベースPrefab Variantに追加しておいたVQT Network ID Assignerが面倒を見るので何もしなくても基本的に同期します。
実機を使わない動作確認
私はQuest実機での動作確認をほとんどしていません。
Androidアバターにはローカルテストの仕組みはありません。つまり実機確認のためにはアップロードが必要ですが、PC版以上に非常に動作確認の効率が悪いです。PC版と同様に可能な限りUnityやデスクトップモードで動作確認し、動作確認と修正作業のサイクルを高速化することを考えます。
パーティクル系のシェーダーを使わない限り、現在のVRChatでは同じアバターをPCとQuestで使った時で動作はほぼ同じです。ここまでの方針を守っていれば同期ずれは基本的にはありません。QuestでできることのすべてはPCでもできるので、デスクトップモードで十分に動作確認になります。
VQT Avatar Builder (VRCQuestTools)を使うことで、Android用のビルド設定を使ってローカルテストアバターをビルドできます。
非破壊アップロード
動作確認が済んだらいよいよアップロードです。ただし非破壊改変の場合、シーンに置かれているのはPC版のアバターであるためVRCSDKによってビルドを止められます。
代わりにVQT Avatar Builder (VRCQuestTools)を使うことで、この制限を回避してビルドを開始しアバターをアップロードします。もちろん、ビルド後のアップロード直前に再度VRCSDKによるチェックが入るので変なものはアップロードできません。
非圧縮サイズ/ダウンロードサイズの最適化
ここ最近のアバターはシェイプキーが豊富なためメッシュのサイズも増大しており、非圧縮サイズ制限40MB/ビルドサイズ制限10MBを超えやすいです。ですが未使用のシェイプキーをAAO Trace And Optimizeが削除してくれるため、サイズをかなり減らすことができます。テクスチャの解像度を減らすよりも効果が大きいでしょう。
それでも大きいときはテクスチャの解像度を減らすよりもTTT AtlasTextureで効率的にテクスチャを削減した方がよいでしょう。
実機での動作確認 (任意)
複雑なギミックや初めてのギミックがあるときは少し不安になるのでQuest実機で動作確認をします。
アップロード後、バージョン管理の方針にしたがってGitにコミットしておきます。さらに改変用ブランチをメインブランチにマージして改変完了です。
メンテナンス
現実には改変後もアバターの修正があります。共通マテリアルの修正であったり、Unityのアップデート対応であったりです。
改変アバターへの共通設定の反映
プロジェクトには多数のアバターがありますが、Prefab Variantを活用していることによりベースへの変更が自動的にすべての改変アバターにも反映されます。Prefab Variant間の依存関係を意識して更新します。
バリエーションの一括アップロード
Prefab Variantによって変更を一括で反映できる一方で、再アップロードは一つ一つ行わねばなりません。手作業でアップロードするのは大変なので、Continuous Avatar Uploaderで自動化します。
Q&A
Android Very PoorはQuest対応と呼べないのでは？
ぜひ一度Quest単体でVRChatを遊んでみてください。楽しいですよ。
Android Very Poorはいつか禁止されるのでは？
その時はその時で。たぶん大反発が起きそうですが。VRChatが軽くなるとみんな嬉しいので、PC Very Poorも是非禁止しましょう！
今にして思えばスマホでVery Poorを使えなくするためのポーズでしかなかったのでは。
彼らはメンテする気があるんだかないんだか。
海苔対策のためにVRChat/Mobile/Particles/AdditiveやMultiplyで透過ができるのでは？
あまり期待を持たない方が良いです(個人の感想です)。
まず前提として半透明マテリアルというのはそもそもそれ自体の描画負荷が高いです。VRChat自身、過去のドキュメントではアバターに使うべきでないとしていました。また、これらのシェーダーは何度も壊れたり直ったりを繰り返しており信頼性に欠けます(なお、ほとんどすべてサイレント変更)。過去にはUnityとPCと実機で動作が違うこともありました。
よって、安定・安心を求めるならば使わないことをお勧めします。VRChatやVRCSDKのアップデートのたびにQuest実機で動作確認をする覚悟があるのであれば使っていいと思います。1年以上継続して安定していたら教えてください。
iOS対応は？
正式版になるまで静観でいいんじゃないですかね。ワールドみたいにAndroidビルドから自動変換してほしいので1体だけ対応して他は未対応で放置しています。ワールドと違ってシェーダーが決まってるんだからできるはず。
インポスターでよいのでは？
Quest単体でログインして自分でインポスターを着れるようになったら呼んでください。
実はQuestってQuest対応アバターしか使えないんですよ。ご存じでしたか？
あと、いちいちWebを開いてポチポチするのがめんどくさいのでアップロード後すぐに自動で生成してほしいです。
以上です。