VMDの補間曲線64バイトの読み方｜Z移動と回転のx1は1行目に無い

64バイトの並び

1つの曲線は3次ベジェの制御点2つ (x1, y1)・(x2, y2) で、値は0〜127です(127が1.0)。4項目ぶんで16個の値になり、1行目にはこう並びます。

2〜4行目は、1行目を1バイトずつ左へずらした写しです。実物で確かめると、写しが1行目と食い違う場所は1行目の [2]・[3] の写しにあたる5か所([17]・[18]・[32]・[33]・[48])だけで、ほかは全件一致していました。

1行目の [2]・[3] は全部0

実物30本・255,380件のキーで、1行目の 2と 3は1件残らず0でした。一方、2行目の写しにあたる [17] は143,385件、[18] は134,552件で、0以外の値を持っています。

どちらが本当の値かは、MMDが新しいキーに入れる「直線」を見ると分かります。実物でいちばん多かった64バイト(68,138件)は次のとおりです。

20, 20,  0,  0, 20, 20, 20, 20, 107,107,107,107,107,107,107,107
20, 20, 20, 20, 20, 20, 20,107, 107,107,107,107,107,107,107,  0
20, 20, 20, 20, 20, 20,107,107, 107,107,107,107,107,107,  0,  0
20, 20, 20, 20, 20,107,107,107, 107,107,107,107,107,  0,  0,  0

X移動とY移動は (20, 20)-(107, 107) で、対角線上の直線です。1行目の0を信じると、Z移動と回転だけ (0, 20)-(107, 107) という直線でない曲線になります。写しの20を読めば、4項目とも同じ直線になります。Z移動と回転の x1 は、写しの [17]・[18] から読むのが正しいと判断しました(MMDが1行目の2バイトを何に使っているかは、ここでは確かめていません)。

• 残りの写しも同じ値を持っています([32]=[17]、[33]=[48]=[18])
• 64バイトがすべて0のキーも37,189件ありました。制御点が (0, 0)-(0, 0) の曲線は直線になるので、読み方で結果は変わりません

three.jsのMMDLoaderは0の方を読む

three.js(r171)の MMDLoader は、項目 i の x1 を interpolation[i] から読みます。X移動・Y移動はそれで正しいのですが、Z移動と回転は常に x1 = 0 として補間されます。

どれくらい変わるかを、実物30本で見積もりました。同じボーンの隣り合うキーの組は250,950あり、1フレームしか離れていない組を除いて、回転の曲線が食い違う組が124,560ありました。補間の進み具合の差の最大値に、2つのキーの間の回転角を掛けた値で見ると次のとおりです。

MMDの既定の直線でも、x1 を0で読むと進み具合が最大0.070(区間の22%あたり)ずれます。作者が回転の緩急を付けたキーほど差が大きくなり、ダンスの止め・溜めの位置がずれて見えます。Z移動の位置のずれは、ほとんどが0で、最大3.56ユニットでした。

直し方

• 読むとき: Z移動と回転の x1 だけ [17]・[18] から読む。ほかの14個は1行目のままでよい
• three.jsに渡すとき: VMDのバイト列を写し、各キーの [2]・[3] へ [17]・[18] の値を入れてから MMDLoader に渡す。three.js のコードには手を入れずに済みます
• 書くとき: 上のMMDの64バイトをそのまま使う。1行目をずらして写すと、1行目の0が写しにも入り、MMDで読み直したときにZ移動と回転が直線でなくなります

カメラのキーの補間曲線(24バイト)はずらし書きをしていない別の並びなので、この話は当てはまりません(カメラVMDの中身)。

この記事に関係するツール

• VMDファイルの構造 — キーフレームのレコード全体
• VMDの切り出し・結合で壊れるところ — 補間曲線を生バイトのまま持ち回る理由
• PMX・PMD・VMDを調べる — 直線のままのキーの割合が出ます
• VMDの道具箱 — 切り出し・結合・反転(補間曲線はそのまま残ります)