レス数が1スレッドの最大レス数(1000件)を超えています。残念ながら投稿することができません。
MMDのモデルデータについて語るスレ
-
■MMDのモデルデータであるmiku.xxおよびrin.xxの内部構造等について語るスレです。
モデルデータ改造関係の話題はここで
■関連２ちゃんねるスレ
MikuMikuDance動画制作/鑑賞スレ part 13
http://pc11.2ch.net/test/read.cgi/streaming/1219114396/
■過去ログ
http://www6.atwiki.jp/vpvpwiki/pages/25.html
■このスレでの注意事項（暫定）
・人をdisらない
・批判おｋだが代替案を示すなどを推奨
・荒らしはスルー
■次スレは>>950が建てる事
次スレに必要な議論はそれまでに済ませておくべし
>>950が音沙汰無い場合は>>970一任
-
rin.xx のデータ (MmdMaterial で見られるもの以外全部) の
ダンプを Excel の表に整形したものをうｐしました．
http://www10.uploader.jp/dl/mikumikudance/mikumikudance_uljp00212.lzh.html (5.45MB)
-
なんだかよくわからんけど凄そう。
乙です
-
xxファイルからpmdファイルに形式が変わったみたいですね。
うーん、今までのは水の泡なのだろうか。
-
miku.pmd のマテリアル設定の箇所
0 0x069DED
1 0x069E37
2 0x069E79
3 0x069EBF
4 0x069F05
5 0x069F4B
6 0x069F91
7 0x069FD7
8 0x06A01D
9 0x06A067
10 0x06A0B7
11 0x06A0EF
12 0x06A135
13 0x06A17F
14 0x06A1C1
15 0x06A207
16 0x06A24D
これでたぶんあってるかな？
-
エッジのアドレスをさわって消せるのは pmd も xx ファイル同様ですし、
今回は別名保存しておけばオリジナルと別なものとして読み込みできるので便利ですね。
データなく00で埋まってたようなところが詰まったような感じに
アドレスが変化したように見受けられるのですけど実際どんな感じなんでしょうね？
--
eye*.bmp を変えて別フォルダにpmdごと保存して、読みわけしても
先に読み込んだモデルのテクスチャで後から読み込んだモデルのテクスチャが表示されるのは仕様だと思うので、
目のテクスチャも変えて表示したい場合は該当アドレスの eye*.bmp を別名に変えておけば同キャラ別瞳が可能になります。
# miku.pmd の場合は 0x069F7D から始まる箇所を eye2.bmp から eye5.bmp等に変えればOK
-
xx ファイルの頂点データのあとに osm ファイルにかかれていたMeshが入ってるようですね。
たぶん、解析ができるかただと速攻で気が付かれてる話だとは思いますが。
Mesh
Bone No.1,Bone No.2,weight
1番目の頂点だと頂点の座標の後に 03 00 00 00 64 00 って感じでデータが入ってるのですね。
---
いま、見てる人の多そうなタイミングなんで興味をもってもらうために
些細なことでも書いていこうかなぁ……
# ど素人の適当な話が先に上がると
# じっくり解析されている方のモチベーションを下げてしまうかな？
-
0x00053E67 からがエッジのデータかな？
BF AF 00 00 で エッジ数から開始っぽい
元の xx ファイルのアドレスに頭に製作者情報が119（16進数）加わったのと
メッシュの情報が
Bone No.1で 2、Bone No.2 で 2、 weight で 2 ずつアドレスが増加するから計6個増加
頂点数は変更なしの9036だから 9036 x 6 = 54216（10進数）
これを16進数に直して D3C8（16進数） なので
両方足して D4E1（16進数）
ナクアダさんのご提供くださったデータの実エッジの開始アドレスが 0x00046988
足したら 0x00053E69
ありゃ？微妙にずれてる orz
-
BF AF までが エッジ数で 次の 00 00 が 材質番号かぁ。
データは頂点番号が順に並んでいるだけで
エクセルで表示くださっていたのは各頂点に対応するように各座標をいれてくださっていたのですね。
0x00055677 からが 素材1かなぁ
データの並びは微妙に異なる気がしますが、
0x00053E67 - 0x00055676 までを00埋めしたら素材0 に当たる部分が消えましたし。
-
MMD 3.0x のモデルファイル (*.pmd) を解析してわかったこと．
まだ少し不明な部分があるけど，とりあえずこれで MMD3 用の
MmdMaterial と MmdErase は作れるので残りは後回し．
*.pmd ファイルは次の内容からなる．
(1) MMD2 の *.xx の内容 (ポリゴン，材質)．
(2) MMD2 の *.osm の内容 (ボーン，IK，スキン (表情))．
(3) フレーム登録窓の，モデルに依存する項目 (ツリー構造，表情の種類)．
以下，"初音ミク.pmd" を具体例として解析した結果．
-
●"初音ミク.pmd" の内容
0x00000000 〜 0x0000011A (283 (0x11B) バイト)
・ヘッダ
// マジック文字列 (ファイル種別識別用)．0x00 終端．余白は 0x00 で埋める．
char magic[5] = "Pmd";
BYTE 0x80, 0x3F; // 不明 (モデルによらず固定値)
char name[20] = "初音ミク"; // モデル名．0x00 終端，余白は 0xFD で埋める．
char comment[256]; // コメント (著作権表示など)，0x00 終端，余白は 0xFD で埋める．
0x0000011B 〜 0x00053E66 (343372 (0x53D4C) バイト ＝ 4 + 38 * 9036)
・頂点データ
DWORD nVertices = 0x0000234C = 9036; // 頂点数 (４バイト)
MMD3_Vertex_t vertex[nVertices]; // 頂点データの配列 (38バイト × nVertices 個)
0x00053E67 〜 0x00069DE8 (89986 (0x15F82) バイト ＝ 4 + 2 * 44991)
・ポリゴンデータ (頂点番号の配列)
DWORD nIndices = 0x0000AFBF = 44991; // 頂点番号数 (４バイト)
WORD vertexIndex[nIndices]; // 頂点番号の配列 (２バイト × nIndices 個)
※MMD2 ではエッジ (頂点番号対) の配列だったが，
MMD3 では単一の頂点番号の配列となり，データ量が半減している．
0x00069DE9 〜 0x0006A292 (1194 (0x4AA) バイト ＝ 4 + 70 * 17)
・材質データ
DWORD nMaterials = 0x00000011 = 17; // 材質数 (４バイト)
MMD3_Material_t material[nMaterials]; // 材質データの配列 (70バイト × nMaterials 個)
0x0006A293 〜 0x0006B52A (4760 (0x1298) バイト ＝ 2 + 39 * 122)
WORD nBones = 0x007A = 122; // ボーン数
MMD3_Bone_t bone[nBones]; // ボーンデータの配列 (39バイト × nBones 個)
0x0006B52B 〜 0x0006B59F (117 (0x75) バイト)
・IK
WORD nIKs = 0x0007 = 7; // IK データ数
MMD3_IK_t ik[nIKs]; // IK データの列 (可変長 × nIKs 個)
0x0006B5A0 〜 0x00070EF1 (22866 (0x5952) バイト)
・スキン
WORD nSkins = 0x0010 = 16; // スキン数
MMD3_Skin_t skin[nSkins]; // スキンデータの列 (可変長 × nSkins 個)
0x00070EF2 〜 0x0007106F (382 (0x17E) バイト)
・フレーム登録窓表示用データ
// expression[i] は「表情」のｉ番目の子となるスキン番号
// expression[0]＝9 ⇒ bone[9]＝"あ"
// expression[1]＝10 ⇒ bone[10]＝"い"
// :
// expression[14]＝15 ⇒ bone[15]＝"下"
BYTE nExpressions = 0x0F = 15; // 表情の個数
WORD expression[nExpressions]; // 表情として使用するスキン番号
// フレーム登録窓のツリーの中間節点名文字列
BYTE nStrings = 0x07 = 7; // 文字列数
char string[nStrings][50]; // 文字列 (50バイト固定長) の配列．0x00 終端，余白は 0xFD．
0x00071070 〜 0x00071166 (247 (0xF7) バイト)
・未調査 (おそらくフレーム登録窓のツリー構造とボーン番号の対応データ)
●頂点データ (MMD3_Veretx_t，38バイト)
typedef struct {
// 次の部分は MMD2 と同じ．Direct3D の D3DVERTEX 型．
float x, y, z; // 座標
float nx, ny, nz; // 単位法線ベクトル
float u, v; // テクスチャ座標
// 次の部分は MMD3 で追加された，ジオメトリ・ブレンディング用データ．
// (MMD2 では *.osm 内にあった．)
WORD bone[2]; // ボーン番号
WORD weight; // ブレンドの重み (0 〜 100％)
} MMD3_Vertex_t;
●材質データ (MMD3_Material_t，70バイト)
typedef struct {
struct { float r, g, b, a; } diffuse;
float shininess;
struct { float r, g, b; } specular, ambient;
WORD 不明; // MMD3 で追加されたデータ
DWORD nEdges; // この材質に対応するエッジ数
char textureFileName[20]; // テクスチャファイル名 (MMD2 では 256 バイト)
} MMD3_Material_t;
●ボーンデータ (MMD3_Bone_t，39バイト)
typedef struct {
char name[20]; // ボーン名 (0x00 終端，余白は 0xFD)
short parent; // 親ボーン番号 (なければ -1)
WORD to;
BYTE kind;
WORD knum;
struct { float x, y, z; } position;
} MMD3_Bone_t;
-
>>11
解析データのご開示ありがとうございます。
判らないことだらけなので一つ一つ調べたりしつつ元データとつき合わせて考え考えみております。
-
以下、適当に試したこと
ボーンデータの箇所を参考にダミーボーンをいじって親ボーン番号を入れてみたら無事MMD3でも反映されました。
ﾎﾞｰﾝ02 の親ﾎﾞｰﾝのアドレス 0x000164-165 の FF FF を
00 00 に書き換えると ﾎﾞｰﾝ02の親ボーンがﾎﾞｰﾝ01 になりました。
01 00 に書き換えるとﾎﾞｰﾝ02自身を親ボーンにしたためか位置が動かなく回転だけができるように
02 00 に書き換えると ﾎﾞｰﾝ02の親ボーンがﾎﾞｰﾝ03 になりました。
To は繋がる先を表し、全てのボーンの根っこを00から開始して根っこが終了したら先側という感じなのでしょうか？
ﾎﾞｰﾝ02 の to にあたるアドレス 0x000166 - 167 の 10 00 を
00 00 にすると自分自身へ？
01 00 にすると自分自身へ？
02 00 にすると ﾎﾞｰﾝ03 の根っこへ
03 00 にすると ﾎﾞｰﾝ04 の根っこへ
0F 00 にすると ﾎﾞｰﾝ01 の先っぽへ
11 00 にすると ﾎﾞｰﾝ03 の先っぽへ
,kind,knum はなんのことかさっぱりわかりませぬ orz
x, y, z position の値を変えるとﾎﾞｰﾝの根っこの部分（MMDで中黒のついた□の部分）の初期位置が変更されました。
---
多関節ダミーボーンはできそうですし、着ぐるみ系キャラ用のボーンは自作できそうですよね？
# 関節稼動による変形の伴わないロボットは自作可能
# グラディウス等2Dシューティングであったような多関節触手も自作可能
ってな感じですかねぇ。素人が適当にいじってるだけなので同じ素人の人の参考にでもなればｗ
-
kindは、V2のmiku.osmのぞいた感じだと、
ＩＫか否か移動できるか回転だけか、だったようなオボロゲな記憶。
knumもmiku.osmに出現してたっけ。
バグ報告スレでダミーボーンの別ボーンへの追従の要望が出てるけど、
>>13の改造で実現できる？
|
|
掲示板管理者へ連絡
無料レンタル掲示板
