よねぞん画像掲示板

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チャンクだけはファイルの最後尾に複数続きます。

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データを使う」で良いと思われます。

初めまして、最近らぶデスFINALを購入したものです。既に何度か書き込まれている話題ですので恐縮ですが、どうしても答えにたどり着かなかったのでこちらで質問させていただきます。

たむ式メーカーでテクスチャを変えようと思い、ALP→MQO、TGAに出力、外部ツールで瞳のペイントデータ（その時はeye_A@HEAD_RT_BASE.ODF.tgaでした）を書き換え、（圧縮なども切った状態です）元のファイルに上書き保存し（ファイル名もそのままです）、上部のファイル入力欄はいじらずにMQO、TGA→ALPの変換ボタンで変換しました。
そしてそれをたむたむすーるで読み込んだところ、たむたむ自体が動作を停止してしまいました。
何も書き換えずに変換ボタンを押したものでも同様に止まってしまうので、どこに原因があるのか分からず困っています。お力添え願えれば幸いです。

Re: 無題 - のぞく人 2018/03/12(Mon) 22:42 No.498
おむさん、初めまして。のぞく人と申します。

ファイルを書き換えてなくてもす〜るが止まってしまうというのは思い浮かぶ原因がないですね…。こちらでも確認してみたいので、公開されているALPファイルの場合は教えて頂けますでしょうか？

あと、他のALPファイルでも何も書き換えずに「MQO、TGA→ALP」の変換ボタンを押しただけで同じようにす〜るが落ちるようになるか確認して頂けると助かります。あとは…、動作に差が無いはずなんですが、「TGA→ALP」ボタンの方でも同じ症状か確かめてもらえると更に助かります。お願いばかりで申し訳ない。
Re: 無題 - おむ 2018/03/12(Mon) 23:29 No.499
のぞく人さん、ご返信有難うございます。
個人的に作っているものなので公開するのは難しく、教えて頂いているところ申し訳ないです…。

もう一度なにも書き換えずに変換してみたところ、掲示板などで配布されているデータ、問題のデータともに正常に表示されました。ただTGAのみの変換ボタンの場合でも書き換えると同じく止まってしまいます…。書き換えたファイルやツールに問題があるのでしょうか？
Re: 無題 - おむ 2018/03/13(Tue) 03:11 No.500
申し訳ありません、こちら解決しました！お騒がせして申し訳ありません…。

改変したTGAデータを一度PNGに変換、新たに変換で生成したTGAにそれをGIMPでコピペ、圧縮せずに上書き保存、たむ式メーカーでALPに変換、で正常に表示されました。使用しているペイントツール（sai）と相性が悪かったのだと思います。親切に助言して下さり有難うございました。
Re: 無題 - のぞく人 2018/03/13(Tue) 13:04 No.501
無事解決されたようで何よりです。確認だけお願いしてまだ何も返してなくて、お手を煩わせただけになってしまってごめんなさい。

御覧になるかわかりませんが他に見ている人もいるかもしれないので一応返答を。

こちらでペイントデータ(eye_A@HEAD_RT_BASE.ODF.tga)をαチャンネルが無いTGAファイルに差し替えて試してみたところ、おむさんと同じように

ALP2PMXはエラーを出さずに終了する
す〜るでALPファイルを読み込むと落ちる

という状況になりました。なのでこれが一番怪しいかなと現時点では考えてます。αチャンネルがあるかどうかチェックする一番簡単な方法はファイルサイズを見ることだと思うので(無圧縮だからとれる方法)、おかしい時があったらチェックしてみて下さい。αチャンネルが存在する場合は

512dotのテクスチャ → 1025KB
256dotのテクスチャ → 257KB

となります。αチャンネルが無いファイルだと

512dot → 769KB
256dot → 193KB

と大体3/4のサイズになります。

TGAファイルの出力に使うペイントツールはGIMPが確実そうです。Photoshopも(よねすけさんも使ってらっしゃるし)大丈夫なはずなんですが、よねぞん改の当該記事でぷらっしーさんがαチャンネルを上手く書き出してくれなかった旨をコメントされてるので、気をつけた方が良いのかもしれません。私も何かのソフト(忘れました、スミマセン)で、透過部分が無いと判定されたのか、出力段階でαチャンネルを落とされた経験があります。

他の手段として、Yomekoさんのアップローダーにある「tga2png」というツールで変換するという方法もあります。「ペイントデータをいじる(目)」のスレッドのNo.494の書き込みが参考になるかなと。これだと編集中はBMPでもPNGでも関係なく行けます。


余談ですが、実は今までαチャンネルが無いTGAファイルを取り込もうとするとALP2PMXでエラーが発生すると思ってました。今回実際にエラーが出ない所を目にしたので、場合によって異なるのか、単なる思い込みだったのかどっち？？？という状況です(でもそう思ってたということは忘れてるだけでエラーに出くわした経験があるんじゃないのかなーとも)。

他に「TGAファイル内部のデータの並びが上下逆になっている」とか「フッターが無い」(そういうTGAファイルを見たことがあります)等も書き出すソフトによってはあるかもと思いましたが、何れもす〜るが落ちるような事態にはならないだろうと判断しました。αチャンネルが原因でない場合は検討してみる必要有りですが。
Re: 無題 - のぞく人 2018/03/14(Wed) 19:15 No.502
追記。

試しにペイントツールSAI(Ver.1.2.5)で1つファイルを出力してみましたが、ALP2PMXでの取り込みに支障はありませんでした。まあ1つ2つ試したところで大丈夫／大丈夫じゃないなど断言できるものじゃありませんが、参考までに。

やってみたのは、

1. 心愛さんのALPファイルからALP2PMXの「ALP⇒TGA」ボタンでペイントデータやテクスチャを書き出す
2. a_eye_A_anim.bmp(瞳テクスチャ)をSAIで読み込んで、それをペイントデータ(eye_A@HEAD_RT_BASE.ODF.tga)として出力する
3. ALP2PMXの「TGA⇒ALP」でペイントデータをALPファイルに書き戻して、す〜る(都合によりver.4体験版)で読み込んでみる

といった一連の操作です。

SAIでのTGAファイルの出力ですが、ファイルの種類をTGAに指定しただけで他は何も指定していません。と言いますか、指定する場所らしきものを発見できておりません。

取り敢えず今回試した限りでは、αチャンネル付きの32bpp、ランレングス圧縮無しのファイルが書き出されました。読み込んだBMPファイルはαチャンネルの付かないファイルなので24bppで書き出されるかとも思ったのですが、SAIの側でα値(全体に渡り255、即ち不透明度100％)を付加してきました。

SAIが出力するTGAファイルはす〜るで使われてるものとフッタの文字列が少々違うのですが、ここはデータの内容に関係する箇所ではないので、別段問題にはなりません。

ということで、ALPへの取り込み、す〜るでの表示共に問題が起きることはありませんでした。色々やっていれば他の状況も有り得ると思いますが、こういうこともあったということで。


変換したTGAファイル貼ろうと思ったんだけれど、元に戻せちゃうからやっぱマズイよね〜
Re: 無題 - よねすけ 2018/03/14(Wed) 20:48 No.503
のぞく人さんいつもありがとうございます。

なるほど、TGAファイルはアルファが当然あるものとして使ってましたが、アルファがないとエラーがでるんですね。
Re: 無題 - のぞく人 2018/03/15(Thu) 01:23 No.504
透過させたいからTGAフォーマットを使う場合が大半だと思いますが、TGAファイルは書き出せるけどαチャンネルなしに限るみたいなソフトもあった気がしますし(設定見逃しただけかもしれないけど)、ファイルフォーマット的には1ピクセル24bitα無しもあり得ます。

ALP2PMXでの取り込みに失敗するにしろ(ぷらっしーさんもそのようにコメントしてるのでやっぱり場合に因るんじゃ…)ALPを読んだ時点です〜るが落ちるにしろ、上手くいかない時にチェックすべき点の1つかなと。特にALP2PMXがエラーを出さない場合はペイントデータの取り込みが正常に行われたように見えるので厄介ですね。

初めまして、最近らぶデスfinalを入手した者です

初歩的な質問かもしれませんが…
アンチエイリアスを有効にしたいのですが、なぜか項目が押せず、たむたむすーるでもアンチエイリアスの項目は「なし」のままです。どうやったら有効にできるのでしょうか？

win7 32bitのノーパソではダメなんでしょうか(´・ω・｀)

Re: 質問 - のぞく人 2018/01/25(Thu) 02:08 No.479
aoさん、初めまして。のぞく人と申します。

アンチエイリアスだけグレーが一段濃くなっていて選択出来なさそうですが、正直言いまして初めて見ました。

問題の切り分けですが、Win7、32bitであることは全然問題ありません。というか本来の動作環境です。ノートパソコンという形態が問題になることはありませんが、CPUやチップセットに内蔵されているGPUを使ってることが多いので、それが原因です〜るに問題が出ることはあります(デスクトップでも起きるやつは起きる)。

ただ今回のようにアンチエイリアスが選択できないというのは初めて見た気がします。古い機種(が使ってるGPU)だと対応している機能(頂点／ピクセルシェーダのバージョン)の関係で全ての機能が使えないということがあったとは思うのですが、画面を見る限りHDRとか選べるようなのでその辺りは大丈夫そうですし…

上手くいくか分からないのですが、取り敢えず以下の部分をチェックしてみて下さい。

らぶデスFINAL!のインストールフォルダ(「らぶデスＦＩＮＡＬ！」ですね)の下に「data」というフォルダがあるのですが、そのまた下に「Config」というフォルダがあり、そこに動作設定ファイルが入っています。「GraphicConfig.dat」がゲーム本体のグラフィクス設定ファイルで、「ToolGraphicConfig.dat」がたむたむす〜るのグラフィクス設定ファイルになります。普通のテキストファイルなのでメモ帳などで開けます。上から3つ目に[ShaderVer]という項目があるのですが、これの値が“AUTO”になっているか確認してみて下さい。グラフィクスの機能が足りてない時は違う値になった気がします。

続いて上から4つ目に[AntiAlias]という項目があります。多分これの値がが0になってると思うのですが、2とか4とかに書き換えちゃってみて下さい(元のファイルは他所にコピーするなりして戻せるように)。数字がアンチエイリアスの倍率になります。上手くいけばこれでアンチエイリアスが効くようになるかもしれませんが、プログラム側でまた0に書き戻されることも十分予想されます。

[AntiAlias]の項目がもし無かった場合は[ShaderVer]の下に追加してみて下さい。

最後になりますが、PCに載っているCPUやGPUの型番を教えて頂けると何かわかることがあるかもしれません。長文失礼しました。
グラフィクス設定ファイル - のぞく人 2018/01/25(Thu) 02:29 No.480
設定ファイルを開いたところはこんな感じです。これはす〜るの方ですね。

Re: 質問 - ao 2018/01/25(Thu) 21:58 No.481
のぞく人さん、詳しく書いてくださりありがとうございます。

「GraphicConfig.dat」と「ToolGraphicConfig.dat」を開いてみて確認したところ、[ShaderVer]の項目は"AUTO"でした。
しかし、[AntiAlias]の項目を0から2に書き換えて、らぶデスFINALを起動してみても、アンチエイリアスの項目は押せず、すーるの方も「なし」以外の選択肢はなく…。
もう一度「GraphicConfig.dat」と「ToolGraphicConfig.dat」を開いて[AntiAlias]の項目を確認してみたら、また0に戻っていました…。

CPU・GPUですが、「Intel(R) Core(TM) i5-M560」、「Intel(R) HD Graphics (Core i5)」となります。


Re: 質問 - のぞく人 2018/01/25(Thu) 23:05 No.482
返信ありがとうございます。書き換えは駄目でしたか。

Core iの第1世代ですね。対応してる機能が頭に浮かんでこないので、ちょっと調べてみます。
Re: 質問 - のぞく人 2018/01/27(Sat) 00:16 No.483
Intel HDグラフィックスのコントロールパネルの設定項目を探してる最中なんですが、Core i第1世代で使われてるグラフィックスチップはアンチエイリアス(MSAA)をサポートしてないっぽいです。DirectXの方ももう少し見てみないと本当にやりようが無いのかなんとも言えないんですが。

「自分でAAのシェーダーを書けばなんとかなる」のレベルなのかもしれません(誰か書いてくれたら組み込むのはやぶさかではない)。
Re: 質問 - のぞく人 2018/01/27(Sat) 16:28 No.484
Intel HDグラフィックスのコントロールパネル(画面の何もないところを右クリックして出るメニューの「グラフィックス・プロパティー」みたいな項目を選択すると出るやつ)に3Dという設定の括りがあるのですが、GPUがアンチエイリアスに対応してる場合はこの中に「マルチサンプル・アンチエイリアシング」といったような項目があります。で、お使いのPCにはこの設定項目が多分無いものと思います。

もしあった場合はそこの設定をいじってす〜る／ゲーム本編に反映されるか試してみてください。

DirectXのソフトウェアシェーダーでアンチエイリアスがかけられるか確認中なんですが、頂点シェーダーもピクセルシェーダーも全部ソフトウェア処理することになるので、実用的な速度はとても出ないと思います。あと可能だったとしても実行ファイルの書き換えになってしまうので、す〜る／ゲーム本編の環境設定からアンチエイリアスのon／offを切り替えるといったことは出来ません。SS撮る時だけアンチエイリアスの掛かる実行ファイルに切り替えて…みたいなことをせざるを得ないかなと。
Re: 質問 - ao 2018/01/27(Sat) 22:31 No.485
Intel HDグラフィックスのグラフィックスプロパティーで3Dの項目を確認してみましたが、マルチサンプル・アンチエイリアシングはありませんでした。
Core iの第1世代にはアンチエイリアスは対応してないのですね…。アンチエイリアスが有効にならない原因が分かってモヤモヤしていた気持ちがすっきりしました。


のぞく人さんには調べてもらったり、丁寧な回答をくれたりと感謝しかありません。お時間を取らせてしまい申し訳ないです…。本当にありがとうございます！
Re: 質問 - のぞく人 2018/01/28(Sun) 21:35 No.486
いえいえ。引っ張った割に代替策も見つけられなくて申し訳ないです。

DirectXがサポートしたマルチサンプル・アンチエイリアシング(MSAA)をIntelはCore iの第2世代までサポートしてこなかったみたいなんですが、一応代わりの手法は研究していたようで、モルフォロジカル・アンチエイリアシング(MLAA)とかその後継のコンサバティブ・モルフォロジカル・アンチエイリアシング(CMAA)といったものを出してきています。MLAAはCore i第1世代上でベンチマークを取ったりしてるのでドライバーに組み入れてくれてもよかったような気がしますが、そうしなかったみたいですね(第4世代(Haswell)はコントロールパネルからCMAAが選べます)。まあ、MLAAが有効に出来ても、す〜るからアンチエイリアスの設定が出来るようにはなりませんが(多分)、アンチエイリアス自体は掛かるはずなので、残念。

Intelの内蔵GPUを使う上で注意点を一点。

す〜るで使われてる技法で“頂点削除”と呼ばれたりしてるものがあります。これを使ったデータをIntel内蔵GPUで表示させると、消したはずの頂点が足下の方に現れてやはり消したはずのポリゴンが下に向かって引き延ばされた形で描画されてしまいます(yonezon.coresv.com/joyful/img/137.jpgとかyonezon.coresv.com/joyful/img/212.jpgとか参照)。対策パッチもあるのですが、Core i第1世代の場合は先のインテル グラフィックス / メディア・コントロール・パネルを出して「頂点処理」(3Dの項目にあります)をソフトウェアでやるように設定してやれば回避できるはずです。IntelによればCPUで処理しても遅くならない(むしろ速くなる場合もある)そうです。

それでは。

追記。
「ポリゴン伸び」に関わっていそうな辺りの処理(GPUの動作)がCore i第1世代と第2世代以降とで大きく変わっているらしいので、もしかしたら発生しないかもしれません。上は発生した場合の対処ということで。
Re: 質問 - のぞく人 2018/01/30(Tue) 19:06 No.487
aoさん向けという訳ではなく、不特定向けの内容です。

上でCore i第1世代のグラフィックスチップ(Ironlakeと呼ばれる)がアンチエイリアス、もう少し絞って言うとマルチサンプル・アンチエイリアシング(MSAA)に対応してないと書きましたが、これは「Intel HD Graphics DirectX Developer's Guide」(Sandy_Bridge_Intel_HD_Graphics_DirectX_Developers_Guide.pdf)を根拠にしています。これの「2.1.1 What's New in Intel HD Graphics」という項目に「Intel HD Graphics Feature Specifications」という表があり、「Rasterization and Z」の欄に「Added 2X and 4X MSAA support under DirectX 9 and DirectX 10」と書いてあります(一緒に「Added OpenGL MSAA 4X support」とも書いてある)。なお「Intel Integrated Graphics Developer's Guide」(Intel_Integrated_Graphics_Performance_Developer_s_Guide_v2_7_1..pdf、先の文書のIronlake版)の同じ表ではMSAAに関する記載はありません。

海外BBSに「第2世代以降はMSAAに対応してる」とか「第1世代は対応してない」といった書き込みはあったのですが、「根拠としてはちょっと弱いからデータシートでも見るか」とやってたら先の表にたどり着きました(最初はスルーしちゃったけどね)。他にも、Intelの人が書いているモルフォロジカル・アンチエイリアシング(MLAA)の文書(https://software.intel.com/en-us/articles/mlaa-efficiently-moving-antialiasing-from-the-gpu-to-the-cpu)に「IronlakeではMSAA 4xの機能が提供されていない」という記述があります。

さて、アンチエイリアス(の中でもMSAA)に対応してる／してないとか書いてますが、今回のケースで言えば、DirectX経由でアンチエイリアスの機能が呼び出せるかということを問題にしています(MSAAに焦点を当てているのはDirectX9や10で対応しているのアンチエイリアスの方式がMSAAだからです)。MSAAを処理するハードウェアが搭載されているかどうかは直接の問題ではありません。

もちろんMSAA用のハードウェアユニットが載っていれば当然DirectX経由で使えるでしょうし、現にNVIDIAやAMDのGPU、そしてSandy Bridge以降のIntelのGPUではそうなっています。そしてIronlakeにはMSAAを処理するハードウェアは搭載されていません(「IntelのSandy Bridge Graphics Architecture」(IFB003_Intel Sandy Bridge's Graphics_J_.pdf)という学会発表の日本語訳らしき文書に依る)。それでも「IronlakeはDirectX10対応でシェーダーの機能も低くないんだから、ドライバーがシェーダーを駆使してMSAAを実現するということもあるのでは」とか考えていたんですが(上に書いたように表の内容に気付いてなかったので)、先のDeveloper's Guideにある「Intel HD Graphics Texture Sampling and Pixel Specifications」という表のSandy Bridge版では「Multi-Sample Render」という欄が「MSAA 4X」であるのに対しIronlake版では「Single Sample Only」となっていました。Ironlakeでは「マルチサンプル」ということがそもそも考慮されていなかったようで、ソフトウェアでMSAAを実装というのは無理なようです。

と書いたけど、タイムリープぱらだいすではIntelのチップセット内蔵GPUでMSAAを使っているから、やっぱり何かやりよう有るんだよなあ…

それはさておき、ゲームからDirectX経由でMSAAを呼び出す時は、機能が使えるかどうかの問い合わせをゲーム側からDirectXへ事前に出すことになっています。実際にコードを追って確認してはいませんが、す〜るでも当然こういう処理が行われているはずです。す〜る→DirectX→Ironlakeのドライバーと問い合わせが行った結果「サポートしてないよ」という答が返ってきた場合、「ToolGraphicConfig.dat」の[AntiAlias]の項目に0が書き込まれているものと思われます。

す〜るではDirectX経由でしかアンチエイリアスを利用してないようですが(DirectXの描画時にMSAAが指定されている箇所は見たことあるので使っているのは確か)、別段それに限らなくてもいい訳で、実際アンチエイリアスの実装を自前で持っているゲームは多いと思います。SSAAのような重いけど古くから存在するようなものもありますし、GPUメーカー毎にコードを用意する必要はありますが、新しいGPUの機能を活かした新しいアンチエイリアスの方式を利用することも出来ます。上の方で挙げたIntelのMLAAはサンプルプログラムを配布してますが、これもゲーム等にルーチンを組み込むことを念頭に置いたものでしょう。まあでも、DirectX利用とそれ以外とか、二本立てで開発する余力なんか無かったんだろうなあ…

ま、今更す〜るのエンジンが新しくなることは無い訳ですが。ただシェーダーだけで話が済むのならば、シェーダーはリソースとしてプログラム本体と別のブロックに書き込まれているので、何か書き足す余地はあります。ただシェーダーのどの部分がどういう時にどの様な順番で呼ばれるのか私には理解できておりませんので、何処にどう書き足せば良いのかも分かりません。全部ちゃんと読んでみると、まだ何か埋まってたりして…


少々余談。「マルチサンプル」とあるので私サンプリングエンジンの能力が関係してるものと思ってました。でもMSAAの処理ユニットはレンダー出力パイプライン(ROP)に属してるのですね。書き出しの時にサンプリングすると考えれば当然のことなんですが。GPUの仕組みをちゃんと理解してる人には自明のことなんでしょうし。ちなみにサンプリングエンジンはテクスチャを読み込む時に使われるユニットで、別系統にあります。

調べ物のメモのつもりで始めたらどんどん長くなってしまいました。長文失礼。

Yomekoさんで以前配布されていた髪拡張パックと似たようなものを制作中です。バッチファイルじゃないです(流石にそのまま再配布という訳には…)。途中で投げ出さなければ出ます。

kさんには以前「髪は塗れません」と素っ気なく言ってしまい申し訳ないです。あの時点では髪拡張パックのことをすっかり忘れてまして…。いやでも、何か方法が無いかもうちょっと考えてみていれば思い至ったはず。

Re: 言ってみる - よねすけ 2018/01/23(Tue) 18:34 No.476
おお、それはありがたいです。
手動でできるけど、皆で同じ環境を作るなら必須ですし。
Re: 言ってみる - のぞく人 2018/01/24(Wed) 00:56 No.477
髪に色を塗りたいという要望は一定数あるのかなと思って下調べとかしてたんですが、ここの所ALPで使ってるという話が複数出てきてちょっと驚いてます。入れてる人も多いんでしょうけど、新しい人が入手できない状況なんで(手動でも行けますが)。

フォームまでは出来た。

はじめまして。質問失礼します。
たむたむす〜るのデータをalp2pmxで変換してMMDでモデルとして使用したいのですが、それを体験版で行う手順を教えていただきたいです。す〜る体験版とMMD、alp2pmx(私の手違いがなければ)はインストール済みです。

Re: 無題 - のぞく人 2017/11/23(Thu) 16:49 No.455
みしまさん初めまして。のぞく人と申します。管理人じゃなくて失礼。

最初にお断りしておきますと、ALP2PMXはらぶギア、カレマチカノジョ、らぶデスFINAL!何れかの製品版がインストールされてることが動作の前提になっています。これは「このツールを使う人はゲームを買った人に限る」という作者様の意思だと自分は(勝手に)解釈しています。その他にもまだまだ配慮が必要な事柄だと考えられますので、自分からはハッキリ手順を説明することが出来ません。ごめんなさい。

そうこう言ってもらぶギアDL版以外はプレミアが付いてて入手困難な状況ですので、以下を参考にしてみてください(もっといい説明がどこかにあった気がしたけど見つけられなかった)。なおレジストリの操作が必要です。


らぶギア他のDL版はパッケージ版とレジストリに登録されるインストール情報が違っていて、そのままではALP2PMXが動作しません。パッケージ版と同じ情報をレジストリに書き込んでやる必要があります。例えばらぶギアのインストール情報を書き出したものは

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\TEATIME\らぶギア]
"INSTALLDIR"="D:\\TEATIME\\らぶギア\\"
@=""

の様になります。上の5行をコピーしたものを拡張子“reg”で保存してWindowsに読ませるか、レジストリエディタを直接操作して値を書き込んでください。"INSTALLDIR"の場所は実際にゲームがインストールされている場所に合わせて書き換えてください。あと既にす〜る体験版をインストールされているとのことなので、レジストリキー[HKEY_CURRENT_USER\Software\TEATIME]は存在してるものとしています。余談ですが、よねぞんアップローダー(yonezon.coresv.com/upload/upload.cgi)の00074.zipを使うとレジストリの書き込みをコピーと一緒に行います。

カレマチカノジョの方もDL版があった頃はALP2PMXを使うにあたりインストール情報をレジストリに書き込んでやる必要があった訳ですが、こちらは

[HKEY_CURRENT_USER\Software\TEATIME\カレマチカノジョ]
@=""
"INSTALLDIR"="D:\\TEATIME\\カレマチカノジョ"

の様にインストールフォルダ名の後ろの“\\”がなぜか付きません。

したらば掲示板の“改造板”TEATIME4スレッド(オリジナルはjbbs.shitaraba.net/bbs/read.cgi/game/4500/1383924338/)を検索すると関連情報がいくつか出てくると思います。またこちらの情報によると、す〜る体験版でかすたむ☆たいむやらぶギアのヘッド・髪型を利用するにはそれぞれのインストール情報が必要なようです。らぶギアは上に書いた通り、かすたむ☆たいむは

[HKEY_CURRENT_USER\Software\TEATIME\放課後かすたむ☆たいむ]
@=""
"INSTALLDIR"="D:\\TEATIME\\放課後かすたむ☆たいむ\\"

の様になりますが、"INSTALLDIR"には実在するフォルダを指定する必要があるらしいので実際に書き込む値は

[HKEY_CURRENT_USER\Software\TEATIME\放課後かすたむ☆たいむ]
@=""
"INSTALLDIR"="D:\\TEATIME\\たむたむすーる　ver4.00体験版\\"

みたいになるかと思います。

以上、長文乱文失礼。
Re: 無題 - よねすけ 2017/11/23(Thu) 19:30 No.456
のぞく人さん、返信ありがとうございます。

Twitterで聞かれたのですが、私ではわからなかったのでこちらで聞いてみてほしいと頼みました。

みしまさん、レジストリを弄る際は、バックアップを必ず取ってください。
Re: 無題 - のぞく人 2017/11/24(Fri) 08:46 No.458
そのような経緯だったんですね。
レジストリのバックアップのこと書き漏らしてました。フォローありがとうございます。

みしまさんには申し訳ないですが、必要なことは書いたつもりなので汲み取ってください。
Re: 無題 - みしま 2017/11/24(Fri) 22:33 No.459
のぞく人さん、よねすけさんありがとうございます。
ここで質問するまで、体験版で変換する方法を検索しても全く手順がヒットしなかったので不可能なのかと思っていたのですが、ヒットしないのはそのような理由だったんですね。納得しました。

そして返信少し遅れてしまい申し訳ないです！一通りやってみてから返信しようと思ったのですが、元々あまりパソコン周辺の知識がなく、レジストリなどを操作すること自体初めてだったため思ったより手間取っていますので、一旦お礼の返信だけさせていただきます；
Re: 無題 - みしま 2017/11/25(Sat) 00:05 No.460
続けて失礼します。reg読み込みをしたところ、レジストリエディタにらぶギアとたむたむのレジストリが表示されるようになりました。
alp2pxは「ALP２PX　たむ式メーカー」というウィンドウが1つ開きました。正しく動作したということでしょうか？


Re: 無題 - のぞく人 2017/11/25(Sat) 00:53 No.461
ALP2PMXのウィンドウが開くだけでなく、エラーを出さずに変換できて初めて「正しく」動作したと言えます。

ALP2PMXは変換動作の時にレジストリのインストール情報を見てODFファイルやテクスチャを探しに行きます。この時ファイルを見つけられないと

実行時ｴﾗｰ'9':
ｲﾝﾃﾞｯｸｽが有効範囲にありません

というメッセージが出て変換を中止してしまいます(実行時エラー9は他の状況でも出ます)。これを回避するために、インストール先を実際にファイルが存在するところにしておくという寸法です。
Re: 無題 - みしま 2017/11/25(Sat) 12:01 No.462
なるほど。では一度変換してみた方がいいんですね。
変換する際にalpファイルを開くと思うのですが、alpファイルといものが見当たりませんでした。たむたむすーる内でのセーブくらいしかキャラクターの保存方法は把握していないのですが、たむたむ内でalpファイルを作成するのでしょうか？
Re: 無題 - のぞく人 2017/11/25(Sat) 18:47 No.463
す〜るのデフォルトで表示される心愛さんをそのままセーブしたもの(save\AllPackフォルダに保存されます)か、data\EditData\DefEditにあるHeroineA.alp(デフォルトの心愛さんはこれを読み込んだものです)の何れかをテスト用のフォルダにコピーして試してみて下さい。時間経ってるのでもう試されたかもしれませんが(リアルタイム感に乏しくて申し訳ないです)。

変換するとALPファイルのあるフォルダの下にALP2PMXがサブフォルダを作って色々書き出しますから、インストールフォルダ(たむたむすーる　ver4.00体験版)配下でないところに変換用のフォルダを作るのが良いと思います。
Re: 無題 - みしま 2017/11/25(Sat) 22:28 No.464
いえいえ、私にとってはもう教えて頂けるだけでありがたいので・・・。
今試してみたのですが、alp2pxから開こうとしても「検索条件に一致する項目はありません」と表示され、
ファイルを選択できませんでした。（テスト用フォルダ・コピー元どちらも）
Re: 無題 - のぞく人 2017/11/25(Sat) 23:17 No.465
「開く」ボタンからでなく、直接ALPファイルをdrag&dropしてみて下さい。みんな気にしてないだけで「開く」ボタンはちゃんと働かなかったと思います。こちらでもボタンからは開けないです。
Re: 無題 - みしま 2017/11/26(Sun) 19:17 No.466
ありがとうございます。そうだったのですね。
無事ファイルを開くところまではできました。

ただ、上に書かれていた
実行時ｴﾗｰ'9':
ｲﾝﾃﾞｯｸｽが有効範囲にありません
の英語版の表示が出てしまったため、うまくいかなかったようです…。

regの読み込みなのですが、「5行をメモ帳でreg保存→ライブラリのregを右クリックで結合」
という手順で合っているでしょうか？結合後、alp2pxでテスト用フォルダからalpをＤ&Ｄで
変換、上の表示が出た。という流れです。

Re: 無題 - のぞく人 2017/11/27(Mon) 01:06 No.467
最初の455の書き込みで書いたことはあくまでも参考で、らぶギアのDL版を購入した人がALP2PMXを動作させるための手順です。作業手順としては「上の5行を…」でいいのですが、書き込む内容は……ということです。
エラーが出ている原因は多分461の書き込みに書いた通りだと思いますので、レジストリエディタで「HKEY_CURRENT_USER\Software\TEATIME」のキーを開いて値をチェックしてみて下さい。455、461の内容と照らし合わせつつ。

Re: 無題 - みしま 2017/11/27(Mon) 18:27 No.468
そうでしたか…勘違いしておりました。
書き込みの部分はハッキリ書けないから汲み取ってください、ということですね。
まだ今のところ汲み取れそうにないのですが、
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\TEATIME\らぶギア]
"INSTALLDIR"="D:\\TEATIME\\らぶギア\\"
@=""
を体験版のインストール情報に書き換えて保存する、ということでしょうか？

それとエラーのことなのですが、こちらはレジストリエディタでたむたむ体験版とらぶギアの
INSTALLDIRの値（D:\Games\TEATIME\たむたむすーる　ver4.00体験版\など）を同じものにする、という意味ですか？
Re: 無題 - のぞく人 2017/11/28(Tue) 01:23 No.469
REGファイルを使うのでもレジストリエディターで直接編集するのでも目指すところ、即ち設定されるべき値は変わりませんので、どちらか好きな方でやってみて下さい。既に[HKEY_CURRENT_USER\Software\TEATIME\らぶギア]のレジストリキーが存在してるので私だと(慣れてるので)レジストリエディターで書き換えちゃいますが、得られる結果は同じです。

まあ、あとはドキドキしながらトライしてみて下さい。

あと、うちの環境でインストール先が「D:\Games\TEATIME\たむたむすーる…」となっていますが、これは私がルートフォルダ直下にメーカーとかブランドのフォルダを並べるのが嫌いで一段フォルダを掘ってるだけの話で、別段意味はありません。ドライブもフォルダもみしまさんの環境に合わせて読み替えて理解して下さい。

もう一つ。これは特にみしまさん向けということではないのですが、もしす〜るをインストールしたアカウント(多分管理者ですね)以外にもユーザーアカウントを設定していてそちらでもALP2PMXを使う場合には、レジストリの[HKEY_CURRENT_USER\Software\TEATIME]以下の内容をそのアカウントにコピーしてやる必要があります。レジストリエディタデーで[TEATIME]以下をエクスポートして、別のユーザーでログイン(Win10だとサインイン？)してからエクスポートしたものを登録してやればOKです。ま、あんまりそういう人居ないと思いますが、一応。
Re: 無題 - のぞく人 2017/11/28(Tue) 02:14 No.470
461でもチョロッと書きましたが、動作背景をもう少々説明しておきます。興味なかったら読み飛ばして下さい。

たむたむす〜るのALPファイルですが、これは単体だと3Dモデルのデータとして成立しません。TEATIMEのゲームではモデルデータはODFファイルという独自フォーマットのファイルに格納されているのですが、髪のODFファイル、頭(顔)のODFファイル、ボディのODFファイル、服のODFファイル…といった具合に複数のODFファイルと組み合わせることで、ALPファイルは初めて3Dモデルとしての意味を持ちます。大まかに言うと、ALPが持っているデータは
・どのODFファイルを使ったか
・それをどの様に変形させたか(変形後の頂点座標や体型調整用スライダーの値等)
・テクスチャに塗り重ねたペイントデータ
くらいです。

そういう訳で、ALPファイルを読んで別フォーマットの3Dモデルを出力する時は、ALPが読み込んでいる全てのODFファイルが必要になります。これはPMXファイルでもMetasequoiaのMQOファイルでも同じです。

それで変換ツールは必要なODFファイルの在処が分からないとどうしようもない訳ですが、これを知るためにはユーザーから教えてもらうかツールが自身で調べる必要があります。後者の手段でよく用いられるのがレジストリのインストール情報を見てデータのインストール場所を特定するという方法です。そしてALP2PMXではこれがODFファイルの所在決定の唯一の方法になっています。なのでレジストリにインストール情報が見つからない、又はインストール情報に書かれた先を探してもODFファイルが見つからないといったことがあると、ALP2PMXは変換を止めてしまうのです。
Re: 無題 - みしま 2017/12/08(Fri) 22:09 No.471
返信かなり遅れてしまって申し訳ないです。私用が重なって
たむたむに全く触れていませんでした。

今日また試行錯誤しながら色々試していますが、今のところまだ理解が追いつかず目星がついていない状態です。ですが、のぞく人さんはここで言える限りの説明をして下さったと思いますので、これ以上のことは私の理解の問題ですし聞くべきではないかなと判断しています。(こんなにたくさん書いていただいているのに理解できずで申し訳ないです…。)知識不足でグダグダな中、全てにわかりやすい説明で返してくださってとても参考になりました。ありがとうございました。もう少し試行錯誤してみます。
Re: 無題 - のぞく人 2017/12/17(Sun) 06:47 No.472
返信頂いたのにお返事遅くなってしまいすみません。

実は468の書きこみを見た時に「これなら大丈夫かな」と思ったのですが、解決しましたでしょうか？

お察し頂いた通り私からは「動かし方」の説明はこれ以上できませんが、一般的な質問も答えないということはないので、何かあったらお声かけ頂ければと思います。

…でも普通の質問だったらtwitterの方が反応直ぐ返ってきて良いか。