GestureWeightSmoothingでInterruptionSourceを設定する場合の不具合について
Tukumomiさんの検証（時系列）
このAFKを高速で切り替えたときだけバグるのってなんでなんでしょうね…？
最初はアバター更新入ってその影響でバグるのかなとも思ったんですがちょっと違うバグり方なんですよねー
Actionレイヤーも見てみたけどそんな変な作りしてないしVRC自体の不具合な気もしなくない～
アバター☑
┗衣装まとめ☑
┗各衣装
┗各部位☑
って感じで分けて、デフォルト状態は上記でその後初期状態上書で
アバター☑
┗衣装まとめ☑
┗各衣装☑
┗各部位
になってから各部位のオンオフ切り替えをしてるんですが、何故か各部位の変更は適用されないで各衣装がオンになるんですよね…
ComponentにSkinned Mesh Rendererを持っているメッシュのみIsActiveがデフォルト状態(アップロード状態)に戻されるって言った方が伝わるかも…
マヌカちゃん(だけ？)でAFKを連続して切り替えるとAnimatorの特殊にゃ再読み込みが発生しちゃうバグについてのツイート～
※Animationを2フレーム(1フレーム目と同じ値にコピーするやつ)に変えるとある程度改善
※以前から存在する、同じオブジェクトを操作するAnimationが連続すると特定条件？でAnimationが再生されにゃくにゃるバグも誘発されるみたい
Gesture Managerをお使いのようですが、Av3Emulatorを使うと変わったりしますか? (Av3Emuの方が、VRC上での挙動の再現度がより高いです)
AV3Emuはまだ使ったことにゃいので今使い方を調べてます！
VRC上でも確認しましたが同じ挙動をしますね。他の人視点でも同じ挙動のようです。
いろいろ検証してた時、何故かFXの付け外しで治った時があることからUnity側のキャッシュが悪影響及ぼしてるのかにゃ…？とプロジェクトのLibraryフォルダ削除しても見たのですが変わらず…
何故かこのバグ時のAnimator再読み込み時だけ再生されにゃいAnimationがあるんですよね…
(元ツイートにも記載していますがAnimationが再生されにゃい時があるのは以前から認知しているバグです。根本的にゃ原因は不明ですが…
Av3Emuでも試しましたがやはり同様のバグが発生しますね…
少し複雑にゃのですが、今回発生している問題はまとめると下記のようににゃります。
※いずれも検証中で不確かにゃ情報を含むことをご留意ください。
前提条件：FX、ActionレイヤーはWDオフ。Animationは別のバグ回避のため2フレームで作成。
発生条件：マヌカのAFK「AFK_Intro」再生中にAFKを抜ける
発生事象：FXが再読み込みされ以下のバグが発生
・特定のAnimationが再生されにゃい
(今回の場合は初回のみ実行しているアバターの初回セットアップAnimation)
・Animationは再生されるがSkinned Mesh Rendererが設定されているオブジェクト(？)だけAnimationに登録しているIsActiveが適用されにゃい
・EXパラメーター経由で保存されているはずのパラメーターが数フレーム？だけ反映されにゃい(Entry直下のStateでEXパラメーターに保存した変数で判定を行おうとしてもDefault状態で判定されてしまう。)
GestureManyagerとAv3Emuで違いがあったのでそちらも追記しておきます。
GestureManyagerだと初回Animationが再生されにゃかったのですが、Av3Emuだと再生された(再生はされるけど上記の問題が発生)という感じでした。
挙動的にはAv3Emuの方がVRC内の動きと同じようですね。
このバグ、FX他のレイヤーは変動が多い&初回のみ実行するAnimationが”ほぼ”無いから問題にならなかっただけっぽいんですよねー
まぁAFK連続で押さなければ発生しないからそこまでクリティカルな問題じゃないんですが…
発生条件の方で記載漏れがあったので追記します！
発生条件：マヌカのAFK「AFK_Intro」再生中にAFKを抜ける
↓
発生条件：マヌカのAFK「AFK_Intro」再生中にAFKを抜ける
※ただし、最速でAFKを連打すると発生しない。AFK押してから0.5sくらい待ってからAFKから抜ける発生
となります…(複雑すぎる～
初回セットアップAnimation作らにゃいでアップロード時にオブジェクト状況合わせれば(たぶん)バグらにゃいんだけど…
gesturemanyager通さにゃいでデバッグするときに恐ろしく手間にゃので…
検証進めたので追記です。
いろいろ検証した結果、多分にゃんですがAnimatorが再読み込みされてるっていうのは勘違いで、
「AFKバグ誘発時にSkinned Mesh Rendererが設定されているオブジェクト(メッシュ)のみアバターアップロード状態に戻される」という挙動を取っている気がします。
メッシュに限定したWDオン時の挙動みたいにゃ感じですね。
詳細は割愛しますが、Animationが再生されにゃくにゃる不具合がAFK関係にゃしに発生していた影響で勘違いしていたようです。
(このバグはこのバグで発生条件がよくわからにゃいのですが回避自体は可能です。)
このツイートとそのツリーでも呟いてますが、ある程度原因は絞れたけど何故それが発生するかが本当に謎！
Av3Emuですら謎にゃ挙動をするので…
リセットアバター関係にゃく初回しかバグらにゃい～
VRCだと確定で何回もバグるのに…
GWSを入れた上でさっきの動画のここの設定を「None」「Current State Then Next State」以外にするとバグるらしい…
(隠れて見えないけどその下にあるOrdered Interruptionは関係なかった)
これ原因分かりました～
どうやら「パラメーターを変動させるAnimation」とTransitionの設定の「Interruption Source(Next StateとNext State Then Current State)」が悪さしてるっぽい…
WDオフで、どこかのレイヤーでパラメーターを変動させるAnimationを再生中に任意の場所でTransitionの設定のInterruption Sourceの「Next State」か「Next State Then Current State」が動く(割り込みが発生する)と”今までの変更状態はそのままに、メッシュだけデフォルト状態に戻る”バグが発生する～
今回はGestureWeightSmoothing(GWS)が原因で発生してたみたい…
あとどうやらこの”パラメーターを変動させるAnimation”、FXだけじゃにゃくてアバターに含まれるAnimatorどれかに1つでも含まれていると問答無用で「Next State」実行時にバグるみたい…
にゃして…？
発生原因が分かったので綺麗にゃ対策が打てるようににゃりましたが明らかにゃバグで頭抱えてる～～～～
影響範囲大きそうなので一応タグつけて投稿しておきます～
似たバグに遭遇した方が居たら参考までに…！
簡単に説明すると「アバターに使用しているAnimatorで”パラメーターを変動させるAnimation”が再生されている状態だと、特定条件下で全てのメッシュの状態がデフォルトに戻る」バグです
原因解明できましたので共有します！
原因は下記のようです。
今回はGestureWeightSmoothingが引き金ににゃっていたみたいです。
原因が分かったので対策も出来たのですが、Interruption Source(Next State関連)を使用すると発生する可能性は依然として残っているのであまりすっきりはしにゃい結果とにゃりました…
このバグはAnimatorのくくりを受けにゃいのが恐ろしいですね…
(Gestureレイヤーで問題のAnimationを再生しててもFXで条件を満たすとバグが発生するみたいです。)
ほぼ自己解決ににゃってしまいましたが、お気に留めていただきありがとうございました！
TransitionにあるInterruption Sourceの「Next State」「Next State Then Current State」にゃんて凝ったギミック作る人にゃら普通に使いそうにゃので恐ろしいところ～
今回見つかったのはうちの子の作りが特殊にゃのも影響してたけど…
BlendTreedirectバグまみれの印象。
あまりちゃんと読めてないけど、昔naqton先生も言及していたこれとは別事象なのかな。
BlendTreedirectは関係にゃいんですよね…
(GWSはBlendTreedirect使用してにゃい&Blendtree自体も確認したけど問題にゃかったので)
あくまで”パラメーターを変動するAnimation”が問題を引き起こしてるみたいです
”パラメーターを変動するAnimation”はこういうやつ～
Animationの中にAnimatorで設定してるパラメーターを変更できる～
(私もGWSの中身見て初めてAnimationにパラメーター登録出来ること知りました…ｗ
Interruption Source、WDオンありき機能っぽく、使うなよ！みたいな話が、WDオフがVRChatの推奨になったあたりで(英語圏つよつよ勢の間で)話題になってたわね
海外ユーザーの間だとInterruption Source自体がWDオン推奨みたいな話があったみたいですね…(知らなかった！
昨日のバグもっと簡単に発動するっぽい…
うーん考慮不足…(想定外の動きしすぎてるから考慮の難易度が高すぎる問題ある～
メッシュにだけWDオンみたいにゃ挙動するのが解せにゃいんですよね…
普通にWDオンみたいに全部リセットされるにゃらもう少し早く気づけたんですが…
そもそもなのですが"メッシュにだけ"というのがよくわかってないのですがSkinned MeshのBlendShape ShaderProperty等を指していますか？
(SkinnedMeshRendererのm_MeshはAnimationでいじれなかった記憶があるのでよくわからんになっていました)
Skinned Mesh Rendererが割り当てられてるオブジェクトのIsActive状態がリセットされる形ですね。
BlendShapeにまで影響するのかまでは未確認です。
(Twitterの方には追記したのですがMisskeyの方に追記しそびれてました！)
情報が抜けてたので追記です！
確認バージョンはUnity2019、VRCSDK3.4.2です。
メッシュがデフォルト状態に戻るというのはSkinned Mesh Rendererが割り当てられるGameObjectのIsActive状態のことを指してます！
※マテリアルやBlendShapeがどうにゃるかは未確認。
それから、更に細かい発生条件が絞れたので追記します。
「Parameterを変動させるAnimationがいずれかのレイヤーに含まれている状態」で、Interruption Source＝Nextな遷移が発動するだけでバグが発生するようです。
※対象のLayerWeight=0がでも発生することを確認。
(複数要因が絡んでいるようにゃのでまだ考慮不足もあるかも… )
↓画像みたいにゃ状態でもInterruption Source＝Nextにゃ遷移が起きるとバグります。
もはやInterruption Sourceをすべての遷移でNoneにするか、そもそもparameterを変動させるAnimationを使用しにゃいかどちらかしか対策が取れにゃくにゃったので終わりました！
おのれー！
ついでにマヌカちゃんのAFKにもInterruption Source=Nextにゃ遷移が含まれてるので対象のAnimationがどこかに混入するだけでバグります。
他の方が確認取ってくれたのですが、Interruption Source＝Nextを設定しているTransitionのTransitionDurationが0以上だとこのバグが発生するようです。
あと確認してくれた方曰く、AudioSource、パーティクル、MeshRendererの設定、マテリアルの色あたりも全部リセットされるみたいです…。
こうにゃってくるともうInterruption Sourceは全部Noneで運用した方がよさそう…
(回避策もラグった時の動きが怖いので
こちらでもInterruption Source＝Nextを設定しているTransitionのTransitionDurationを0にしたら発生しにゃくにゃるのを確認しました～
ただ…globalでのラグを考慮するとやっぱり怖いですね…
これからギミック付きのものを買ったときにすべての遷移でInterruption Sourceが使われていにゃいか確認する必要性が生まれてしまった…
いやGWS抜けばそれで解決はするんですが…
「- 本ギミックはAAPを使用しているため、アバターでInterruption Source＝Nextの遷移が発生すると様々なものが初期化されるバグが発生します。」 でいいかな
正確にはInterruption Source = Next"系列"ですね
これはWD関連のバグなのでWDオンの環境なら多分大丈夫なはず～
DBTだけWDオンの場合は試してないので一度試してみた方がいいかも～
(AAP含んだアニメーションがAnimator内に含まれてるだけでアウトだったので駄目な気がしなくもないw)
そういえば以前から気になってたんですがAAPって何の略なんですかー？
何かのツール？
AAPは・・Animated Animator Parametersです！
ざっくりいうとDBTから読み書きできる変数です！便利！
ただしExParameterには(Contact使わないと）出力できない。残念。
WD関連、いろいろなバグがあるので詳しく見ないとどれかは不明なんですが、見付けにくいバグだとこういうのもありましたよ～
(Unity側のバグ
あと今現在WDオフで動かしてるとなにもしてないくても↑のようなWDオン"モドキ"の動作がそれぞれのローカル環境下でランダムに起きる謎バグがあります
謎バグの方は滅多に起きないんですが発生条件が謎過ぎるので諦めてます～
(デフォルトから変更するアニメーションはAnimatorの何処かで常に再生し続けるのが安全ではある…)
WD ONでは発生しない？
ローカルでのみ発生する？
着替えアニメーションを再生し続けていれば発生しない？
WD ONで表情がおかしくなるのを防ぐために、最上位レイヤーでデフォルト表情を再生するのと同じ？
Tukumomiさんの検証まとめ
現象
Skinned Mesh Rendererが割り当てられてるオブジェクトのIsActive状態がデフォルト状態(アップロード状態)に戻される
つまり、着替えアニメーションがすべて無効化される
AudioSource、パーティクル、MeshRendererの設定、マテリアルの色などもすべてリセットされるらしい
条件
「Animatorのパラメータを変更するAnimationClip」をいずれかのレイヤーのいずれかのステートで再生している
WD OFFの場合のみ発生？
つまりON・OFF混在のときも発生する？(OFFが優先されたはず）
トリガー
「Interruption Source が Next または Next State Then Current State」かつ「TransitionDuration が0より大きい」遷移が実行される
GestureManyagerやAV3Emuでも再現可能
ただし初回のみ？
WD OFFにする場合は、Interruption SourceをNoneにすべき
Interruption Sourceの機能はWD ONと同等のため
"WD On breaks transition time to blendtrees when a parameter is Animated" のケースに該当？
対応策
WD OFFにする
ここまでの調査だと逆っぽいが…
複数ステートのレイヤーでBlendTreeを使わない
AnimatorのパラメータをAnimationClipで操作しない
BlendTreeからの遷移がおかしくなるバグだからちょっと違うか
下記の2つのステートを作る
出力値をGestureWeightに近づける
出力値を0に近づける
0になるまでの時間を指定
処理速度によらず一定の速度で減少させたい
GestureWeightに近づける場合と同様の方法をとった場合、すぐに出力値が0になる
0までの遷移を中断して元の状態に戻るためにInterruptionSourceを使っていた
出力値の減少が遷移によるものでなければInterruptionSourceは不要
AnimationClipで減少させればいいか？
再生開始位置を制御したい
MotionTimeだと停止してしまう
CycleOffsetが使える？
オフセットした分は末尾に追加される？
Offset at which the animation loop starts. Useful for synchronizing looped animations. Units is normalized time.
AnimationClip loop time needs to be checked to use cycle offset, otherwise cycle offset won't have any effect. Valid range is 0 to 1.0.
この説明だと末尾に追加されるかどうかは不明
VRCのアバターでTimelineを使うことはできない
NDMFですべてのステートをチェックして、InterruptionSourceがNoneでない遷移がある場合はスムージング無効化を提案する？
遷移のチェックにどれだけかかる？
AnimatorControllerの探索は他のチェックと共通化したい
Interruption SourceがNextを含む場合のバグは報告されているが、Currentだけのケースでのバグは報告されていない
とりあえずCurrentに変更して様子を見るか？
MA ShapeChanger不具合にともなう調査
再現手順
萌のソックスにShapeChangerをアタッチして、Body_allのKneeをDelete
元々のExMenuでソックスを消して、ハンドジェスチャーをFistからNeutralに変更
デスクトップモードでも良い
ソックスが消えたままであれば不具合なし、一瞬ソックスが出現すれば不具合あり
WD ON統一時には発生しない
WD ON・OFF混在時には発生する
MA 1.10.4, NDMF1.5.5で発生
MA 1.10.5で修正
対症療法に近い
一瞬で切り替えるアニメーションでチラつきが発生しているため、ウェイトを入れてから切り替えるアニメーションに直している
Interruption SourceをNextからCurrentに変更しても解消されない
スムージングレイヤーの構成をCurrent仕様に変更 → NG
そのままの構成でCurrentに変更 → NG
そのままの構成でNoneに変更 → NG
スムージングを切ると解消される
Resetステートを削除すると解消される
Resetステートを削除したことにより、BlendTreeのアセットが消えてスムージングレイヤーが機能しなくなっていた
テンプレートのレイヤーをコピーしておらずそのまま参照している…
復旧にはFaceEmoの再インストールが必要
Resetステートへの遷移を削除すると解消される
スムージングレイヤーのすべてのステートのWDをONにすると解消される
他の設定は変更していない（FaceEmo1.5.5適用直後の状態）
「WD ON統一時には発生しない」との辻褄が合う
スムージングレイヤー以外のWDはOFFでも問題ない
現状、VRCではWD OFF推奨という認識が広まっているため、これはちょっと厳しい…
やはり「WD OFFでも問題ない組み方にして、WD ONにする」がベストっぽい
WD OFFの書き戻し処理が原因かもしれない
ソックスのトグルのWD ON・OFFは関係ない
検証まとめ
Resetステートへの遷移が存在する場合に発生
InterruptionSourceは関係ない
そのため、Next → Currentへの変更のための構成見直しは（少なくともShapeChangerには）効果がない
Resetステートへの遷移が存在しても、WD ONにすれば発生しない
考察
「AAPレイヤーで短時間に複数のステート遷移発生」が条件？
Listening -> Waiting -> Resetで遷移するとダメ？
BlendTreeが消えている場合（つまりAAPレイヤーではない場合）は大丈夫
先の不具合も、実はInterruptionSourceは関係なかったのでは？
InterruptionSourceの有無により、パラメータ変更までの時間が変わることが本当の原因だったのでは？