UniVRM [1.0] Library を削除するなどの初回アセットロード時、 `Migrate to Vrm 1` オプションを有効にした vrm ファイルアセットがエラーでアセット化されない

環境情報

UniVRM version: 2.43.2　/ VRM1.0 Unity version: Unity-2020.3.36f1 OS: Windows 10

バグについて

これをバクとするか仕様とするか、判断に迷いましたが、知らないと現状復帰できないのこちらに書かせていただきました。

＜症状＞ Library※を削除すると、FBX化したVRMファイルがFBXとして認識しなくなる。結果として、インスペクターとのリンクが切れる。 ※正確には、Artifactsフォルダ・関連ファイルで、ShaderCacheなどは削除しても復帰します。

複数人数で開発しており、Libraryはサブバージョンのコミット対象からは外しております。プロジェクトのコピー、UnityEditorのバージョンをアップした際に、初期化のためにLibrary削除しておりますが、現状、Library削除すると、VRM10でFBX化したファイルがすべて使用不能になります。再度、migrate　を実施すればリンクも含め回復します。

現状、旧バージョンでは問題ないため、現在は旧にもどして対応する予定ですが、将来的にご対応いただければすごく助かります。

よろしくお願い申し上げますm(_ _)m

削除前削除後

Jan 22 '23 10:01 Nekohatsuden

バージョン追記しましたm(_ _)m

Jan 23 '23 05:01 Nekohatsuden

報告ありがとうございます。特に Unity や UniVRM のバージョンに関係なく報告の現象を手元でも確認したので、タイトルを変更させていただきます。

もしよろしければ、問題のない Unity と UniVRM のバージョンの組み合わせをいただけないでしょうか？

現状、旧バージョンでは問題ないため

確認した環境

Unity 2020.3.36 & UniVRM 0.108.0
Unity 2020.3.36 & UniVRM 0.107.0
Unity 2019.4.30 & UniVRM 0.99.1
Unity 2019.4.30 & UniVRM 0.82.1

Jan 26 '23 13:01 Santarh

https://github.com/vrm-c/UniVRM/issues/1971

…のバージョン表記もそうでしたが、勘違いが起きるような報告にて申し訳ござませんでしたm(_ _)m 当方が、UniGLTF と　UniVRM　の違いを正確に認識していませんでした。

確認した内容は下記の通りです。

<動作正常> UniGLTF 2.43.2 / UniVRM　0.107.2 ←旧バージョン Unity version: Unity-2019.4.35f1

★念のための補足★ 0.107.2では、vrmファイルを展開した後、vrmファイルを捨ててよかったので「結果として問題ありませんでした」。以前の課題として、 GitやSubversionで他の場所でPULLすると、PULLした場所で毎回新規にVRMを展開しなおす為、どこかでPULLをするたびに、vrmファイルが作り直され、コミットデータが莫大・Unity起動時間も倍になるという状況が発生していました。

対策として「一度vrmを展開してそのデータだけをコミットすれば、オリジナルvrmファイルは削除(または拡張子を書き換える)」を行って、Unity起動時にvrmファイルを認識させないようにしました。 0.107.2 は、vrmファイルは本体ではなかったので、データだけコミットして対策できていました。 ↓以前報告した内容ですm(_ _)m https://github.com/vrm-c/UniVRM/issues/1784

UniVRM 2.43.2 / VRM1.0　 ←新バージョン Unity version: Unity-2020.3.36f1 ライブラリーを削除すると、FBX化したものが、すべて vrmに戻ってしまい、プレハブ・バリアントも中身がすべて消えてしまいます。 0.107.2と異なり1.0ではvrmがファイル本体なので、0.107.2のようにデータ本体を展開してコミットする回避方法がとれません。

質問: 1.0のvrmファイルを、0.107.2のように、すべてデータ化できないでしょうか?

現在は、 UniVRM　0.107.2に戻して開発しています。よろしくお願い申し上げますm(_ _)m

Jan 27 '23 03:01 Nekohatsuden

この問題は UniVRM ライブラリ内のロードが終わる前に VRM ファイルのアセット解決が起きてしまうため起きる問題になります。したがって Unity Project を再度開くとか、VRM ファイルを Reimport することで回避可能で Prefab Variant なども問題ありません。

この問題自体は、引き続き調査いたします。

分かりづらいのですが、本 UniVRM は 2 つの VRM ライブラリを内包しています。ひとつは従来の VRM 0.x ファイルを扱うためのライブラリ（場所は Assets/UniVRM )です。もうひとつは VRM 1.0 ファイルを扱うためのライブラリ (場所は Assets/VRM10 ) です。これは VRM が規格として 0.x と 1.0 の２つあり、この差異に対応するためです。

そして従来「VRM 0.x ファイルを Prefab に変換していた」機能は前者のライブラリです。またここで焦点となっている「VRM ファイルをそのまま ScripterImporter でアセット化する ( @Nekohatsuden さんの言うところの FBX 化 )」機能は後者のライブラリです。

したがってもし従来の昔の挙動を維持する必要があるのであれば、前者のライブラリ ( Assets/UniVRM ) を使い続けてもらって構いません。またその場合、後者のライブラリ ( Assets/VRM10 ) は消してもらって構いません。（もちろんその場合 VRM 1.0 は使えなくなりますし、型などはすべて変わってしまいます）

Jan 31 '23 07:01 Santarh

ご回答をありがとうございましたm(_ )m 現状、やはり処理速度・開発の利便性が重要であるので、当面は旧VRM 0.x にて進めようかと思います。基本はアバター向けの企画のようですが、ゲーム関係にも意識してもらえるとすごく助かりますm( _)m

Feb 01 '23 23:02 Nekohatsuden

実装メモ VRM ファイルの ScriptedImporter.OnImportAsset() において、ファイル自身のロードより前に VRM 用シェーダアセットがロードできていないことが問題。おそらく以下の関数で依存するシェーダを宣言すれば直りそうだが、Editor 芸が必要。

https://docs.unity3d.com/ScriptReference/AssetImporters.AssetImportContext.DependsOnArtifact.html

Mar 06 '23 10:03 Santarh