iCyP

単ファイルでカプセル描画サンプルを作りましたので、良ければご査収ください。zipの中身は単一 .blendです。 右上テキストエディタのrun scriptで動きます。下側テキストエディタはそれぞれglslファイルの代わりです。 [dev_glsl.zip](https://github.com/saturday06/VRM_Addon_for_Blender/files/8246078/dev_glsl.zip) 

カスタム法線持ちのvrm export 出来るblendファイルを添付します。(blender3.0 [custom normal suzanne.zip](https://github.com/saturday06/VRM_Addon_for_Blender/files/8572343/custom.normal.suzanne.zip)

https://github.com/vrm-c/UniVRM/commit/3d2e1ce39537522881ac4e38785ca07bec3ea775 // google translate sorry. I think the above spec change is related to this issue.　Also, I haven't tracked this change. I couldn't reproduce it with a simple model....

**I think**, IO can export same file as possible from imported. So, I won't attach shade texture if shade texture is null when export 0.0. Otherwise, it may look different...

手動でTpose化すれば問題ない、自動Tpose化するとモデルが壊れるというuniVRMのTpose化issueになりませんか？ ローカル軸の保持は利用アプリ上での正規化を要するものとなり規格としての標準化の意味を薄めると思います。 また、アプリからのエクスポートであればアプリ側独自のTpose化実装もできるのではないでしょうか。 （Tpose化された）vrm由来モデルを再度vrmにする際にTpose化すると壊れるのでそのような場合はTpose化を実行しないようにという話もあります。手動（独自コード）でもTposeの仕様に沿っていればVRM出力時に絶対にuniVRMのTpose化を利用しなければならないというものではないと私は考えています。

仕様通り正しく厳密にTposeになっていると仮定すれば、各humanoidボーンのローカル軸は固定の値を用いることができます。 なぜなら、Tpose化によってローカル軸情報-回転をジョイント・頂点座標情報にBakeされていると言えるからです。(仕様に明記されていないこと・標準に実装されているTpose化機能が問題ではありますが…)　これにより、汎用的にモデルに動きをアタッチできます。 たぶん。（間違っていたらごめんなさい　 モデルにローカル軸情報を持たせることは、正規化(というより仕様準拠化)-Tpose化による上記利便性を失わせることになります。 [参考: slideshare - unite-tokyo-20193dvrm](https://www.slideshare.net/UnityTechnologiesJapan002/unite-tokyo-20193dvrm-176308996) の26枚目2項目目,33枚目

私は以下よりこの仕様は不要だと考えています。 1. 先にも述べたが、正確に正規化されたモデルはローカル軸を固有する必要はない。#54 により各ボーンのローカル軸をドキュメントに明示・利用するだけで良い。むしろローカル軸の独自所有は動きのアタッチをモデルに最適化する手間が発生する。 2. この仕様を読むか読まないかはクライアントが決定するということであれば、それはルックの一貫性を失う原因の一つになる。これはVRMのポータビリティという思想に反する。 3. 個人的にその時点で必要最低限な方が良い（追加は楽、変更・削除は困難なため)。 現問題はTpose化の改善で解決できると感じている。

（モーキャプに最適化された | 一般化されたモーションを持ったアプリに対する）3Dアバターフォーマット、から離れた使い方を使いやすくするべきという話は、VRM-Cの方々の判断すべきところであると私は考えますので、これ以上申し上げることはございません。 ただし、ボーンの向きとギズモが合わない言うのは、VRMとしてはTposeに反しているという問題です。これはuniVRMのTposeを通していればuniVRM、それ以外であればモデル固有の問題であり、ここで議論すべき問題ではないでしょう。Tpose化の問題であればuniVRMのリポジトリへissueを建てるべきです。 o0O(画像大きすぎて読みづらいです…高さﾀｸﾞ等で調節いただけると幸いです...e.g:) ``` ```

一点確認させていただきたいのですが、その２体に当てたポーズはそれぞれそれ専用に設定したモーションデータでしょうか？それとも同じデータでしょうか？ 　公開されているVroidのデフォルトTposeは人間が（普遍的な・見栄えよく）Tposeした時の姿勢をボーン初期姿勢として持っていると認識しています。同じポーズを適応しているのであれば、 - 仕様Tpose - 背骨が真っすぐ（自然な姿勢からは逆に曲がっていると言える？ - 足の骨がY軸（縦）に並行（解剖学的に言えば下に行くほど骨関節-回転軸は後ろに下がるはずでは？ という、人間として少し不自然な姿勢（モデリングできないので書籍頼みの知識です）)から、キャリブレーション時のようなTposeを取っているときの姿勢への差分をポーズモーションへ適応しないと差異が出るのは当然と思います。ここに、仕様Tposeはモーションデータを作るときに留意すべき初期姿勢状態であるというDocumentationが必要でないか、というissueが考えられます。 　ご回答頂けると幸いです。@m-sigepon

　理解としては、humanoidモーションの適用において、初期姿勢のキーを最初に打っても以降別のモーションを当てると初期姿勢のキーが残らないという問題ですね。　モーションを当てた場合ー**アバター以外の使い方をした時に発生する**(リターゲティングされたモーキャプデータであれば問題はないのではないかと思います、識者意見求む)、unity HumanoidとVRM1.0仕様のTposeとかみ合っていない問題と見えます。 　また、仕様に合わせてTposeにするとアバターの印象を与えたい姿勢と（ﾓｰｷｬﾌﾟにせよ手付ﾓｰｼｮﾝなどにせよ）アクターの姿勢との差異の吸収させるは解決が難しい問題だと思います。かつ別issueですね。どこにどう提起すべきなのか分からないですが…　バーチャルキャストはクライアント側でそれ実装しているように感じる ([tweet @virtual_cast](https://twitter.com/virtual_cast/status/1199920682689130496))ので、クライアントで解決すべきという思想なのかもしれませんが。どうなの？@vrm-c 氏～識者氏～ p.s.　脚がガクガクするのは汎用IKを真っすぐ繋がったボーンにリグセットアップ・ヒント無し（blenderでいうpole targetのような物）を適応すると、優先的回転軸を見失って、フレーム毎の計算結果に一貫性が失われることによるものでしょう。理屈からいえば脊椎、腕や指でも同じことが起こりえます。VRMクライアントに専用IKが組まれていれば or インポート時にIKセットアップされるよう設定すれば-（人型前提で、デフォルト姿勢が明らかで一意であれば曲がる方向は明確なので、自動セットアップは困難ではないはず、どのみち手間はありますが、ローカル軸はTpose依存固定仕様でもモデル固有仕様でもやることは同じでしょう（見る値が違うだけ））、解決できると思います。