よねぞん画像掲示板

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

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


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

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

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のはずです。

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がエラーを出さない場合はペイントデータの取り込みが正常に行われたように見えるので厄介ですね。

Yomekoさんのアップローダーで公開されているツールの中に、以前こちらの掲示板に使った様子を書き込んだ(記事No.416)「icp2dat」があります。同じツールがアックスにもUPされているのですが、そちらのアーカイブにはYomekoさんに上がっているものには含まれてないファイルが幾つか入っており、その中に「alpbodyeyetex2.exe」というものがあります。

同梱されているソースのコメントに書いてある使い方によると目のペイントデータの書き出し／格納が出来るようなので(icp2datでは出来ない)前々から試してみようと思っていたところ、Soldatさんがよねぞんフリーアップローダで公開された「ビビリーダー」の説明に「瞳テクスチャは(中略)リアル瞳をお借りしています」とありましたので、丁度いいやとネタに使わせて貰うことにしました。以下、使ってみた様子です。icp2datの作者さんが公開されている別のツール「tga2png」も使います。


最初に断っておきますが、同様の作業はALP2PMXでも出来ます(よねぞん改「たむ式メーカー（ALP2PMX）でテクスチャを変える」(yonezonkai.blog.fc2.com/blog-entry-19.html)によねすけさんの詳しい説明が有ります)。alpbodyeyetex2でなきゃ出来ないというものではありません。基本的に個人的興味で使ってみただけです。また、画像の合成等もtga2png以外でもちろん出来ます。ただその為だけにGIMP等をインストールするのであればtga2pngの方が手軽かなと思います(GIMPでもpaint.netでも、あれば他の用途にも使えますが)。

あと、これ書いてる途中で判明したのですが、alpbodyeyetex2は目のメッシュ名が“eye_A”“eye_AR”の決め打ちになっているので、かすたむ系ヘッド(かすたむ☆たいむ以降)と20773ヘッド以外ではボディのペイントデータしか扱えません。瞳のペイントデータは書き出し／格納共に出来ません。“おまけ”扱いなのでこれは今後とも変わらないと思います。ALP2PMXはもちろんどのヘッドでも大丈夫です。

以下連投です。

使ったツールについて - のぞく人 2018/02/05(Mon) 18:16 No.489
ツールの入手ですが、Yomekoさんのアップローダーからtga2pngを取ってきて下さい。頻繁にアップデートが繰り返されているので番号書きませんが、常に最新版しか上がってないと思います。アックス(www.axfc.net)に置いてあるicp2datはこのアーカイブに入っている“このツールと他のツールについてなど.txt”というファイルにURLが書いてあります(Yomekoさんに置いてあるicp2datのアーカイブ内の“ミラーについてなど.txt”というファイルにも書いてあります)。それを見て最新のものをアックスから落として下さい(パスワードは一緒)。

tga2pngのインストールは、適当なフォルダを作ってそこに実行ファイルとアーカイブ中にある“mesh”フォルダを放り込んでやって下さい(なお展開したmeshフォルダ中の“_ReadMe_mesh.txt”は削除して下さい)。以前にも書きましたが、うちでは“TamTool”というフォルダを作ってそこに実行ファイル(tga2png.exe)と説明(ReadMe_tga2png.txt)とmeshフォルダを他のツールと一緒に放り込んであります。

tga2pngのどの実行ファイルを使うかですが、基本的には“.net4.0”フォルダのものでいいと思います。Windows7(以前)の人も大抵の場合は他のソフトが.Net Framework 4.0以降をインストールしてるものと思われます。Win7(以前)で.Net4.0以降が入っていないと断言できる、もしくはインストールされてるかさっぱり分からない(確認の仕方も)といった場合は“.net2.0”フォルダにある実行ファイルを使って下さい(怒られてから使うので構わないと思う…)。

次いでalpbodyeyetex2ですが、まずアーカイブ内のどこにあるかと言いますと、“icp2dat”フォルダの下にある“omake”というフォルダに入っています。これも実行ファイル(alpbodyeyetex2.exe)をtga2pngと同じフォルダに展開してもいいのですが、使い方(後述)を考えると実行ファイルをデスクトップに置いてしまっても良いかもしれません。私は実行ファイル自体は他のツールと同じフォルダに入れて、デスクトップにショートカットを作りました。実体を置くかショートカットを置くかはお好み次第ですが、どちらかが在った方が使う上で便利だと思います。

alpbodyeyetex2を使ってみた - のぞく人 2018/02/05(Mon) 18:19 No.490
で、取り敢えずの目的です。Soldatさんの“ビビリーダー.alp”(yonezon.coresv.com/joyful2/joyful.cgi?read=3588)は、ノリさんがよねぞんフリーアップローダで公開されている「リアル調のキャラクター用瞳テクスチャ」(“eye.zip”、yonezon.coresv.com/joyful2/joyful.cgi?read=1479)を導入した環境で制作されています。そのままだと同じテクスチャが導入されてないと瞳が意図した通りに描かれません。そこでペイントデータ(レイヤー)にノリさんのリアル調テクスチャとSoldatさんがペイントしたデータを合成したものを取り込んで、リアル調テクスチャが導入されてない通常の環境でも意図した通りの瞳が描画されるようにしようというものです。なお、Soldatさんが同時に公開された「ビビリアルィーダー」(yonezon.coresv.com/joyful2/joyful.cgi?read=3589)にも全く同じ手順が適用できます。

作業に入ります。対象のALPファイル(ビビリーダー.alp)はす〜るのsaveフォルダ以外の所で作業するようにして下さい。alpbodyeyetex2を使う分にはファイルが多数生成される事はないのでデスクトップでも大丈夫ですが、基本的には作業フォルダを作ってそこにコピーするのが良いと思います。リアル調瞳テクスチャも使用してない場合はどこかに展開しておいて下さい。ビビリーダー.alpと同じフォルダでいいと思います。

実は今回試しに使ってみるまで気付いてなかったのですが、alpbodyeyetex2は基本的にはコンソールプログラムです(フォームを持っていないの意)。但し引数を何も付けずに起動すると処理対象のALPファイルを入力する為のファイルダイアログボックスが開き、以後はマウスを使って操作することになります。

引数無しで起動すると、ALPに続いてボディのペイントデータとして入力するファイル、通常目のペイントデータとして入力するファイル、AR目(通常じゃない方、メッシュ名にARが入るのでこう呼ぶことにしてます)のペイントデータとして入力するファイルと順に訊かれます。ペイントデータを書き出す時はこれ3つともキャンセルで抜けるのですが、それなりに面倒なので、デスクトップに置いたアイコンに処理対象のファイルをdrag&dropした方が手っ取り早いです。上でデスクトップにショートカットか実体を置いておいた方がいいと書いたのはその為です。ALPファイルだけをdropすると、ALPファイルと同じフォルダにペイントデータがTGAファイル(α付き32bit無圧縮)の形で書き出されます。

書き出されるペイントデータのファイル名は

[メッシュ名]@[ODFファイル名].tga

の形で、これはALP2PMXと同じです。“BODY_top_L@RT_BODY_TYPE_A.ODF.tga”というファイルも出力されますが、これはボディのペイントデータなので今回は使いません。用があるのは“eye_A@…”“eye_AR@…”の2つだけです。ビビリーダー.alpはのどかヘッドを使用しているので、ファイル名はそれぞれ“eye_A@HEAD_RT_BASE.ODF.tga”と“eye_AR@HEAD_RT_BASE.ODF.tga”になります。このファイル名はALPがどのヘッドを使っているかに依存します(ヘッド毎のODFファイル名やメッシュ名は「ヘッド表3」(よねぞんアップローダーの00048)に書いてあるので確認したい方はどうぞ)。

と、ここで、「メッシュ名がeye_Aとかで始まらないらぶデス２系ヘッドだとどうなるのかな？」と思いnanami.alpで確認しところ、ボディのペイントデータしか書き出されません。ソースを確認してみると、通常目、AR目のメッシュ名がそれぞれ“eye_A”“eye_AR”であるものとして処理されていました。メッシュ名が“eye_A_Mesh_HEAD_RT_base_Layer2”等となっているらぶデス４系ヘッドもyuuki.alpで一応確認してみましたが、やはりボディのペイントデータしか出力されません(当然)。ということで、先に書いたようにalpbodyeyetex2が使えるのはかすたむ系ヘッド(と20773ヘッド)に限ると判明いたしました。

ALP2PMXだったら - のぞく人 2018/02/05(Mon) 18:22 No.491
ALP2PMXを使った場合を書いておきますと、“ビビリーダー.alp”のある場所に“ビビリーダー”というフォルダが作成され、その下に(のどかヘッド使用なので)“head_A”というフォルダが作られて、その中に数多くのファイルと一緒に“eye_A@HEAD_RT_BASE.ODF.tga”“eye_AR@HEAD_RT_BASE.ODF.tga”が書き出されます。これを編集、上書き保存して[TGA⇒ALP]ボタンで書き戻すという流れになります。

tga2pngを使ってみた(合成) - のぞく人 2018/02/05(Mon) 18:25 No.492
ペイントデータが書き出せたので次はリアル調瞳テクスチャとの合成です。これはtga2pngでやってみました。(ちょっと古い版で作業しましたが、多分最新版でも変わってないと思います。)

tga2pngを起ち上げると「File変換モード」で起動します。が、ペイントデータの合成を行うのはこのモードではないので、画面右側下から4分の1くらいの所にある[差分作成モードへ]のボタンを押します。

「差分作成モード」になったら、「ベース画像」(左上)と「比較/合成画像」(右上)を指定します。今回の場合はベース画像がリアル調瞳テクスチャ、比較/合成画像が先程出力したペイントデータです。ファイルの指定は枠内にdrag&dropすることでも出来ますし、枠内を左クリックすればダイアログボックスが出るのでそこからでも入力できます。まずは通常目ということで、ベース画像に“l_eye_A_anim_black.bmp”、比較/合成画像に“eye_A@HEAD_RT_BASE.ODF.tga”を指定しました。

双方のファイルを指定すると、最初は押せない状態になっていた右側にある諸々のボタンが押せるようになります。今回はテクスチャとペイントデータの合成なので[合成画像生成]ボタンを押します。すると、合成された画像が左下に表示されます(作者さんもす〜るで使われている合成アルゴリズムを調べて実装したのではないと思うので厳密に同じことが行われている保証は無いですが、多分同じです)。今回は、他のボタン／設定はいじってないです。

tga2pngでありがたいと思ったのは、比較/合成画像の側がαチャネル付き32bitの画像であれば、ベース画像側が24bitでも出来上がり(合成された画像)がαチャネル付き32bitになる点です(TGAでやっただけでPNGは試してみてませんが…)。合成結果をTGAで書き出してやればそのままALPに書き戻すペイントデータとして使えます。

合成結果の保存は画像の枠内を右クリックすることで出てくるメニューから行います。一番下に「画像保存」という項目があるのでこれをクリックします(右側に出るオプションは変更しなくていいと思います)。ファイルの種類はTGAファイルを選びます。ファイルの場所と名前ですが、ペイントデータの出し入れにALP2PMXを使っている場合は元の場所の“eye_A@HEAD_RT_BASE.ODF.tga”を上書きすることになります。alpbodyeyetex2を使う場合もやはりペイントデータを書き出したフォルダに出力するのが良いと思いますが、ファイル名は“eye_A”という文字が含まれてさえいればOKです(だからと言って“eye_AR”が含まれていてはいけません)。取り敢えず“eye_A_new.tga”という名前で保存して試してみましたが、書き戻しまで無事終了しました。画像は上書き保存でやってみた時のものです。こちらも書き戻しまで問題無く終了しました。

次いで、AR目についても同様の合成を行います(ベース画像が“l_eye_AR_anim_black.bmp”、比較/合成画像が“eye_AR@HEAD_RT_BASE.ODF.tga”)。こちらも最初は合成結果を“eye_AR_new.tga”という名前で保存しました。ファイル名は“eye_AR”が含まれている必要があります。ペイントデータを取り込めたことを確認した後、今度は上書き保存(“eye_AR@HEAD_RT_BASE.ODF.tga”)して再度試しています。

余談ですが、合成結果の画像を直接drag&dropしてみたところ、“合成画像.png”という名前で保存されました。ただ、αチャネル無しの24bitになるようです。

ペイントデータを取り込む - のぞく人 2018/02/05(Mon) 18:28 No.493
最後に、新しいペイントデータをALPファイルに書き戻します。対象ALPと読み込ませるペイントデータ2つの計3ファイル(画像では“ビビリーダー.alp”と“eye_A@HEAD_RT_BASE.ODF.tga”と“eye_AR@HEAD_RT_BASE.ODF.tga”)を選択してalpbodyeyetex2のアイコンにまとめてdrag&dropすると、対象ALPファイルがある場所に“[元のファイル名]_tex2.alp”という名前でペイントデータを取り込んだファイルが書き出されます(今回の場合は“ビビリーダー_tex2.alp”です)。

alpbodyeyetex2を引数無しで起動(もしくはアイコンをダブルクリック)した場合は、先ずALPファイルを指定、ボディの入力ファイルはキャンセル、eye_Aの入力ファイルに“eye_A@HEAD_RT_BASE.ODF.tga”を指定、eye_ARの入力ファイルに“eye_AR@HEAD_RT_BASE.ODF.tga”を指定といった流れになります。ALPファイルだけdrag&dropした場合は追加の入力ファイルは訊かれずにペイントデータの書き出しが行われます(上で書いたのと同じ動作)。合成結果を上書き保存していた場合は問答無用で更に上書きされてしまいますので、注意が必要です。

ALP2PMXの場合は「ALPファイル」に対象ファイル(“ビビリーダー.alp”)を指定して、[TGA⇒ALP]ボタンを押して合成結果を取り込みます。alpbodyeyetex2と違いALPファイルは上書きされます。

以上でリアル調瞳テクスチャとペイントデータの合成及びALPへの書き込み、完了です。

tga2pngを使ってみた2(変換) - のぞく人 2018/02/05(Mon) 18:31 No.494
つづき。瞳のテクスチャデータを直接ペイントデータに取り込むのにもtga2pngが利用できます。要するに、他の形式の画像ファイルをαチャネル付き32bitのTGAファイルに変換する目的にも使えるということです。例としては引き続きノリさんのリアル調瞳テクスチャを利用します。

今度は起動した直後の「File変換モード」でそのまま使います。まず上半分のグリッド(何も読み込まれてない時は真っさらですがグリッドです)の部分に変換したいファイルをdrag&dropして登録します(単純にダイアログを開くような登録方法が見つけられませんでした。ごめんなさい)。今回の場合は“l_eye_A_anim_black.bmp”と“l_eye_AR_anim_black.bmp”の2つのファイルです。

右側中程にある変換モードを選ぶドロップダウンリストからは「TGA画像に変換」を選びます。続いて[TGAに変換]ボタンを押すのではなくて、まずは右クリックします。すると変換動作のオプションが現れますから、「32ﾋﾞｯﾄｶﾗｰ化」(試したバージョンだと上から4番目)にチェックを入れます。ここにチェックを入れないとペイントデータとして読み込めるαチャネル付き32bitのフォーマットにならず、αチャネル無し24bitのファイルとして出力されてしまいます。

改めて[TGAに変換]を押すと、元のファイル名の拡張子を“tga”に書き換えたファイルが出力されます。出力先は変換元のファイルがある場所に固定されています(デフォルトでは出力するファイルと同名のファイルが既にあった時は変換を回避するようです)。他のフォルダに出力したい時は、変換ボタンの3列下にある[出力先]ボタンを押して出力先フォルダを選ぶ(フォルダを選ぶと左側のチェックは自動で入ります)か、ボタン左側のチェックボックスをチェックして出力先を直接手入力するかして予め指定しておいて下さい。

tga2pngを使ってみた3 - のぞく人 2018/02/05(Mon) 18:34 No.495
なお、複数ファイルをまとめて変換するには上記の方法が良いと思いますが、1つずつ個別に変換するなら他の方法もあります。上のグリッドでファイルを1つ選択すると左下の枠の中に画像が読み込まれます。ここで右クリックすると表示されるメニューの最下段に「画像保存」があり、更にそのサブメニューの中に「保存Option表示」があるのでそれにチェックを入れます。そこで上の階層に戻って「画像保存」をクリックするとファイル保存のダイアログが出るので、種類に「TGAファイル」を指定し、場所とファイル名も指定して[保存]ボタンを押します。するとファイル変換モードを選ぶ小さなメニュー(先程の保存Optionとはコレ)が現れるので、「32ﾋﾞｯﾄｶﾗｰ化」にチェックを入れ、[保存実行]ボタンを押すと画像がαチャネル付き32bitのTGAファイルに変換されて出力されます。

個別保存の場合は更に、イメージボックス(画像が表示されている枠)の右クリックメニューで「ImageBox画像」→「α値(不透明度)関連」と進んで「32ﾋﾞｯﾄｶﾗｰ化」を選択し、先にαチャネル付きのデータに変換しておいてから書き出すという方法もあります。

TGAファイルが出力されたら、あとはペイントデータとしてALPに取り込みます。alpbodyeyetex2を使う場合はALPファイルとTGAファイル2つ(今回だったら“l_eye_A_anim_black.tga”と“l_eye_AR_anim_black.tga”)の計3ファイルをまとめてalpbodyeyetex2(もしくはそのショートカット)のアイコンにdrag&dropして下さい。瞳テクスチャをペイントデータに取り込んだALPファイルが作成されます。

ALP2PMXを使う場合は、[ALP⇒TGA]ボタンを使って予めペイントデータを書き出しておきます。その時作成されるフォルダの更に子供の階層にある“head_*”(ヘッドのODFファイルが格納されているフォルダ名と同じ名前。“*”の部分はヘッド毎に固有。ヘッド名との対応は“head_units.dat”に記載されている。のどかヘッドなら“head_A”。これもヘッド表3で見られます)フォルダの中にあるペイントデータ(を書き出したTGAファイル)を探して、先程BMPファイルから変換して作った新しいペイントデータで置き換えます。のどかヘッドだったら

“l_eye_A_anim_black.tga” →“eye_A@HEAD_RT_BASE.ODF.tga”
“l_eye_AR_anim_black.tga”→“eye_AR@HEAD_RT_BASE.ODF.tga”

とファイルをリネームして、“head_A”フォルダにあるファイルを上書きします。あとは[TGA⇒ALP]ボタンを押せば、ALPファイルの瞳テクスチャのペイントデータが新しく取り込んだデータで更新されます。

因みに瞳ペイントデータのファイル名ですが、先にも書いたように使用するヘッドが変わると変わります。かすたむ系ヘッドを使う分には基本的には変わりませんが、エイルヘッドはODFファイル名が違うので“eye_A@HEAD_0000.ODF.tga”となります。らぶデス３、４系のヘッドだとメッシュ名が違うので“eye_A_Mesh_HEAD_RT_base_Layer2@HEAD_RT_BASE.ODF.tga”となりますし(一応全部一緒。AR目だったら“eye_AR_”で始まる)、らぶデス２系ヘッドだと通常目だけで、ペイントデータの名前も“Mesh_HEAD_RT_base_Layer2@HEAD_RT_BASE.ODF”の様に“eye_A”で始まりません(あゆみヘッドは更にODFファイル名も違います)。探す際は注意して下さい。

以上です。全部読み通した方、オツカレサマ！

初めまして、最近らぶデス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の仕組みをちゃんと理解してる人には自明のことなんでしょうし。ちなみにサンプリングエンジンはテクスチャを読み込む時に使われるユニットで、別系統にあります。

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