Silc Lizard (Tokage) Renew

hips の高さの格納には大きく賛成します。しかし、 Humanoid ボーン以外へのアニメーションは許可しない感じですかね？ これについて、 root をボーンとして定義したアニメーションもといルートモーション(※1)への対応を希望します。 最近のゲームエンジンではルートモーションという機能があり、移動モーションや攻撃モーションを実装する際に、基本的に hips の上に root ボーンを追加し、その root ボーンへアニメーションをつけます。この時、体格差による歩幅を調整する為には、足の長さつまり**アニメーションを作成したモデルの hips の高さ**と適用するモデルの hips の高さの比率を用いるとスリップを抑える事ができます。 root ボーン自体はモデルの読み込み時に原点にジョイントを追加するだけなので、アプリケーション側で容易に対応できるのですが、アニメーションファイルの方で root ボーンが許可されていない場合どうにもならなくなるので...。 > 異なるモデル・アプリケーション また、 0.x 現在の VRM ではモデルのローカル方向が破棄されているので、ローカル方向が定義されていないと指が変な方向に曲がるといった事が考えられます。そちらについては #34...

glTF 2.0 のアニメーション仕様を VRM にそのまま継承するのであれば、単純にアニメーションを付けたモデルを glTF として出力すればよいように思えるので、VRM としてアニメーションデータを定義する意義は薄いと感じますがその点は如何でしょうか。 一つ問題があるとすれば、glTF アニメーションはローカル軸破棄前のレストポーズを起点としてアニメーションを行います。また、私の記憶が間違っていなければ、glTF アニメーションには「レスト」と「ポーズ」の区別が存在せず、全て「レスト」の値をアニメーションさせるような形で記録されているという点において glTF 2.0 のアニメーション仕様そのままでは少し扱いづらいかと感じます。この点、VRM モデル自体がローカル軸を破棄する現状においては、アニメーション側もローカル軸を破棄すればさほど問題にならないので、エクスポーター側の問題となります。 なので、例えば @qhnu さんが blender を使っているのであれば、「blender の VRM addon にローカル軸を破棄した上でのアニメーション付き glTF を出力して欲しい」という要望を出すのが良いのではないでしょうか。 またその際、モーションの使い回しを考えているのであれば、human bones のリネームをするしない等のオプションがあったほうが良いかもしれません。VRM モデルの...

> アニメーション側のローカル軸を破棄すると対応できる @qhnu もしくは、初めからローカル軸を破棄した状態のモデルをアニメーションさせて glTF アニメーションを書き出すことで、想定通りのアニメーションが適用できる筈ですが、そもそもローカル軸を破棄してしまうことによりモデルの関節の正しい回転方向が分からないという問題があるので、決して良い方法とは言えません。宜しければ #34 やこちらの記事も参考としてご覧下さい。 https://qiita.com/TokageItLab/items/e5880123a9f508b2769d#%E3%82%A2%E3%83%8B%E3%83%A1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E5%85%B1%E6%9C%89%E3%81%8C%E5%AE%B9%E6%98%93%E3%81%AB%E3%81%AA%E3%82%8B

> 1.0においては 今後定義される可能性はあると言う事でしょうか。上でしげぽんさんが仰ったような S 字湾曲のようなケースに対しては、確かにオフセット値よりボーンのローカル方向の推定は可能です。しかし最初にある指のようなケースに対して、ロール値の推定をオフセット値から行う事は容易ではありません。 Unity の Mecanim はブラックボックスなのではっきりとは分かりませんが、モデルやアニメーションに対して恐らくインポート時にローカル方向の推定を内部的に行っているのではないかと考えられます。 ローカル方向を破棄してしまうと、例えば一つのアニメーションデータを用いて Unity の内外で同様のアニメーションを行うためには Mecanim と似た様な実装を各プラットフォームに強いる事を意味し、 Mecanim はブラックボックスである事により、一貫性が失われてしまいます(※1)。また、 Mecanim を各プラットフォームに実装する事と比較して考えると、上で FMS-Cat さんが書かれていますように、各ボーン軸をワールド軸に向ける処理をアプリケーション側の VRM インポーター等で必要に応じて実装する事の方が遥かに容易ではないでしょうか。 規格としてデータを揃える上で、ユーザーによって乱雑になりやすいデータを破棄するという事は一番簡単であり確実な方法ですが、失う物が大きいという事にも留意して頂きたいと思います。 #176 のようにローカル軸の名前を定めるのであれば、例えば Blender の Fortune アルゴリズムで推定されるようなローカル方向をロール値も含めて VRM...

私自身、 Godot というゲームエンジンで VRM に対応するかどうかというプロジェクトに関わっておりますが、 #12 でも挙げられているように、現在の仕様ですと Unity の Mecanim から離れてボーンの操作を行う事は困難です。 Blender の VRM Importer ~~（恐らく Fortune での方向推定）~~（独自の決め打ちベースの方向推定っぽい）を用いたとしても本来のロール値は破棄されており、再編集やアニメーションの作成を行う事が困難である事に変わりはありません。 繰り返しになりますが Mecanim のようなリターゲッティングシステムの利用が前提にあると、ルックの一貫性・ポータビリティという点については Unity を離れた時点で破綻してしまいます。プラットフォーム間の互換性を考えるのであれば、ローカル方向をガイドラインで定める等してローカル軸の維持を行う必要があると強く感じております。 ---- 例えば Blender のボーンのローカル方向は進行方向が +Y となり、 VRChat...

本件に関しまして私の方でも問題点と解決案をまとめていまして、今月末に開催される[ VRM 勉強会](https://vrm.connpass.com/event/205289/)で発表するように考えていました。 本件はいくつかの issue に跨がる問題であり、また Unity 以外の環境についても考慮・説明する必要があるので、まとめるのに手間取っておりますが、少なくとも一つ言えるのは現状のロール軸の定義に２軸使っているような定義では親指の回転方向を定義する事が明らかに不可能なので Unity 依存を断ち切る上では定義の変更は避けられないという事です。

恐れながら、ローカル軸の破棄により起こる問題と改善案をまとめさせて頂きました。 https://qiita.com/TokageItLab/items/e5880123a9f508b2769d 改善案についてはあくまで提案なので、完全にこの通りにしろというわけではなく（して頂ければ幸いですが）、そこは議論していく所だと思いますが、記事中のまとめ部分に記述したように、最低限以下の２つは「プラットフォームを越える汎用アバターフォーマット」として必要であると考えます。 - 正規化処理でボーンのローカル軸の方向を破棄するような実装は避ける - 回転軸の役割が X Y Z で一意に決まるような定義を行う 関連 #54 Humanoid bone の向き？ #83 SpringBone の回転方向の制御 #118 アニメーションデータについて #176 ローカル軸の定義

Context: #83 Does this issue means considering to implement feature like DynamicBone's Inside Collider to SpringBone? I've wondered about it before, because the implementation cost seems inexpensive. Reference for Inside...

破壊的変更を glTF データの本体部に持たせている理由としては、インポート時に glTF データの本体部に対しての処理を行いたくないという理由がありそうですが、だからといって破壊的変更を本体部に適用した物を標準とするのは良くないと考えます。 よく問題として挙げられる、 - 再編集が困難 - Unity 外での利用が困難 これらの原因がその破壊的変更にあるように私は考えており、現状では Unity Humanoid 専用フォーマットから脱却する事は難しいと考えております。

> アプリケーションに利用しやすい形で変更が加わる @s-iwaki-d 現在の破壊的変更によって Unity 以外のアプリケーションでの利用が困難であるという現状が #12 や #34 で示されていると思うのですが、これは「 Unity アプリケーションにおいて利用しやすければよい」という意図で決められたコンセプトなのでしょうか。 JPEG の破壊的変更はあくまで圧縮であり、画像としての意図は伝わるだけの情報は残っている一方で、 VRM の正規化処理は明らかに元の情報が欠落しており、 圧縮と同等のように考える事はできないと思います。