Open FujiSunflower opened 1 year ago
ousttrue
commented
1 year ago vrm-0.x の仕様は、修正しない方針です。
vrm-1.0 は center に関する記述があります。
Centerノードは、そのSpringChainの0番目のJointもしくは、その祖先nodeである必要があります。 また、Centerノードには、他のSpringChainのJointノードおよびその子孫を指定することはできません。
vrm-1.0 のエクスポート時に この制約外れることはお勧めでないという警告を出すことは可能です。
FujiSunflower
commented
1 year ago VRM 0系の仕様を修正しない代わりに、説明がVRMドキュメントにあるのが落とし所ですかね。
VRM 0系ではCenterに指定可能なノードに制約はありませんが、VRM 1系ではCenterに指定可能なノードに制約が設けられました。
ousttrue
commented
5 months ago
概要
特定の条件のアバターでVRM SpringBoneの挙動がアプリ毎に異なる現象が見つかりました。 原因はVRM SpringBoneのCenterに指定したノード階層によるもので、VRMの仕様に制約を追加する必要があると感じました。
検証
環境
詳細
Metasequoiaから出力したようなHipsボーンが直接Rootボーンとなっているアバターを使用します。 このアバターでHipsボーンと同じ階層のゲームオブジェクトをVRM SpringBoneのCenterに指定しました。
このアバターをSimpleViewerで読み込みます。
実験として、SimpleViewerのシーン上にあるVRMとVRMのHumanPoseTransferの元であるtmpをそれぞれ平行移動してみました。
考察
アバターの移動方法がUnity上で主に2種類あることが違いを生んだようです。
ところで、Rootボーンの子階層にHipsボーンがありRootボーンと同じ階層のゲームオブジェクトをVRM SpringBoneのCenterに指定することが現在のところ可能です。この場合だと上記のどちらの方法でもスカートの激しい揺れが起こりません。Hipsボーンだけが移動するため、Rootボーンと同様にCenterのゲームオブジェクトが取り残されるからです。
また、VRoid Studioで作られたアバターにはRootボーンがありCenterとして指定されています。 この設定方法はUnityのルートモーションを想定したものと考えられ、上記２種の両方の移動方法を考慮していそうです。
提案
検証したようなテクニカルな設定方法が出来るとアプリ毎の挙動の差を引き起こすためVRM SpringBoneのCenterに指定出来るノード階層をHipsボーン以下の階層とする制約が必要かなと感じます。 もしくは、テクニカルな設定方法を可能とする代わりにRootボーンの有無を決めてしまう必要があるかなと感じます。 厳密な制約条件としない場合でもドキュメントに記載が必要な内容ではあると感じます。