よねぞん画像掲示板

alp2pmxでalpをpmxに変換・・・に関してなんですが。

たびたびの質問で恐縮です。
自分なりにかなりalp→pmxでググったんですが、
どうしても自分の力だけでは解決無理そうなんで、
ご存知の方が　いらっしゃいましたらお知恵を拝借したく
書かせていただきました。

たむたむす〜るのalpファイルをalp2pmxでpmxに変換、
MMDで表示するときなんですがキャラクターと下着、
アイテムは忠実に反映されているんですが、最近知ったことで
特定の衣装が、バストアップしたキャラに反映されずに衣装を、おっ〇いがぶちぬいてしまうんです。

もし以前に出た案件であったら、見つけきれなかったということで、お許しください。

スライダーにチェックを入れたままならそういうことは
無いんですが、その場合ムネが一番小さい状態のままらしく
なんかちょっと残念というか・・・

ならばと思い、pmxエディタで胸を拡大させるような処理を
してみたんですが、なんか不自然なんですよね・・・・

出来れば、たむたむす〜るの綺麗な胸の形状を再現させたい！

これは、解消出来ない事なんでしょうか？

ただ、今後も主戦場はたむたむす〜るで
やっていくつもりなんで、「それは出来ないよ」
とかいう結論いただければ、未練たらしく
考えなくて済むかな、なんて思ってしまいまして。

でも惜しいのが今回知ったpmxに反映されない
服の一つが「海崎学園制服」なんですが、個人的にこの服が
気に入っているというか秀逸なデザインと完成度が特に
気に入ってまして。
（この衣装＋巨乳でMMDで踊らせたい！）

あと、確かミナモの死神服も反映されなかった
のですが、別な死神服が同じような３Dデータ
だったんでalp2pmxを使用したテクスチャ改造方法
で対応することが出来ました。

で、海崎学園制服については、バストデータが
反映される服を切り抜いて、たむたむす〜るで
着替え→カスタム、切り抜き、重ね（合わせ）着で
対応してみました。
ちょっと感じが変わってしまいましたが、
まあ、なんとか・・・というレベルなんですが。

これで自分の中では一応の解決にしていますが、
ここで不思議に思ったのが「なんでミナモの服の３Dデータは胸が反映されず、同じような形状の３Dデータの
死神服は胸が大きくなるのか？
（確か「黒い死神服」は、胸の大きさが
反映されると思いました、なので現在MMDでミナモ
の死神服を使うときは、黒い死神服PMXデータにミナモの服の
テクスチャを合成しています）

もしかしたら、スゴイ単純な事が引っかかって
いるのかな？とも考えました。
MQOファイルの名前がおかしいとか、でも、
これを書き換えたとしても、MMDには
反映されないし・・・・・


もしこれを、解消できる知識をお持ちの方が
いらっしゃいましたら、ぜひ教えていただければ
幸いです。
長文失礼いたしました。

0

Re: - よねすけ 2018/08/20(Mon) 07:36 No.574
時間がないので胸の部分だけ説明すると、PMX変換時には頂点モーフが反映されないので、胸のモーフスライダーをす〜ると同じ値にしてやればokです（胸以外のモーフも初期化されてます）。

方法は、PMXEでF9を押して出てくるビューから、スライダーを動かして適当なモーフ値にしてやり、現在のモーフで保存とかそういうやつだったと思います（うろ覚え）。
Re: 申し訳ないんですが、 - ゴート 2018/08/20(Mon) 10:01 No.575
お返事ありがとうございます。早速やってみました。
ただ、操作している部分が間違っていますかね？
トランスフォームビューの、モーフの変化量を操作して
みたんですが、服が消えるか半透明になるかで、保存して
MMDで出してみたけど、同じでした。

頂点モーフ再計算と言うところにも、それなりの数字
入れて試したんですが、治らなかった？？

何か根本的な勘違いしてるでしょうか？

もし、ご指導いただけるときは画像貼り付けていただけると
ありがたいのですが・・・・

何とぞよろしくお願いいたします。

新しいツールありがとうございます。制作お疲れ様です。

取り敢えず起動・終了・インストール先の指定が出来ることだけ確認しました。Windows10Home64bit(April 2018 Update)です。まだ動作確認というほど動かしていません。

ところでインストールフォルダ等はどこに記録されているのでしょうか？
0

Re: TAMQOConcierge - 透過好き 2018/06/17(Sun) 14:48 No.551
たしかーProperties.Settings.Default使ってたからー
\TAMQOConcierge\TAMQOconcierge.exe.config かな？
Re: TAMQOConcierge - 透過好き 2018/06/18(Mon) 08:04 No.552
わーALP系の機能入れるの忘れてたー
ALPからどの衣装パーツつけてるかって
どーやれば参照できたっけ？
Re: TAMQOConcierge - のぞく人 2018/06/18(Mon) 20:19 No.553
ALPで使っているアイテムを読み出すのは、頭から読み飛ばしていくしかないと思います。indexが06Hのブロック(WBSファイルに相当するところ)は16個のデータブロック(ICPファイル相当)が並ぶ構造になっていますが、ブロックの先頭がアイテム番号になっています。-1の時はアイテム未装備(空きスロット)です。

取り敢えずALP.SYMは参考になりませんか？
Re: TAMQOConcierge - 透過好き 2018/06/18(Mon) 21:10 No.554
ALP.SYM読み込んでみたんだけどエディット髪のとこで
ItemNOはわかるんだけどそこにたどり着く
アンカー思いつかなくって挫折 orz
ALPのZIPを作る人がファイルリストを作るタイプに仕様変更しましたとさ…
Re: TAMQOConcierge - のぞく人 2018/06/18(Mon) 21:12 No.555
インストールフォルダとかの設定の保存場所見つけました。

ユーザーフォルダの下の「AppData\Local\Microsoft」フォルダに
「TAMQOconcierge.exe_Url_...(略)」
という名前のフォルダが作られて、その下にバージョン毎のフォルダ(今回だと「1.0.0.0」)が作られて、そこに作られた
“user.config”
というファイルに書き込まれてました。

実行ファイルと一緒に置いてあるTAMQOconcierge.exe.configが書き換えられることは無いようです。
Re: TAMQOConcierge - のぞく人 2018/06/18(Mon) 21:25 No.556
ALPの方ですけど、まあ頭から地道に読んでいくしかないと思うので。

バージョンコンバータ系とかrevvtxcなんかは読み込み処理をしてますが、全部読み飛ばしているという意味ではalpdown4のソースが読みやすいかもしれません(ソースあります？)。

あとはicp2datのomakeフォルダの中に適当なソースがあるかな…
Re: TAMQOConcierge - のぞく人 2018/06/18(Mon) 21:35 No.557
既出ですけど、ALP(他)の構造を大雑把に書くとこんな感じです。ご存知かと思いますが一応。

0A(ALP ..07まで)
　　05(BBS ..14まで)
　　　　13(BMS)
　　　　14(MPS)
　　08(FSP ..00(c)まで)
　　　　00(a)
　　　　00(b)(FMS)
　　　　00(c)(FPS)
　　09(HRP ..03まで)
　　　　04(HMS)
　　　　04(HMS)
　　　　04(HMS)
　　　　03
　　06(WBS ..({0D,0B,0C} x 15 or 16)まで)
　　　　{
　　　　0D(ICP ..0Cまで)
　　　　　　0B(IMS)
　　　　　　0C(IPS)
　　　　}　x15(らぶギア以前) or x16(カレカノ以降)
　　07
Re: TAMQOConcierge - 透過好き 2018/06/19(Tue) 10:56 No.558
>AppData\Local\Microsoft
ああーなんかそのあたり探した記憶がうっすらｗ

>alpdown4のソース
探してもexeしかござらんたーい
ALP(他)の構造は暗号･･･
Re: TAMQOConcierge - のぞく人 2018/06/19(Tue) 19:47 No.559
ALP.SYMよりもCUS.SYMの方が例として適当だったかもしれない。

そう言えばモーション系のかすたむファイルは基本的に1ファイル1ブロックで、親子関係を含んでるのはDNCファイルくらいでしたね。

ヘッダから始まってその後にブロック固有のデータが続くという構造は全部のかすたむデータ(形状系もモーション系もDRMファイルも)で共通です。構造のところで0Aとか06とか書いているのはヘッダの先頭にあるブロックの識別標識です(TSXBIN＋ALP.SYMでDTypeのラベルが付いてるやつ)。HANファイルだったら10ですね。

例えばIMSファイルだったらブロック0B１つで成り立っています。IPSファイルならブロック0C１つです。で、ブロック0Dというのは0Bと0Cを1つずつ含んでいて、これ単体だとICPファイルになります。

同じようにブロック13単体だとBMSファイル、ブロック14単体はMPSファイル、ブロック05(BBSファイル)は子としてブロック13と14を含んでいます。

FSPファイル(ブロック08)は子として3つのブロックを含んでいますが、子の標識は全部00になっています(単純ミスと思われる)。2つ目が単独の時はFMSファイル、3つ目が単独の時はFPSになるのですが、この2つはヘッダの標識だけでは区別ができません。

ブロック09(HRPファイル)は子としてブロック04(HMSファイル)を3つとブロック03を1つ持っています。3つのブロック04はそれぞれ前髪、後ろ髪、エクステにあたります。

ブロック06(WBSファイル)は元々アイテム番号と服パーツ毎の着衣・脱衣のフラグが15ずつ並んでるくらいしかデータが無かったんですが、服かすたむが出来るようになってアイテム毎に子としてブロック0Dが挿入されるようになりました。

で、これらブロック05、08、09、06と終端のブロック07(今だに何だかよくわからない)を子に持つ親ブロックがブロック0Aで、これがALPファイルになります。
Re: TAMQOConcierge - のぞく人 2018/06/19(Tue) 19:58 No.561
ちょっと変えた。これでどう？

0A(ALP)
{
　　05(BBS)
　　{
　　　　13(BMS)
　　　　14(MPS)
　　}
　　08(FSP)
　　{
　　　　00(a)
　　　　00(b)(FMS)
　　　　00(c)(FPS)
　　}
　　09(HRP)
　　{
　　　　04(HMS)
　　　　04(HMS)
　　　　04(HMS)
　　　　03
　　}
　　06(WBS)　(カレカノ以降)
　　{
　　　　0D(ICP)　×16
　　　　{
　　　　　　0B(IMS)
　　　　　　0C(IPS)
　　　　}
　　}
　　07
}

なお親ブロック側も固有のデータを持ってるけれど、その辺は考慮しないで書いてます。あくまで構造だけ。
Re: TAMQOConcierge - のぞく人 2018/06/19(Tue) 20:31 No.562
忘れてた。

服アイテムのアイテム番号は、ブロック06内のデータ(繰り返しの先頭)とブロック0D、0B、0Cの標識の次(オフセット0004からの4byte)にあります。
Re: TAMQOConcierge - 透過好き 2018/06/20(Wed) 07:25 No.563
なるほどねー
IPSとか良くわかんなかったんだけど*.ipsでサーチしたらわかったｗ
結局個別のセーブデータを集積していったのがALPってわけね
んでもいまだに78 9Cの意味がわかんないんだけど
これってただのヘッダーなのかしらん
05(BBS)と08(FSP)とかの間を分けるもの？
Re: TAMQOConcierge - のぞく人 2018/06/20(Wed) 12:29 No.564
“78 9C”はzlib(の圧縮データ)のヘッダです。実はフォーマット上は他の値もあり得るのですが、す〜るのデータで他の値になってるのを見たことがないのでこれで決め打ちにしてます(甚だ危険、だが未だエラーに遭遇せず)。

因みにzlibのデータは

ヘッダ＋deflate圧縮ストリーム＋チェックデータ
(ZHdr)　(Zなんとか)　　　　　　(ZCSuM)

という構成です(下段の括弧はALP.SYMのラベル名)。直前の4バイトの値(ZDLen)はこれ全体のサイズです。

参考までですが、これを.Netの機能だけで展開する場合はヘッダ2バイトとチェックデータ4バイトを除いた残りをDeflateStreamに渡します(なのでサイズから6を引く)。tga2pngの作者さんがやってるようにzlibの外部ライブラリをリンクさせた場合は、ヘッダからチェックデータまで書かれているサイズ分まるっと渡します。

ZCSuMの最後のMが何故大文字なのかは謎だ！
Re: TAMQOConcierge - 透過好き 2018/06/21(Thu) 07:08 No.567
ああー
POSの圧縮解凍プログラムを作っていながら忘れてるというていたらくｗ
逆にuだけが小文字なのが気になる！ヽ(´▽`)ﾉ

たびたび、しょーもない質問させてください。

少しでも綺麗なSSを撮りるために、1366ｘ705にしていますが、
任意で、もっと大きく出力することとか出来ないんでしょうか？


MMDなら、倍ぐらいの大きさで出力して、SS撮って編集も出来るんですが、たむたむすーるのキャラをMMDで読み込むと、いろいろ控えめになるというか、修正する方法もあるんでしょうけど、それを極めるなら、たむたむで大きく出力出来れば、それで済むかなと思い、質問させていただきました。

相変わらずシロート丸出しの質問でスミマセン。

0

Re: - よねすけ 2018/05/09(Wed) 20:10 No.525
画面設定はモニターのサイズを元に参照してると思うので、大きいモニターを使うと大きいサイズ設定が選択肢に現れますね。

これはグラボの設定を見てるんでしょうかね？＞詳しい人

前に、画面サイズの設定ファイルを弄ればなんとかなるかもとか考えたことはありますが、設定ファイルを探しきれませんでした。
Re: 出来なければ、 - ゴート 2018/05/09(Wed) 23:15 No.526
よねすけさん、お返事ありがとうございます＆お久しぶりです。
なるほど、大きいモニターですか。
さすがに新品はキビシイので、オンボロを、オークションででも探してみます。

毎回ありがとうございます！
Re: - よねすけ 2018/05/09(Wed) 23:18 No.527
いや、それ以前にいじれるなら設定ファイルをいじるか、あるいはす〜るに偽のモニター情報を流す方法を考えたほうがよいのでは・・・と思います。
Re: 出来なければ、 - のぞく人 2018/05/10(Thu) 00:24 No.528
お久しぶりです。

取り敢えず“data\Config\ToolGraphicConfig.dat”ファイルの[WindowSize]の項目をモニターより大きいサイズに書き換えてす〜る(ver.5)を起動してみましたが、モニターのサイズに書き直されました。起動時にチェックしているようです。

ハードウェア(というかWindows)に問い合わせを出していると思うので、設定ファイルの書き換えでは対応できないんじゃないかと考えます。実行ファイルの問い合わせを出してる箇所を書き換えることになる？(場所の特定はそれ程難しくはないと思う)
Re: 出来なければ、 - のぞく人 2018/05/10(Thu) 00:49 No.529
追記
体験版で実画面サイズ以上の選択肢が並んでいたので選択してみましたが、実際に描画されたウィンドウは実画面サイズの範囲内に縮小されました。因みにToolGraphicConfig.datファイルの[WindowSize]に書かれたサイズはす〜るの設定画面で選択したもの、つまり実画面サイズより大きいままでした。とにかく描画時にチェックが入るらしいということで。

で、ちょっと思ったのですが、仮想デスクトップで何とかならないかやってみようと思います。
一応は - のぞく人 2018/05/10(Thu) 13:41 No.531
以前は「実画面サイズより広いデスクトップを設定してその一部を表示させて使う」みたいなことがWindows＋標準のドライバで出来た気がするんですが、今は駄目みたいですねぇ。仮想デスクトップのソフトもレビューとか見てみたのですが、Windows10標準のものを始め複数デスクトップを切り替えるものばかりで、でっかいデスクトップを実現してくれそうなものは殆ど有りませんでした。

で、ちょっと試してみたら一応大きな画を撮れた別の方法を。

ディスプレイドライバの機能で「カスタム解像度」というものが設定できるのですが、これを実画面サイズ以上の広さにしてみたところ大きなスクリーンショットが撮れました。但し、す〜るのウィンドウサイズの選択肢が実画面の最大の次はカスタム解像度となっていたので(1600×900とか1600×1200とかは出てこない)、ゲーム側がどの様に認識しているのか少々疑問が残りました。

あと、実画面サイズより広いデスクトップを縮小して表示しているだけなので、画面一杯に表示されたす〜るを見ているだけでは本当に大きなサイズで描画されているか見分けがつきません(自分には分からなかった)。画面キャプチャーを撮ると大きなサイズになるので、そこで初めて「確かに広い画面として描画していたのだなあ」と実感できる程度です。

確認したのはWin7・32bitでGPUはNVIDIAですが、カスタム解像度の設定はIntelGPUにも有りましたので、大抵の場合有るものと思われます。アナログの頃はモニターの回帰周波数さえ追いつけば画素数なんてどうにでもなったんですけどねー。

あとカスタム解像度を設定する時に色々と警告が出ると思いますが、そこは踏み越えて下さい。
Re: 出来なければ、 - ゴート 2018/05/10(Thu) 17:18 No.532
ありがとうございます、まずやってみます！
Re: - よねすけ 2018/05/10(Thu) 17:43 No.533
あー、思い出しました。私も設定ファイルいじったけど、起動したら戻っててダメだったんだ。

Re: 出来なければ、 - ゴート 2018/05/10(Thu) 18:28 No.534
やってみましたが、１３６６ｘ７６８以上を設定しようとすると、「画面の大きさを超えている」みたいな表記が出て、ムリみたいです。ま・これについては、衣装テクスチャの時ほど、どうしても必要って訳ではないんで、このままでも良しと思っていますので。

貴重なお時間割いてもらって申し訳ありませんでした。
Re: 出来なければ、 - のぞく人 2018/05/10(Thu) 18:45 No.535
うーん、こちらではカスタム設定で画面解像度を1920×1536に設定したらす〜るにもそのサイズで選択肢出たんですけどねぇ…

まあ、ハードウェアが違えば条件変わっちゃいますからね。残念。
あ、 - のぞく人 2018/05/10(Thu) 18:59 No.536
もしかしたら、テストしたモニターはアナログ入力も持っているので画素数と違う信号が来ても捌けるのかもしれません。デジタル入力だけだとモニターが対応できないとかあるかも。

因みにテストしたのはデジタル入力側です。あと別のモニターでデジタル入力だけだった気がしますが、説明書かスペック表だかに対応できる解像度の一覧があったと思うので(大抵640×480の信号くらいは処理できる)、そういうのがあれば表示ではなく信号を受け入れられる最大の解像度が判ると思います。
独り言がダダ漏れてます - のぞく人 2018/05/16(Wed) 21:39 No.537
今更なんでチェックしてないけど、画面の「スケーリングを実行するデバイス」がGPUになっていたからデスクトップサイズに関わらずモニターの解像度内に押し込めてくれたのではないのだろうか？だとするとGPUでスケーリングするようにさえしておけば(GPUが処理できる範囲内で)デスクトップサイズ大きくし放題なのでは？

うちの場合スケーリングモードは縦横比維持にしてあるけど、これを「スケーリングなし」にしてモニター解像度よりデスクトップサイズを大きくするとどうなるのか。単にデスクトップの中央付近だけが描画されるのか、はたまたスクロールバーが出現して全体が見られるようになるのか。前者な様な気がするけど、「表示できません」と言われて終わる可能性も。
Re: - 手抜きソフト 2018/05/25(Fri) 01:53 No.538
初めまして、ゴートさん。
GeForseの新しめのグラボだったらDSRにすればOKのはずです。
Re: 出来なければ、 - ゴート 2018/05/29(Tue) 18:25 No.543
手抜きソフトさん、ご意見ありがとうございます。次回買う時が来たら、一考に入れておきます。

基本的にYomekoさんのコメントの続きです。ALPファイルで使われている髪エクステ(頭アイテムではない)を指定しているindexを900101から8900101に書き換える手順です。違う番号の場合でも参考にはなると思います。特定のALPファイルに依存した手順ではありません。

最初に。頂いたALPファイルを誤って書き換えてしまわないように、別の場所にもう一つ保存するとかコピーを作って作業するようにしましょう。

件のALPファイルを私は所有しておりませんので、一応付けてみた画像はおとうさんのかやちゃんのものです。ツインテMODも導入してないので、画像に表示されているアドレスや髪indexは実際のものと全く異なります。適宜読み替えて下さい。0

TSXBIN＋ALP.SYMの場合 - のぞく人 2018/05/28(Mon) 18:38 No.540
先にALP.SYMを入れてあるTSXBINを使う場合から。

・“ｼﾝﾎﾞﾙ検索”で「DType」を指定する
・値が「00000004」のシンボルの3つめを探す

因みに1つめが前髪／セット、2つめが後ろ髪、3つめがエクステのデータです。

・「DType」の直下にある「HairIdx」の値を選択して「0087CE05」に書き換える
・下の“L:”や“UL:”の所に「8900101」と表示されているのを確認したら完了

元の値は「000DBC05」となっているはずです。下の“L:”や“UL:”の所に「900101」と表示されるので確認して下さい。値が違う場合は書き換え箇所でないと思われるので、値「00000004」で3つめの「DType」を探し直して下さい。

なお入力モードは「上書き」です。違っているとファイルが壊れるのでご注意下さい。データの種類は“16進”です(変更できませんが一応)。

TSXBINを使う場合は以上です。

他のバイナリエディタの場合 - のぞく人 2018/05/28(Mon) 18:40 No.541
次に他のバイナリエディタの場合。Stirlingを想定していますが、他のバイナリエディタでも同様の機能を持っていると思うのでこれも読み替えて下さい。

・“検索”から16進データで「04 00 00 00 05 BC 0D 00 0B 00 00 00」を検索する
・真ん中の4バイト「05 BC 0D 00」を「05 CE 87 00」に書き換える

“上書”になっていることを確認して下さい。そうでないと(“挿入”だと)ファイルが壊れます。

1箇所しか検索にヒットしないはずです(確認できないので)。もし2箇所以上ヒットする場合は、書き換え箇所を特定できないのでこの方法は使えません(見て判断できる方は別ですが)。

す〜るver.5(FINAL!)のデータであることを前提にしています。ver.4のデータで同じようなことをやりたい方は検索するデータの最後から4バイトめを「0B」から「0A」に変更して下さい。

直接関係ない話 - のぞく人 2018/05/28(Mon) 18:43 No.542
以下余談。ちょっと趣旨が違う話です。

同じODFファイルを複数登録してあるような場合は、上のようにアイテムのindexだけ書き換えればどちらのアイテムを使っているかを変更することが出来ます。これはヘッドでも服アイテムでも同じです。まあ、服アイテム類で同じODFファイルが違うアイテム番号で登録されているものはfood_002(うめいぼー、ねむいぼー、すっきりぼー)くらいしか思いつきませんが。

アナヘッドとまきなヘッドは違うODFファイルではありますが、mesh名、頂点順、テクスチャサイズ等々meshの形状以外のデータは全て一致するので、上のようにしてヘッドのindexを書き換えることでかすたむ結果を他方に移動させることが出来ます(だったと思う)。

先に同じODFファイルと書きましたが、実際にはODFファイル名、mesh名、各meshの頂点数、頂点の並び順、テクスチャサイズといった辺りのデータが一致していればかすたむデータを移動させることが出来ます。(ODFファイル名は実際にチェックされていたかよく覚えてないのですが、ALPには書き込まれます。頂点の並び順はALPに書き込まれませんが、これが一致しないODFファイルの間で形状データを移動させても再現されないので意味はありません。)

のどかヘッド、たむたむヘッド、智里ヘッドの3つもテクスチャファイル名以外は違いが無いので、indexの書き換えだけでかすたむ結果を移せるんじゃないかと思います(ALPにはテクスチャファイル名は書き込まれない)。

(以前indexの書き換えでかすたむ結果を移動できることを確認したと思うのですが、結果を書いたメモとかが見つかっておりません。ALP2PMXでMQOに書き出す方法での移動は交換表に「可」と書いてある以上以前確認したものと思います。)

fixmnameが何をやっているかの説明を書こうと思ってるのですが、ODFファイルのMORPチャンクについての知識が無いとどうにもならないと思うので、まずはそこから説明します。

最初に断っておきますが、す〜るもALP2PMXもソースコードを見ることが出来ないので、以下の説明は外から挙動を観察した結果に基づく推測に過ぎません。そのつもりで読んでください。判ってない部分も多いですし、かなりの部分で自分一人の考えしか反映されてないので見当違いもあることと思います(例えば実際にODFファイルにモーフデータを組み込んでいる性人さんならまた違った知見が有るんじゃないかなあと)。使っている用語もかなり適当なので、自分でしっくり来るものに読み替えて下さい。


ODFファイルのフォーマットについて大雑把に説明しておきますと、いわゆるチャンク構造というやつになっています。データの種類毎にまとめて置いてあるというくらいの意味ですね。ODFファイルの主立ったチャンクには以下のようなものがあります。

MATチャンク … 材質設定
TEXチャンク … テクスチャの一覧
MESHチャンク … メッシュ。形状データとかテクスチャ指定とか
FRAMチャンク … ボーンについての設定
ANIMチャンク … アニメーションさせるデータ
MORPチャンク … モーフのデータ
ENVLチャンク … 頂点ウェイト
BANMチャンク … アニメーションさせるデータ

他にもありますが、アイテム類だと大体この辺りです。各チャンクの内容はあくまでも“大雑把に説明すると”ということで。

可動部分が無ければFRAMチャンクはほぼ空になります。またANIMチャンク、ENVLチャンク、BANMチャンクの有無ははボーンの存在に依存します。MORPチャンクもモーフデータを含まないODFファイルには存在しません。ANIMチャンクとBANMチャンクはどちらもボーンアニメーション用のデータなんですが、どの様に使われているのか判ってないです(が、何か言及してた方は居らした気がする)。各チャンクは1つのODFファイルに1つだけ存在しますが、BANMチャンクだけはファイルの最後尾に複数続きます。0

Re: MORPチャンク - のぞく人 2018/03/23(Fri) 18:19 No.506
ではファイルの内容を見ながらMORPチャンクの説明をしたいと思います。内容の表示に使ったのはバイナリエディタ“TSXBIN”とODFファイル表示用のシンボルファイル“ODF.SYM”です。TSXBINはVectorなり作者様のサイト(TSUCHY Soft、www.net3-tv.net/~m-tsuchy/tsuchy/index.htm)から入手できます。ODF.SYMは茶時うｐろだのup00470.zipに入ってます。

取り敢えずは標準的な内容のものということで、cloth_100_imp.ODF(１級死神装束)を選びました。す〜るver.4体験版の方は予め神ツール等で復号化しておいて下さい。


全てのチャンクとも標識(タグ)から始まります。アドレス0896E2hの「ChunkTag」というラベルが付いてる行、要するに画像の一番上の行がそれです。MORPチャンクと呼んでいるのはタグの値が“MORP”だからです。

次にチャンクのサイズが続きます。サイズの格納場所の次のアドレスにサイズを足した値が後続のチャンクの先頭アドレスになる、という関係になっています。画像の場合だと0896EAhに132C60hを足した1BC34Ahが次のチャンクの先頭になります。このタグ、サイズという並びは全てのチャンクに共通です。これ以降のデータ構造はチャンク毎に異なります(BANMチャンクはサイズの意味も少々異なります)。

続いて「Group.Name」というラベルの付いた64byteのデータがあります。これはMESHチャンクと同様にMORPチャンクも

グループ(レイヤー)0
　モーフデータ0-0
　モーフデータ0-1
　モーフデータ0-2
　：

グループ(レイヤー)1
　モーフデータ1-0
　モーフデータ1-1
　：

みたいな構造になっているという想定でラベル名を決めています。実際にはモーフデータが複数グループに分けられているODFファイルを見たことがないので違うのかもしれませんが、グループ分け構造のデータを読めるようにしておけばフラットな構造でも対応できるので、ODF.SYMはこの様になっています。

なお「Group.Name」の64byteは0しか入っていませんが、他のODFファイルでも0で埋まってるので、この領域には有効な値は格納されていないと思われます。続く「Group.ID」の32bitの値もプログラムは読んでると思いますが、ODFファイル内の他の場所からは参照されていません。

次の「Group.NumMorp」というラベルの付いた値は格納されているモーフデータの個数です。16進数の“3D”なので、61個のモーフデータがあるということになります。

以下、個々のモーフデータの繰り返しになります。

Re: MORPチャンク - のぞく人 2018/03/23(Fri) 18:21 No.507
個々のモーフデータは以下のようにデータが並んでいます。

親メッシュのID
何かのデータ(16byte)
形状割り当て表の行数
形状データの数
名前
頂点数
親メッシュの頂点とのインデクス対応表
頂点数×4byteの領域
　形状データ0の頂点データ群
　形状データ0の名前
　形状データ1の頂点データ群
　形状データ1の名前
　：
形状データの割り当て表
拡張データフラグ
　(有れば)拡張データ
データ(FFFFFFFFh)
大抵0(希にボーンのID)

頂点数が少ないので19番目のモーフデータを見ていくことにします(ラベルに付けてある数字は0から始まっているので「Morp18」は19番目になります)。

上の画像のアドレス10AC7Eh、「Morp18.PMeshID」というラベルが付いた値がこのモーフデータの先頭です。上で“親メッシュ”と言ってますが、要はこのモーフデータで変形させる対象のメッシュを便宜上こう呼んでます(“対象メッシュ”とか他にも言い方があると思われる)。なおODFファイルでは各データにIDが付けられ、データの参照は原則としてIDを介して行われます。

下の画像がID:0170E3C8を振られたメッシュのデータです。IDはアドレス01F46Chに書かれています。「Wear_555_t0_sk_FL02」という名前(00hで区切られるので名前はここまで)が付けられた頂点数20のメッシュです。なお頂点数はアドレス01F4A4hの「NumVertex」というラベルが付いた値になります(16進数の14hは10進数の20)。

上の画像に戻ります。親メッシュに続く「data1」というラベル(以下ラベル名の「Morp18.」は省略)のデータは何だか判っておりません。32bit整数4つのように表示されてますが、実際はいつも0が16byte続くので本当にそういう区切りかも不明です。

Re: MORPチャンク - のぞく人 2018/03/23(Fri) 18:25 No.508
続いて「NumAssign」とあるデータは形状データの割り当て表の行数です。下の方に「番号幾つの時は何番の形状データで描画する」といったことを指定する表(と言っても番号と形状データのインデクスが並んでるだけです)があるのですが、そこに並ぶデータの組の数です。画像の場合はデータは3組(即ち表は3行)です。

この番号というのは、服などのアイテム類の場合は体型スライダーから送られてくる数字になります。ぽっちゃりスライダーだったら左端なら50、右端なら150といった具合です。途中の100とか60とかが指定されてる場合もありますが、表の行数は長くても6くらいです。ヘッドのODFファイルだと表情番号とでもいうべきものが決まっていて、メッシュによっては表の長さが200くらいになったりします。

次の「NumMrpDat」は形状データの個数です。画像の場合は形状データは3つになります。

単純に考えると「割り当て表が3行で形状データが3つあるのなら1行に1つずつ」となりそうですが、もう少し複雑です(実物の所で説明)。また「体型スライダーに左端と真ん中で同じ形状を指定したい」といった場合や「この表情とこの表情で目の開き方を同じにしたい」というような場合もあるので、表の行数より形状データの数の方が少ないことはよくあります。

Re: MORPチャンク - のぞく人 2018/03/23(Fri) 18:27 No.509
次の「Name」のラベルが付いた64byteの文字列領域はこのモーフデータの名前になります。画像だと「Fat_A_t0_sk_FL02」となっています。アイテム類ではこの名前が結構重要です。す〜るはこれを見てどの体型スライダーに対応するデータか判断していると思われるからです(そしてALP2PMXはここでは判断してないと思われます)。

す〜るがどの様にスライダーとモーフデータを関連付けているかですが、これは以下のような文字列をタグとしてモーフ名にそれが含まれているかで判断しています。体型スライダー各々と対応する文字列は以下通りです。

ぽっちゃり ⇔ Fat_A
ウエスト ⇔ Fat_B
ヒップ ⇔ Fat_C
ぽっこり ⇔ Nin_A
胸Ａ ⇔ type_A
胸Ｂ ⇔ type_B
乳首 ⇔ Nip_B
パンツ食い込み ⇔ Fit_A
ソックス食い込み ⇔ Sox_AB

画像のモーフ名は「Fat_A」で始まるので、このデータはぽっちゃりスライダー用のモーフデータであることが判ります。

なお、上で「名前にタグが含まれているかどうか」という書き方をしましたが、これは必ずしもタグから始まっているとは限らないからです。らぶギアあたりまでは名前の最初に位置していたのですが、FINAL!で追加されたデータには「親メッシュ名＋タグ」みたいな順序で並んでる名前が多数あります。また大抵の場合はタグとその他の部分の間に“_”(アンダースコア)が挿入されているのですが、抜けているものが2つ3つあります。その場合もす〜るの動作的には問題ないようです(スライダーに関連付いたモーフデータとして認識される)。

乳首スライダーと対応するタグは「Nip_B」であると書きましたが、実は殆どのブラのODFファイルには「Nip_A」というタグが付けられたモーフデータが存在します。スライダーと双方との関係は実際のところよくわからないのですが、bra_70002(きわどいブラ)やＢブラなどNip_Aのモーフだけ含んでNip_Bのデータが存在しないアイテムでスライダーを動かしてみても変形しないように見えるので、Nip_Bだけがスライダーに関連付けられていると判断しました。なおALP2PMXでは「乳首A」「乳首B」として両方のモーフが書き出されます。

他に「type_D」というタグの付いたモーフデータがＢブラに存在したり「nugasi」や「poff」といったタグが付いたデータがたまにあったりしますが、FINAL!で活用されているのかよくわかりません。

Re: MORPチャンク - のぞく人 2018/03/23(Fri) 18:29 No.510
続く「NumVertex」はモーフデータにおける頂点数です。親メッシュと同じ20(14h)個になっています。基本的には親メッシュと同数の頂点データで構成されてますが、多い時も少ない時もあります。

次の「IndexA」(「Mp18.」も省略)の領域は、「モーフデータのn番目の頂点は親メッシュのどの頂点と対応しているか」ということを記した対照表(マッピングデータ)になります。16bit整数(符号付き)が頂点の数(画像のモーフデータだと20個)だけ並んでいます。並んでる数字は親メッシュの頂点インデクスです。ちなみにここに書かれているインデクスが-1(FFFFh)の時は、モーフデータのその頂点は親メッシュのどの頂点とも対応してないことを意味します。

何故このような対照表が必要なのかと言えば、モーフデータ内の2番目以降の形状データの頂点順が親メッシュと一致しないからです。どういった理由で並べ替えられているのか、またどういう順序に並んでいるのかは判っていません(DirectXでの最適化を図った順かもしれない)。なお、1番目の形状データ(インデクス0)だけは親メッシュと同じ順序で頂点データが並んでいます。

続く「IndexB」の領域は“Index”とラベルを付けてありますが、実際のところは何だか判りません。らぶデス３の頃のODFファイルでも数字(32bit整数)らしき値が並んでいたので何かのインデクスではないかと見られていただけで、確実なのは「頂点数 × 4byte」の領域であるということだけです。全部0でも大丈夫なようです。

Re: MORPチャンク - のぞく人 2018/03/23(Fri) 18:31 No.511
その後に続くのが頂点データ群です。メッシュデータと同じく1頂点あたり52byteで、頂点の個数ぶんだけ続いて1つの形状データを構成します。ラベルが「Mp18_0.」で始まってますが、“0”は形状データのインデクスです(1番目が0)。

「1番目の形状データは親メッシュと同じ順序で頂点が並んでいる」と書きましたが、大半のODFファイルにおいて最初の形状データは座標を始めとする全ての内容が親メッシュと同じになっています(必ずしもぴったり一致してるとは限りませんが、殆どの場合一致)。メッシュデータの画像と較べてみると最初の頂点の座標(「Pos」のラベルが付けられた値)や頂点ウェイト(「Wgt」のラベルが付けられた値)が一致しているのが見て取れます。

なお頂点データに付けてあるラベルは

Pos … 頂点座標
Wgt … ボーンに対するウェイト
Nrm … 頂点法線ベクトル
Idx … ボーンのインデクス
UV … UV座標(テクスチャ上の座標)

となっています。「ボーンのインデクス」はENVLチャンクでのボーンの順番です(これに限っては最初が1)。頂点ウェイトは値が4つ並んでいますが、これは4つ並ぶインデクスとそれぞれ対応しています。

Re: MORPチャンク - のぞく人 2018/03/23(Fri) 18:33 No.512
アドレス10B166hからの64byte(中の文字列)、「Mp18_0.Name」の値が1番目の形状データの名前になります。この様に全ての形状データに名前が付けられています。1番目のものは親メッシュの名前がそのまま付けられていることが多いです。画像の場合は「@」を挟んで後ろにズラズラ続いてますが、こうなっていなければいけないといった決まりがそもそも無さそうに思えます。

名前の後ろ、アドレス10B1A6hの値は「Mp18_1.」で始まるラベルから分かる通り、2番目の形状データの頂点データになります。ということで、1つの形状データを構成しているのは頂点データ群と名前だけです。自分でも時々“サブメッシュ”という言い方をしますが、面がどの頂点で構成されてるかのデータが有りませんので、厳密にはメッシュデータではありません。“頂点モーフ”の情報であると考えれば、頂点の移動先の座標が分かれば事足りるのでこれで充分な訳です。

ただ、親メッシュの頂点が全て形状データにマップされていない時があるので、そういう場合にす〜るがどの様な処理をしているのかは謎です。また形状データの方が頂点が多い時に、親メッシュにマップされていない頂点がどう扱われるのかも判っていません。

Re: MORPチャンク - のぞく人 2018/03/23(Fri) 18:36 No.513
2番目の形状データの頂点データを見てみます。1番目の形状データと較べると2番目の「Wgt」のラベルが「Idx」に、4番目の「Idx」が「nul」にそれぞれ変わっています。

「Idx」は最初の4byteに単精度(32bit)の浮動小数点数で何かの整数が書き込まれていて、残りの3×4byteに0が書き込まれているようです。値の意味する所などは不明です。“インデクス”とラベルを付けてますが、「整数だからインデクス、かなあ…」以上の理由はありません。

「nul」の4byteもいつも0が入っているので「nul」としただけです。1byteの値4つなのか、4byteの値1つなのかもわかりませんが、単に場所を埋めてるだけな気もします。まあ、いつも0なので。

結局、2番目以降の形状データにおける頂点データで有効な値は頂点座標(Pos)、法線ベクトル(Nrm)、UVの3つと思われます。

Re: MORPチャンク - のぞく人 2018/03/23(Fri) 18:37 No.514
アドレス10B5B6hから始まる64byteの領域が2番目の形状データの名前の格納域になります。実は殆どの場合2番目の形状データが標準体型時に描画される形状になっており、FINAL!の新規衣装でなければ名前に「Normal」もしくは「normal」の文字が含まれると思ってまず間違いないです。画像では「Normal_Wear_555_t0_sk_FL02」となっています。

先ほど「1番目の形状データと親メッシュとは形状、頂点順とも同じ」旨を書きましたが、2番目の形状データも親メッシュと形状的には同じです(微妙に違うものや、希に全く違うものもある)。ただこちらは頂点の並び順が異なります。形状データの前にあった頂点の対照表に基づいて並べ替えると、全ての頂点で座標が一致することを確認できます。

2番目の形状データの名前の後には3番目の形状データの頂点データが続きます。

Re: MORPチャンク - のぞく人 2018/03/23(Fri) 18:39 No.515
アドレス10BA06hから始まる「Mp18_2.Name」のラベルの付いた64byteの領域には3番目の形状データの名前が書き込まれています。画像を見ると「Fat_A_Wear_555_t0_sk_FL02」という値になっています。このモーフデータが対応する体型スライダーを示すタグが「Fat_A」、親メッシュの名前が「Wear_555_t0_sk_FL02」ですから、タグと親メッシュの名前を連結したものと言っていいと思います。

2番目以降の形状データの名前は、この様に“モーフデータ内での位置づけを示すタグ”と“親メッシュの名前(か、それに準ずる名前)”を連結したものになっていることが多いです(FINAL!の新規衣装以外)。2番目の形状データの名前も、基本形状であることを示す「Normal」と親メッシュの名前を連結したものになっています。通常、スライダーを示すタグだけが付いているものはそのスライダーを最大限動かした時の形状であることを示しており、ぽっちゃりスライダーを最小側に動かした時の形状が基本形状と別に用意されてるような時は、「Fat_A_LO」のようにスライダーの対応する位置を示す文字列が併せてタグとして付きます。

なお、ALP2PMXではこのタグを頼りに頂点モーフデータを作成していると思われます。形状データの名前が想定外の時は対応する頂点モーフが書き出されず、MMDでスライダーを動かしても変形しないという事態になります。またモーフ名と形状データとでタグが一致しない時は、す〜るの体型スライダーと違ったスライダーに連動する頂点モーフデータが出力されることになります。

Re: MORPチャンク - のぞく人 2018/03/23(Fri) 18:43 No.516
アドレス10BA46hから始まる「Assign」のラベルが付いた3行は、形状データの割り当て表(テーブル)になります。32bit整数が2つ一組で1行を形成します。右側は形状データのインデクスです。左側はアイテム類やボディのODFファイルだったら体型スライダーから送られてくる値、ヘッドだったら表情毎の決められた番号になります。

16進数で書かれているので10進数に直すと以下のようになります。

0 ：1
50 ：1
150：2

2行目で50，3行目で150の場合を指定していますが、50はぽっちゃりスライダーの左端に、150は右端に割り当てられた数字です(スライダーの両端の値は“data\EditData\ToolUI\FaceCustomUISetupData.dat”ファイルに書かれています)。左端の時は形状データ1で、右端の時は形状データ2を使って描画することを指定しています。スライダーが間の位置にある時は、線形変化する(1次関数的に直線状に変化するということです)ものとしてスライダーの値を計算して、その値を使って形状データ1と形状データ2を線形補完(見てきた限りそう思える)して描画する形状を決定します。

画像の場合は両端の50、150しか指定していませんが、真ん中の100に対応する形状が指定されてる場合はそれなりにありますし、60、70といった値に対応した形状が用意されていることもあります。

1行目は0に対応する形状が指定されていますが、この0に対応する行はどのモーフデータでも必ずあります。意味的には“デフォルト”ということなのだと思います。ただアイテム(やボディ)の場合、実際にす〜るが描画する時は必ずスライダーから値が得られるはずなので、この指定がどの様な場合に生きてくるのか分かっていません。

右側の数字を見ると指定されてるインデクスは1と2だけ、即ち2番目と3番目の形状データだけが使用されます。先に「1番目の形状データだけ2番目以降と頂点の並び順が違う」旨を書きましたが、実は1番目の形状データは全てのモーフデータで使用されません。データ構造的に2番目以降と変わらず且つ形状を表すのに必要なデータを保持しているので形状データとして扱ってますが、プログラム的に形状データとして扱われているのかは実際のところ不明です。

Re: MORPチャンク - のぞく人 2018/03/23(Fri) 18:45 No.517
残りはよく分かってないものばかりです。

続く「ExData」とラベルの付いた値(アドレス10BA5Eh)ですが、ここは拡張データが存在するかのフラグ＋αのようです。0以外の時は拡張データの個数、12byte(32bit整数×3)1組の拡張データがその個数だけと続きます(内容は判ってない)。ヘッドでは1〜4の値を取るのですが、アイテム類ではいつも0なので拡張データについてはスルーさせて頂きます。

次の「data2」ですが、これは憶えのある限りFFFFFFFFh(FFhが4個)です。もしかすると古いODFファイルに違う値のものがあるかもしれませんが、かすたむシリーズのファイルを扱う上では-1(32bit符号付き整数と考えた場合)固定と考えて構わないと思います。

最後、「FramID」となっている値ですが、ここは大抵0になっています。ボーン(Frame)のIDが入っているモーフデータを見たことがあるので「FramID」というラベル名になっていますが、実際に目にするものは0ばかりなので有効なデータが入っているフィールドと考えなくて大丈夫だと思います。


以上、いわゆる“普通の”、即ち“イレギュラーなところの無い”モーフデータの説明と、TSXBIN＋ODF.SYMでの表示の見方の説明でした。

スライダーに連動しない - のぞく人 2018/03/24(Sat) 00:36 No.518
す〜る上でスライダーを動かしても服とかブラとかが体型変化に追従しないのは、モーフ名にタグが含まれていないことに因る場合が殆どです。誤字でそうなってしまっている場合や最初からタグに相当する文字列が入ってない場合などパターンは幾つかありますが、す〜るがモーフデータとスライダーを対応付けることが出来なくて起きます。

個々の形状データの名前がおかしいと思われるものが結構あったりするのですが、す〜るではあまり問題にならないようです。なので形状データの名前は全く見てないものと思っていたのですが、親メッシュの頂点が殆どモーフにマップされていないデータ(これ自体イレギュラーなんですが)で名前を変更したら表示が大きく崩れたという事態に遭遇したので、何の影響も及ぼさない訳でもないようです。

ALP2PMXでの変換後にスライダーに連動しなくなる理由は色々あります。

MORPチャンクの説明のところで書きましたが、ALP2PMXは形状データの名前に付けられたタグを見てどのスライダーに対応するモーフであるかを決めています。“タグ＋メッシュ名(かそれに準ずる名前)”という形の名前を想定しているようなのですが、この想定通りにいかないものが多数あるというのが一番の理由です。先にも書きましたがタグは必ずしも名前の先頭にありません。またこれはす〜るが形状データの名前に頼ってないからだと思いますが、誤字と思われるものがそのまま放置されてるケースもかなりあります(「Fat_A」が「Fay_A」になっているとか)。どの形状データか識別する文字列が含まれていても、それがALP2PMXで想定されているものと違う時もあります。

スライダーに連動しないのとは少し違いますが、モーフ名と形状データとで違うタグが付いている為に変形はするけどMMDとす〜るとで違うスライダーに連動する、というものもあります。

す〜るでモーフが動作するのにPMXに変換すると動作しないケースの中には、モーフデータとその親メッシュとで頂点数が異なるのが理由の場合もあります。靴下のつま先側が動くのに膝(ニーソなら腿)側が連動しないというのは大体これです。モーフデータの方が頂点数が多くて且つ親メッシュの頂点が全てモーフデータにマップされている場合は、親メッシュの形状がカバーされてさえいれば連動するように修正できるかもしれません(調査中)。それ以外のケースは修正は難しいかなと思っています。

今のところfixmnameで行っているのは名前関連の修正が殆どです。形状には手を加えていません。ただ、問題が無さそうならばですが、モーフデータと親メッシュとで頂点数を合わせるということも必要かと思っています。もうちょっと調べてからですが。

まあ、具体例を見ないで説明をしてもイメージが湧かないと思うので、取り敢えずここまでということで。

少々違っていた模様 - のぞく人 2018/03/30(Fri) 22:23 No.521
No.513の書き込みのところで、モーフの形状データ(子ですね)について「有効なのは頂点座標と法線ベクトルとUV」じゃないかと書きましたが、UVは微妙に違うようです。

画像は「学園指定ソックス(acce_b_10001sox_imp.ODF)」のメッシュとモーフの形状データをMQOファイルに書き出したものです。膝に近い側のメッシュ(acce_b_004_sox_UpLeg_L及びR)はモーフデータと頂点数が合わないので、モーフ側はNo.510の書き込みに書いたマッピングデータを使って頂点の削除／並べ替えを行っています。

上がMESHチャンクのデータで描いたもの、下がMORPチャンクのデータで描いたものになりますが、見て分かる通りテクスチャの貼り付け位置がずれています。完全に崩れている訳ではありませんが、正しい状態とは言えませんし、ぽっちゃりスライダーを動かしてもこの様には描画されません。ということで、モーフの形状データを構成する頂点データ群のUV値は一見有効な値に見えますが、実際には使われていないようです。

なお、「ニーソックス白(acce_b_1528B_imp.ODF)」ではモーフデータのUV値はメッシュのものと同じだったので、必ず違うということでもないようです(同時に書き出しに使ったスクリプトのせいで違っているのでもないようです)。モーフデータ側のUV値を使う／使わないのフラグがどこかにあるのかもしれませんが、取り敢えずは「MESHチャンクのUVデータを使う」で良いと思われます。