Neko

対策として、インポートした後のVRMファイルを削除、もしくは拡張子を変更することで解決しました。 おさがわせいたしましたm(_ _)m →ある程度時間経過したら本チケットクローズしようかと思います。

返信ありがとうございましたm(_ _)m metaは一緒にコミットしているので問題ないかと思います。 Aポイントで新しいVRMデータを追加・meta含めてコミットし、BポイントでPull(更新)すると、必ずデータを作りなおしてしまう様子です。拡張子VRMはインポートすると不要になると思いますので回避は可能ですが、できれば更新されないほうが良いと感じています。よろしくお願い申し上げますm(_ _)m 

ご確認をありがとうございましたm(_ _)m 最新バージョンでは回避できているのですね。どこかのタイミングでアップデートしたいと思います。 （UnityEditor 2020以上にアップいるとフレームがかなり落ちるので待っている状況です） 現在は、VRMファイルが起動して上書きしないよう、"vrm"ファイルの拡張子を　"_vrm"に書き換えて運営しています。 今のところ本対策で問題は出ていません。 今後ともよろしくお願い申し上げますm(_ _)m

バージョン追記しましたm(_ _)m

https://github.com/vrm-c/UniVRM/issues/1971 …のバージョン表記もそうでしたが、勘違いが起きるような報告にて申し訳ござませんでしたm(_ _)m 当方が、UniGLTF と　UniVRM　の違いを正確に認識していませんでした。 確認した内容は下記の通りです。 UniGLTF 2.43.2 / UniVRM　0.107.2 ←旧バージョン Unity version: Unity-2019.4.35f1 ★念のための補足★ 0.107.2では、vrmファイルを展開した後、vrmファイルを捨ててよかったので「結果として問題ありませんでした」。 以前の課題として、 GitやSubversionで他の場所でPULLすると、PULLした場所で毎回新規にVRMを展開しなおす為、どこかでPULLをするたびに、vrmファイルが作り直され、コミットデータが莫大・Unity起動時間も倍になるという状況が発生していました。 対策として「一度vrmを展開してそのデータだけをコミットすれば、オリジナルvrmファイルは削除(または拡張子を書き換える)」を行って、Unity起動時にvrmファイルを認識させないようにしました。 0.107.2 は、vrmファイルは本体ではなかったので、データだけコミットして対策できていました。 ↓以前報告した内容ですm(_ _)m https://github.com/vrm-c/UniVRM/issues/1784 UniVRM 2.43.2 /...

ご回答をありがとうございましたm(_ _)m 現状、やはり処理速度・開発の利便性が重要であるので、当面は旧VRM 0.x にて進めようかと思います。 基本はアバター向けの企画のようですが、ゲーム関係にも意識してもらえるとすごく助かりますm(_ _)m

回答ありがとうございましたm(_ _)m ボーンコライダー系の警告は無視いたします。 現状、Ｖｒｏｄデータから変換してそのまま持ってきているので、１個のＦＢＸ内でのボーン名は重複はないと考えておりますのが、もし見つけたら重複原因を確認するよう致します。