見出し画像

VRCQuestTools 2.4.0 あとがき

クロツ

VRCQuestTools 2.4.0 をリリースしました。例によってあとがきです。


非破壊フォールバック

2.3.0ではNDMFを使った非破壊改変アバターをマニュアルベイクなしでアップロード出来るようになりましたが、フォールバックアバターの設定はできない状態でした。技術的に難しいとかそういうことでなく、単に忘れていただけなのですが。

フォールバック改変をする機会ってそんなにないし…(最後に改変したのは約3年前)

フォールバックを設定すること自体はVRCApi.SetAvatarAsFallback()を呼び出すだけで良いのですが、いざ実装してみるとアップロード済みのアバターのパフォーマンスランクに関係なくフォールバックに設定できてしまう問題がありました。(なお、手順が分かるとVRCQuestToolsがなくてもVRCSDKだけで任意のアバターをフォールバックにできてしまったりします。とはいえおそらく機能しませんが)

流石にそのまま出すわけにもいかないので、ビルド後のパフォーマンスランクがGood以上である場合にのみフォールバック設定をするようにしました。実装としてはIVRCSDKPreprocessAvatarCallbackを使ってVRCSDKのビルド処理の最後のタイミング(NDMF等の処理がすべて終わったタイミング)でパフォーマンスランクを調べておき、アップロード完了後にフォールバック設定をするようにしています。要するにやっていることはActual Performance Windowの変形・応用です。

Constraints

VRC ConstraintsがLiveに来たことで、AndroidでもConstraintsが使えるようになりました。VRC内でUnity Constraintsからの自動変換があるとはいえ、相変わらずAndroid向けのアップロードには使えません。このあたりはDynamic Bone→PhysBoneの移行時と同じです。

そのため現状は各自でUnity ConstraintsをVRC Constraintsに変換する必要があり、専用の警告をAvatar Converter Settingsに追加しました。PhysBoneと違いハードリミットを超えるケースが当面はなさそうなのと、Live移行時の不意打ちハードリミット追加もなかったので、VRC Constraints Removerのようなものは用意していません。Constraintsは非破壊改変で自動生成されるケースも多いので、あまり複雑なことをしたくなかったというのもあります。

変換ボタンまで入れたのは勇み足であったような気もしており、2.4.2では警告表示のみ

Quest側から見ると単純に機能追加であり、自身でConstraintsを設定して使うことがなかったため、ここ数日の互換性問題等々を対岸から眺める日々であります。
(一番メインで使っているアバターでさえ標準でConstraintsが入っていることに半年くらい気付かなかった程度には関心がなく、また壊れていても気づくことができないのでした)

iOS対応

対応、といってもプラットフォームごとに分岐する処理を点検してiOSとAndroidでほぼ共通にしただけです。

ワールドの自動変換が既にできており、かつアバターはシェーダーの選択肢が決まっていることからアバターの自動変換ができない道理はないので、今がんばってiOSビルドでのアップロードを頑張る必要はないと考えています。iOSベータの招待を受けて自分が使うアバターに困る人向けの改修と言えます。

非破壊でQuest Poorまで軽量化してiOSビルド (マニュアルベイクなし)

テクスチャフォーマットのチェック

iOSビルドでエラーになっていたのはこの部分で、iOS自体を非対応プラットフォームとしてエラー扱いにしていたことでした。今回、iOS用のチェックを実装するとともに非サポートのプラットフォームではテクスチャフォーマットのチェックをしないように修正しました。

折角なのでそもそもなぜVRCQuestToolsでテクスチャフォーマットのチェックをしているのかという話を書いておきたいと思います。

まず前提知識として、アバターやワールドをビルドするときにはpngなどの画像ファイルをそのまま使うことはなく、Unityが裏側でGPUに適した形式(DXTやASTC等)に自動的に圧縮したものを使うようになっています。プラットフォームによって使用可能なフォーマットが決まっており通常はUnityが自動的に切り替えをしてくれます。

ですが、NDMFのビルド中に生成したテクスチャはこれができない(ビルド完了までTextureImporterが動作しない)ので、各プラグインが自前で直接Texture2Dオブジェクトを生成・圧縮する必要があります。
このときマニュアルベイクをした時点でテクスチャフォーマットが決まってしまうので、後からSwitch Platformを実行してアップロードすると非対応のテクスチャフォーマットを使用することになり誤動作の原因になります。

上のIssueのように黒色になるだけならよいのですが過去のトラブル事例として、手動で誤って非対応フォーマットでテクスチャのオーバーライドを設定したことによって、使用するとインスタンス内のQuestユーザを巻き込んでクラッシュさせるアバターが生まれたということがありました。

当時はUnity 2019への移行期だったことと、Crunch圧縮が知られ始めて(よくわからず)手を出す人がいたということが組み合わさって、後から見ると切り分けの大変そうな問題だったなと思った記憶があります。
この手の問題はアップロードの時点で検出できる方が適切でしょうから、2.3.0からはテクスチャフォーマットのチェックをするようになっています。

できるだけ非破壊アップロードを使うこと、マニュアルベイクする場合はアップロード先のプラットフォームに切り替えてから実施すること、を気にしておくとよいです。

MA Visible Head Accessory, MA World Fixed Objectの対応

これらMAのコンポーネントは内部でConstraintsを使っておりAndroidビルドでエラーになるケースがあったため、これまで非対応コンポーネントとして変換過程で削除していました。
MA 1.9.0以降ではMA自身がプラットフォームを判別してAndroidでは無効になるよう制御していることと以下のような状況が整ってきたことから、この制約を外すことにしました。

  • Visible Head Accessory: MA 1.10.0でUnity ConstraintsではなくVRC Head Chopを使った実装に置き換わる見込み。

  • World Fixed Object: 将来的にVRC Constraintsを使った実装に置き換わるとPC/Android両対応になって嬉しい。

おわりに

非破壊アップロードの実装以降、忙しくなってきたこともあってあまり動けていないのですが、新機能の実装は進めていきたいところです。

当面の目標としては非破壊でのメッシュの反転かなと思っています。反転・両面張りはなんとなくできた気がしますが、頂点を複製しての両面張りがうまくいっていません(あとノーマルとかがすごく適当)。ToonLit前提ならそれで充分なのかもですが。

あとは、OVR Lighthouse Managerの要望対応とかも進めたいですね。


いいなと思ったら応援しよう！