2025年2月23日日曜日

モデルさんをモミモミしてみる(ボーンの順序を整える)

 実際のモデルさんで解説したかったんだけど条件が合いそうなモデルさんが見つかりませんでした

仕方がありませんので、例を挙げる形でボーン整理のお話を進めていこうかと思います

ここから先は私の好みの部分もありますので、違う並びが好きというのは有りです

要は「ユーザー(自分)が後で困らないように、よりシンプルに整理、並び替え」が出来てればよいのです


計算順序を考慮して並び替えてあげることで、スタンダードなスケルトンは全て階層0にすることが出来ます

そうすることで、PMXEプラグインでのボーン追加や、オリジナルの構造を組み込むときの見通しが良くなります

ちょっとしたボーン改造する場合でも意識されると良い事あるかもしれません


階層指定設定のあるモデルさんが失敗しているという訳ではありません、正解ですけどちょっと無駄があるというだけです

何故配布モデルに階層付けをされているモデルがあるかの理由は


”出力アプリの配慮”

”MMDのバージョンアップに伴う追加ボーンの不具合修正”

の為に起こった仕方のない事だったと思います



実際の並び替えの作業

基礎の大本のボーンに”センター”が一番最初になるでしょう

順標準ボーンでセンターの上位に「全ての親」とかの便利ボーンを置く場合ももありますが、スタンダードなスケルトンなら「センター」から始まります

私の場合は


センター

上半身

両目

右目(両目ボーンから付与を受ける)

左目(両目ボーンから付与を受ける)

下半身


と体幹と両目を並べます

今でも散見されるの例ですが


頭(階層指定無)

右目(階層2、両目ボーンから付与を受ける)

左目(階層2、両目ボーンから付与を受ける)

(いくつか飛んで)

両目(階層指定無)


のような並びと階層指定になっているパターンがあります

階層指定を特にしていない場合は階層指定は”0”になっています


意図的に階層指定して動くようにしてしまう場合もあるかもしれませんが

モデル制作時にデーター出力時に絶対動くようにアプリがそういう風に指定してしまう事があるからみたいです


ボーン処理順序としては

頭→右目を読んで見たけど階層2だから飛ばして→左目を読んで見たけど階層2だから飛ばして→…→両目をこれだけ動かして

階層0の処理が終わったから次の階層の処理に進んで

階層2の処理に進んだ

右目に両目のボーンの角度を付与させる

左目に両目のボーンの角度を付与させる


という処理になります

どの位置に両目ボーンがあってもちゃんと動く動く、けどちょっと回りくどい

そんな設定になっちゃってますよね

ボーンの順序が両目が下位になっている事で、視線回りの追加ボーンをプラグインで追加出来なかったりする事例もあったり

基準のボーンが視線になっていて、その先にある両目ボーンとの間に割り込む格好で追加しようとして失敗してたりしました


なので

両目

右目

左目

のような並びにして、階層指定の必要が無いシンプルな順番にしてあげましょう


あと、体幹関係でチェックした方が良いのがX座標の数値です

中央に走るのが基本なのでX座標は0なのですが「-6.960701E-11」みたいな指数表示になっている事がありませんか?

これボーン座標が自動設定される時ほとんど0だけど微妙にずれている時に自動で入力される数字になります

実際の数字は「0.0000000000696070」のようなほぼ0ですから、こういうの数値を見つけたら「0」と修正してあげましょう

他の自動入力の場合もこういう数値が入ることがあります

本当に小さな事ですが処理軽減になりますので気が付いたら修正してあげると良いでしょう



体幹の次に

左右の肩~指(指先&ダミーボーン)

を並べます

このあたりで差異が出ることは殆どありませんね

ちょっと特殊な捻りや肩回り、鎖骨なんがを実装しているモデルさんもありますので、そのへんもこのあたりに纏めておきます

握りや拡散ボーンを追加している場合、私は体幹と左右肩の間に置くことが多いかな?


そして足周りを並べます


足   (linkなので黄色)

ひざ  (linkなので黄色)

足首  (ターゲットなのでピンクになりそうだけど、つま先IKのLinkの黄色が優先になってる)

つま先 (ターゲットでピンク)

足IK (をLinkに「足、ひざ」、Targetに「足首」、PMXモデルの場合は0.1~-180°くらいで「ひざ」に角度制限がかかる)

つま先IK(足IKの流れの末端、Linkに「足首」、Targetに「つま先」)


IKは、この「Link黄色TargetピンクIK赤」の順に並べるのが基本になると思います

最近のPMXモデルの足IK周りはちゃんとこんな感じになっているモデルがほとんどですね

足IK親なんてボーンもありますが、そういう感じのボーンはIKのリンクの中には置くと混乱する原因になりかねませんので、私はIK並びの上位に置くようにしています

MMDモデルは現在PMXモデルが主流になっていると思いますが、PMXモデル黎明期のPMDモデルのスケルトンを参考にしたモデルに散見されたパターンがあります


足IK(階層指定2

つま先IK(階層指定2

ひざ

つま先


このパターンです

これも、先に挙げた「両目、左右目」と同じような感じで順番を階層指定して遅らせているのでちゃんと動きます

が、スマートで無いのもあるのですが付与で足、ひざ、足首の回転を取り出すときにちょっと面倒な事がおきます

足、ひざ、足首の階層は指定されていませんから、付与を受けるボーンは普通にそれらのボーンの下位に置けば良いのですが、IKの処理は階層2なのでおかしなことになります

バージョンによっては動かなかったり、MMDエンジン化したりしますし、何かしらの追加ボーンを仕込む時に混乱しかねません


足Dのとかを追加する場合

足Dはデフォルトで階層1のようですから、IKの階層が1ならそのままで行けると思いますが、IKが階層指定2だとNGになります

というわけで足D等を追加したりする可能性も含め、先に説明した、足、ひさ、足首、つま先。足IK、つま先IK(全て階層指定無し)の順に並べるのがお勧めです


※追記として

古いモデルに”つま先”を親にして、付与率0の付与ボーンの形でつま先EXを追加しているモデルがありました

これ、MMDのバージョンアップで追随しなくなったので、そうそう見ないと思います

もし見かけたら足Dの流れを追加してつま先EXを処理してあげましょう

その時に上手く動かない場合は階層指定やボーン順序をチェックすると良いです


膝枕ボーンやORZ79D等では追加構造を物理演算後にしないと目に見えるくらいのズレがおきていました

通常の変形処理が終わった後に足IKに大き目の補正がかかっていたのが原因だろうと思います

比較的新しいバージョンのMMDで足Dと足IKの差異を確認してみましたがほぼ合致していましたので修正がかかったのかな?とも思います

足IKから付与等で回転を取り出した時に気になるズレが起こったなら”物理演算後”に指定するといいかも?

という感じで頭の片隅に置いておくといいかもしれません


足IK周りの次に物理演算ボーンたちを置きます


IKと物理の両方の設定がされるボーンの流れ

ネクタイIK、髪IKとかがそれです

MMDで物理演算がONであれば物理演算が優先されますので、静止画制作時にIKを設定してあげるのも良いと思います


物理演算のみのボーンの流れ

特殊な設定でもなければ、普通に揺れ物全般ですね


その後に表示されるその他のボーン

非表示ボーン(~~先等のボーン)

と置いていきます

非表示の~~先ボーンについては、解りやすさ優先で親ボーンの近くに置いておいても良いと思います

このあたりは好みですよね


こんな感じでボーンの順番を整理していくと

基本のスケルトンは階層指定をしなくても良いシンプルな状態に出来ます

その後の順標準ボーン等の追加もしやすく、追加されたボーンも理解しやすく配置出来ると思います


そんなこんなで今回の作業でボーン改造の下地が整いました(という事で進めていきましょう)

2025年2月16日日曜日

ボーンの計算順序(私的考察含む)

 前回継続回転に付与を使うといい塩梅なんですよ?と紹介していました

この付与というのは、便利構造に結構頻繁に使われます

代表例とかだとPMXEプラグインで入れられる”足D”や”肩キャンセル”とかです

こういうのをプラグインで入れるのも手間いらずなので使っちゃえば良いのです

が、このブログは「UNLIMITED BONE WORKS」と謳っている訳ですから、手作業で追加出来るようになれるといいなぁ?な流れで話を進めて行こうと思います


では、ボーン改造する準備として最初に何をするか?なのですが、私はボーン改造や追加を行う初手にモデルさんのボーンをマッサージします


PMXEのプラグインで便利ボーンを追加しようとして失敗した経験がありませんか?

これは、モデルさん毎でボーンの順番や階層、細かなボーン名称、末端の処理の仕方、追加されている準標準ボーン、便利な独自構造等などなど結構な差異があったりします

この差異がボーン追加の条件に合わない場合にあえて追加しない(出来ない)という処理になっちゃうからなのです


基本的なスケルトンであればボーンの並び順を適切に並べ替え変形階層を全て0にしてあげられます

ちゃんとボーン順序や階層を整理することで正常にプラグインで追加が出来る事が多いのです


モデル毎の差異を全体的にザックリ把握しつつ

ちゃんと動くから”間違いではない”のだけど”ビミョーに無駄”だったり

IKのボーン並び順をそういう感じにちゃうと後で自分が困るかな?

という感じの所を整理していきます

一見無駄に感じると思いますが、モデラーさんの創意工夫が感じられる作業でもあります


ほうほう、こういう事してるのねー?

とか

このボーン並びでどうやって変形させてるんだろ?(ウエイト覗いてみて)うわぁぁぁぁぁぁぁ

とか

これは思いつかなかったなぁ?今度どっかで使ってみよう

とか

モデル作成時に協力させていただいた構造とか使われていたり、紹介されていてホッコリしたり

そんな感じでわりと楽しいお時間です


変形処理の順番(個人的考察を含む)

実際にマッサージってどういうことをするのかなのですが、要はボーンの処理順序の整理適正化です

そのためには、”ボーン番号”と”階層指定”、”物理後演算”の意味と処理のルールを把握しておく必要があります

前にもお話した事と重なりますが、少し詳しく説明していきます


ボーンの変形処理の流れは1フレームの間に下のような感じで進んでいきます


1 ボーン番号

基本的にはボーン番号の小さい順(リストの上)から大きい順(リストの下)に変形処理をしていきます

IKの処理と付与ははちょっと特殊な順番になっていると思われます

私的推察として

同一階層のボーンの処理が終わるまでIKのボーンは一旦FKとして仮処理している

    仮処理ではFKは変形していないのでIKの付与は動かない

    FKの親ボーンにする場合親子関係が内部処理的に逆転する

付与親や親ボーンとして扱う場合はIKの処理を待つために階層指定を遅らせる必要がある


付与を指定した場合は付与親の計算結果を読みに行く割り込み処理が行われるようで親子関係の計算結果に影響を与える

MMDエンジン化したIKを正常化する手段に、付与ボーンで2重化したボーンを親ボーンに切り替える手法があります

割り込みがかかる事で親ボーンの内部的逆転が正常化するのではないだろうか? 

という感じです

一見IKのボーン順序や付与の順序に不正は無いのに正しく動かないという事があるのはこのあたりが関係しているのだろうな?という感じで、これまでの作業経験と結果から推察しています


2 階層指定

変形順序のレイヤーのような感じですね

IKの処理タイミングも重ねて考えると

階層0のボーン順序で処理→階層0のIKの変形処理→階層1のボーン順序で処理→階層1のIKの変形処理→階層2の…という感じになります

普通のモデルさんにはほとんど階層指定は必要無いですが、ちょっと濃いめの構造とかには頻繁に出てきます

IKからの付与を受けてうんちゃらーとか、そういうのをちゃんと動かそうとするとガッツリ大盛になります


3 足IKの処理

多分ここのタイミングで処理しているのだろうなぁ?という推測です

PMDモデルはモデル側で足IKのひざの角度制限が出来ません(必要ありません)

MMD内部で特別な処理をしてグンニャリしないようにしているのですが、その処理をするタイミングが多分ココだろうと推測仮定して作業しています

PMXモデルで足IKに細工をすると微妙に崩れる事があるのですが、多少この処理の影響が出てるのかな?と思っています

また足IK周りに何かを普通に追加しようとするとスッポ抜ける事例もこのあたりが悪さしているのかな?と思っています


4 物理演算

1、2、3の処理を終えてIK、FKの変形がはぼ決まってから物理演算が動く感じ

IKと物理演算が同じボーンに働いている場合は物理演算が優先されます

MMDで物理演算をOFFにするとIKが有効になります

髪IKと物理演算は共存可なので、静止画出力時用に髪IKやネクタイIKを追加してても良いのではないかな?と思うのでした


5 物理演算後

物理演算後のチェックを入れると物理演算を終えてからもう一回ボーン順(IK)、階層指定順で変形処理が走ります

物理演算の揺れものから何かをしようとすると必須ですね

上手に利用出来れば、物理演算とIKの結果を合成出来たりもします

【第18回MMD杯本選】「天月りよん」さんに舞っていただいたで配布させていただいているりよんさんのケープとか髪に使っています

足IKがらみの仕掛けで変形が崩れる場合は、物理演算後に処理をすると良いんじゃないかな?と思います

足Dも物理演算後の付与にすると変形結果のズレが最小になるんじゃないかな?

物理演算の突き抜けが小さくなる可能性もあるので一回試してみてはいかがでしょうか?


足IKの内部処理のタイミングがあのあたりだろうなと推察したのは思い出深いエピソードがありまして

初音ミク@七葉1052式(仮)G型にひざ枕ボーンを組み込んでいる時に動画を出力するとどうしても膝の変形が崩れてしまっていました

ほとんど諦めかけていた時に、試しに物理後処理のチェックを入れたら劇的に改善して採用できたという事がありました

その後自分のORZシリーズ等への足IK回りの処理には物理後処理を採用しています


1~5の順序でボーンを処理して次のフレームの処理へ進む流れになります

モデルのマッサージというのは、こういう流れで処理されると意識してボーンの順番を並べ替えて整理していく作業になります

メッチャ地味です

が見通しが良くなりますし、大雑把でもモデル事の基礎を把握しておくと後が楽になります

基本は大事なのです

少し長くなりましたので実際の作業はまた次の機会にしうようかと思います


折角ブログ用にステージ作ったりしているので、そろそろそれなりにちゃんとした動画を仕上げたい所

少し更新がノンビリになっていくかもしれないのだけれど

更新が止まらないように応援してやって欲しいおっさんでした


2025年2月14日金曜日

MMDエンジンの代替え構造のお話

 継続回転として有名なのがMMDエンジンですね


先のお話でもしましたが、MMDエンジン自身はメッチャ迷惑なバグです

複数の種類があるのですが、回帰的付与や親子関係が設定されると処理残りの角回転し続けるというのが大まかな理屈です

このバグのおかげで回帰的設定を含む(結果含んでしまう)構造を作ろうとするとメチャクチャリスキーな事になったり謎呪文を唱えたり、最悪あきらめたりすることになります

ですから、私個人としては好ましく思っておりません・・・がgagg、後で説明する仕掛けとの比較も必要でしょうし、軽く触れておきます


一番シンプルな1ボーン型

自身に付与します

付与親が赤字になっているのは”設定がおかしいよ”という警告です

MMDエンジンは故意にそういう感じの設定をします

付与率は適当でOKです

適当に回ります


自身で付与+IK

回転軸をIKで固定してるので少しは扱いやすいのかな?

IKのループ数とかは適当でOKです


やっぱり適当に回ります

元々がIKの設定ミスで起こる暴走を体系化したものなので他にもいくつかあの種類がありますが、使用目的を考えればこの辺を知っておけば困ることは無いと思います

利点としては”適当な操作で適当に回転し続ける”事ですね


■回転速度はPC環境に左右されるので安定しません

■動画出力中にも処理負荷次第で回転速度が変わりえます

■出力FPSの設定で回転速度の結果が変わります

「安定した角回転するものでは無いよ」なのです


回しっぱなしで出力するのなら、回転開始時の角度もランダムになりますからフレーム毎の絵は出力ファイルで違う事になります

編集で繋ぐ時とかに制限が出来るんじゃないかな?

操作時と動画出力時の回転速度が違ってしまいますから、プレビューでは無く出力結果を見て速度調整する必要があります

突っ込んでいるモデルやエフェクトの処理も負荷に関わってきますからシーンによっても変動しえます

結局のところそれなりに調整が面倒なんですよね

私みたいにボーンを弄って遊んでる人には邪魔ものでしかないし


「適当に回る」以外に良いところあるのかな?

というのが正直なところです

お手軽なのは解るのですが、前にもお話ししたデメリットが大きすぎます


では、MMDエンジンよりもシンプルな構造で、安定していて使い勝手が良い構造があるのか?というお話になるのですが

ちゃーんと存在するのです


ここからが本題

MMDエンジンは使わない継続回転の仕掛け

MMDで物を回転させるのには60度毎回転させるキーをバカバカ打ち込む必要がある

と思い込んでる人が多いのでMMDエンジンが重宝されるのだと思います

シンプルで使い勝手の良い継続回転の構造は昔からあるのです

配布しているサンプルなのですが、ザックリこんな感じ
説明用PDFも誤字ありますけど添付してます

回転角を指定されるボーンがコレ




その回転角を付与で受けて増幅する(この場合は179倍)

回転親が180度回ると89.5回転します

回転軸をお手軽に変えたいならセンターを双方の親に設定すると便利

このボーンに外部親でモデルをくっつけると継続回転出来るわけですね



とてもシンプル

組み込み簡単

エラーを含まない安定した構成


素晴らしい


開始フレームに初期角度(楽曲頭、デフォルトなら省略可)にキーを一個

回転終わり(楽曲終わりまで回すなら最終フレーム)にキーを一個

途中で回転の変化をつけるなら補完曲線をイジイジ


最小1キー打つだけで良いわけです

このサンプル動画だとステージの最終フレームに一個ポチっとキーを入れています



こんな感じですね

今回は倍率50倍だったので

楽曲の終わりに180度回すキーがモーフのキーを一個入れれば、(180度×50倍)で25回転します

キーは回転終わりのフレームに1個だけです



2分ちょいの楽曲なら毎分4~5回転する計算になります(結構高速に回りますよ)

もっと早くしたいならモーフ化していれば2とか3とかを直接入力しても良いですし、付与の倍率を上げてもいいですね

1楽曲数分間継続回転させるには十分だと思いませんか?

ボーン操作なら補完曲線も使えますし、倍率にもよりますがかなりな高速回転も出来ます(こんな感じ)

これは、donburiroomさんが紹介されているオートグループボーン揺らぎボーン等の継続回転部分になります

この部分の仕掛けは単純で当たり前すぎてわざわざ紹介されなかったのもあるのでしょうね

2011 年発売の「P さんのための MikuMikuDance モーション作成教室」にも欄外扱いでしたが軽く紹介されていました

結構古くからあるものなんですよ


MMDエンジンに慣れすぎてしまって回転開始フレームでボーンを回せば勝手に回転すると思い込んでいませんか?

その操作で回転するのは本来イレギュラーなんですよ?

ボーンを弄ってるのに回転しない、設定をミスってるか、キーを滅多打ちしないと回転しないやつだと勘違いしてませんか?

開始フレームと終了フレームにキーを打って補完曲線弄ってね?って経典でも説明されてますよね

終了フレームで大本のボーンに回転終了角度のキーを打ってあげる

プレビューや動画出力時には、それを数倍~数百倍した角度でボーンが回る

それに乗っかっているモデルやアクセやドームが回る

そういう事です


結構この構造私の配布してるステージとかに採用してるんで触って確認してみてください


ボーンの回転角を指定するのですから、VMDデータとセッティング済のボーンセットと同梱して配布何てことも可能です

これはMMDエンジンではとても難しいんじゃないでしょうか?

実際に見てもらうために動画を作ってVMDデータを含め配布しています

MMDテトリス 誰か文字付けテッテッテテトリス

カメラボーンをグルグル回してあげてモデルさんが回っているように見せています

確認してもらえばキーがめっちゃ少ないのが解ると思います

一応汎用性も考えてIKでの注視モードと手動モードをカメラの接続先を変える事で切り替えられます

背景接続位置にステージ等を外部親接続すると、接続されたカメラからは停止して見えるようになります

継続1は100倍、継続2は10倍、回転補助1~3と全てつながっているので、凄く細かい制御が可能になっています

動画中のちょっとした演出に使うと面白いんじゃないかなぁ?

という所



いくつかサンプルを紹介させていただきましたが、楽曲終わりにキーを1個打つのを大きな手間とは言わないでしょう?

開始、終了時の回転角を指定する訳ですから、フレーム毎の絵面はプレビュー時でも出力結果もで同一になります

ステージを切り替えても倍率と回転角さえ記録しておけば同じ条件で回転する

止める角度も決定出来る

構造もシンプルで組み込みやすく安心して使えます

適当に回るだけの不安定なMMDエンジンと比べると絵作りにもメリットがとても多いのです


結論として

MMDエンジンは無くなってもどうにでもなるのです

この仕掛けがもっともっと広まってMMDエンジン不必要勢が増えてくれるといいなぁ?と思うおっさんなのでした


2025年2月1日土曜日

ボーンで何が出来るのか(とりあえずの基礎編とりまとめ)

 多少変化球もありますが、ザックリとMMDモデルのボーンの基礎なんかを書き進めてみました

これから実際にモデルのスケルトンや、便利構造とかもうちょっと突っ込んだお話に進んでいく事になると思います

以前にニコニコのユーザーブログに書いた事と重複するかもしれませんが、そこはご勘弁ください

MMD関連ブログの魚拓の保護を進めておられる方もお見えになりますので、そちらも有効活用されると宜しいと思います

さて前置きはここまでで、本題に入っていこうと思います


MMDモデルのスケルトンを見たことが無いという人はここを訪れていないと思います

ボーン複数繋げて人型に模式化してスケルトンというのは、とても解りやすいネーミングです

只、このスケルトンを見慣れているが故に気が付きにくい事があります

MMDやMMMのボーンやボーンモーフを使うと、とても自由度の高いアナログコンピューターとして作動するという事です

何を言い出しているのかと思うかもしれません


入出力はボーンの回転角や移動量になりますが、これは意訳された数値、数量、フラグと置き換えて考える事が出来ます

 足し算、引き算、掛け算、割り算、ベクトル演算、行列式計算、理論式(AND、OR、NOT、NOR等)

MMDの処理能力が許す限りの範囲でこれらの演算することがが可能です


マイナスを足せば差の計算になりますので、和差の模式化ですね

構造という程の事はありませんが、計算尺や歯車式の計算機はこんな感じですよね



(X0、Y0、Z0)+N(X1、Y1、Z1)の模式化です

掛け算割り算を含むベクトル算なわけです
N<0なら割り算、N>0なら掛け算ですね

IKを使って少し複雑化になってます



理論式のANDとORです

IKの特性を使って閾値として扱っています

NOTは、ここから180度回転させれば否定扱いになるので省略しています

突き詰めればで数ビットの2進数和くらいは組めそうですが、かなり複雑化しそうですね




上のモデルを触ってみたい人はココからどうぞ


自分で0から構築していくと手間はしっかりかかります

それでも自由な思考発想でMMDモデルや便利構造にチャレンジしてもらえば嬉しいです



■これから出てくるだろう呪文みたいな謎ボーンについて

これから先、スケルトンや便利構造、ちょっとしたテクニックについてお話していく事になると思います

が、謎の呪文っぽい不思議構造が出てきたりすることがあると思います

ぶっちゃけたお話をすると、MMDエンジンっていう邪悪な存在が邪魔しなければ発想と手間で大抵の事は実装可能なのです

(ボーン弄りして遊んでる人はMMDエンジンへのヘイトは理解してもらえると思います)

IKや付与処理は内部的なボーン計算順序に入れ替わりが発生しやすいのです、これが回帰的構造になってしまってエンジン化する事が比較的頻繁に発生します

MMDやMMM自体は本来回帰的構造や付与も許容しています

MMDエンジンが目的の構造を邪魔したり、複雑怪奇な謎呪文構造の原因になっているのです

今後、便利機構を紹介していく事があると思うのですが、妙に意味不明な追加ボーンがあるなぁ?という場合ほぼIKの処理とMMDエンジン絡みの処理の為です

これが、ボーン改造や仕掛けの開発や理解を進める時の大きな壁になっています

MMDエンジンが邪魔しなければかなり簡素で理解しやすい便利構造が一般化されて、その結果を多くのユーザーが享受出来ていただろうと思います

私個人でもいくつも没にした構造がいくつもあります


MMMはMMDエンジンは動きませんが、インパルスモーフがあります

MMDの物理エンジンがバージョンアップされていたならMMDにもインパルスモーフが実装されていた可能性があったと思っています(PMX2.1以上のバージョンに対応したMMDの登場がありえたかも?)

過去の書籍にも紹介されているMMDエンジンよりも簡便で使い勝手が良い継続回転構造もあります(これは次に紹介、解説します)

この回転にはMMDエンジンは使っていません
キーは1個です
MMDエンジンにはこういう事をしようとすると相当面倒な事になるでしょうね


MMDエンジンに代わる何かなんてどうにでもなるのです


過去にMMDエンジンが消えるかもしれない事がありました

その時には”MMDエンジンが無いと困る”という声が大きすぎて”MMDエンジンは邪魔だし次を考えよう”って声は響きませんでした

もしも、もしも今後そのような機会があるのであれば、MMDエンジンを消す方向に声をあげていただきたいと思う次第です