スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

たむたむす~る不具合素材情報

たむたむす~るの各種素材の不具合について、いきなり全部を思い出して書くのは、行き当たりばったりな部分も含め、難しいので、思いついたら書き足していきます。

なお、不具合は環境によっても変わるかもしれませんのでご注意を。たとえば、たむたむす~るを再起動するだけで不具合が直る場合もあります。一応、私の環境では再起動しても無理だったものを記載しておきます。


●顔のペイント情報

これは、それぞれのヘッドでUVマップ情報が異なるので仕方が無いと思いますが、致命的な部分もあるのでメモしておきます。先日確認したのは咲姫ヘッド+愛美目(Red)でしたが、解像度の違う瞳との組み合わせでは起こりうると思います。

通常のペイントは一見問題ないのですが、ぼかしができなくなり、下手するとたむたむす~るが強制終了します。もし上記のような組み合わせで一度でもペイントを行うと(例え瞳以外の部分でも)、ペイントをリセットしない限りは、たとえ目だけデフォルト等に切り替えても、ペイント情報に不具合が生じてしまいます。これはペイントレイヤーとぼかし操作のUV情報が狂ってしまうのが原因ではないかと思います。ぼかしでよく問題が起こるのはこの辺の整合性が取れてないんじゃないかと思います。

【対策】
瞳の元のテクスチャをすべて解像度の高いほう(512x512px)に統一してしまえばいいのではないでしょうかとのことです。まだこちらは試していません。


●UV情報の不具合

サンタ服2011のショールのファー部分には左右で同じテクスチャを使っており、UV情報が共通なのですが、こういう部分は他の衣装の場合、どちらをペイントしても問題ありません。しかし、サンタ服2011の場合、片側からしかペイントできず、しかも反対側にぼかしコピーを使うとそれ以降、一切のペイント操作ができなくなります。一度、ホーム画面に帰ることで操作が可能になります。

この手の不具合は各種パターンがあり、両方ペイントできるけれど突然ペイントできなくなったりするので、調べれば他にあると思います。なお、ペイント操作できるUV情報の不具合で、通常はどうやってもペイントできない服(ブラウンドレス等)があります。

【対策】
ログイン式のページに、UV不具合を修正したODFファイル(UV正規化.zip)がアップされています。バックアップを取った上で、ファイルを入れ替えます。


●パピヨンドレス

色拾いを行っても、ペイントした部分ではなく、元の地の部分のテクスチャを拾ってきます。

【対策】
1280x1280pxのテクスチャを1024x1024pxに差し替えます。ペイントレイヤーがもともと1024x1024pxなので起こる不具合ですので、テクスチャを変えても、ペイントされたファイル自体に問題は発生しません。他の同様の不具合も同じ方法で修正できます。他にも、イレギュラーなテクスチャサイズの素材で発生しますので、色拾いに問題がある場合はまずこちらの解決方法を試してみてください。


思い出したら追記していきます。

コメントの投稿

非公開コメント

いくつか試してみました

パピヨンドレスですが、こちらで試してみたところペイントした部分の色が拾えているようでした。先ずver.5で試してみて大丈夫そうだったので次にver.4でやってみましたが、やはりペイントした部分の色は拾えてたと思います。羽、スカートともにです。

た、だ、し、ver.4で試してたところ3回続けてす~るが落ちました。(最初2回はシステムごと、3回目はす~るのみ。)たまにパソコンが不安定になってす~るが落ちまくることがあるのですか゛、その後しばらく他のことをしていても安定してす~るが動いていました。今のところはパピヨンドレスを疑っております。

目のテクスチャはペイントだけをしてるぶんには普通に動いてるように見えたのですが、ぼかしを掛けてみたら一発でおかしくなりました。当初はAR目の有無が関係あるのかと思ってたのですが、どうもテクスチャサイズの差だけで起こるようです。(まきなヘッド/20773の目で確認。)555系のヘッドも目のテクスチャサイズが512dotなのでこちらも256dotの目テクスチャ(奈々美タイプだったと思う)を指定してぼかしを掛けてみましたが、こちらはす~るが落ちました。

この時挙動を見てて思ったのですが、ヘッドがかすたむ系の時は256dotのデータしか無いところを512dotのつもりで読み取ってデータがおかしくなり、らぶデス系の時は256dotのデータのところに512dotのデータを書き込もうとしておかしくなる(で落ちる)のではないかと。まだそんなに数を見た訳ではないですが。とにかく、実際のテクスチャサイズは可変なのにどこかにサイズ決め打ちの処理が挟まってる感じです。なんか、UVとか以前の問題に思えます…

ところでver.5の方で少々面白いなと思ったことがありました。ヘッド/目を20773/奈々美で目のペイントを試してたのですが、目はそのままでヘッドをまきなタイプに変えたところ、目のペイント情報はAR目相当の方に引き継がれました。5番目に記録されてる(alpファイルとかでの記録順)ペイントデータとしてそちらに引き継がれたのでしょうか(かすたむ系では5番目はAR目、らぶデス系では通常目)。A、ARともに存在するタイプの目で同じことが起きるかはまだ試してません。その後らぶデス系(LD4系のどれかだったかな?)のヘッドに戻したところ、元通り通常目のペイント情報として引き継がれました。尚ver.4で一度試したところではかすたむ系のヘッドに切り替えた時点でペイント情報が引き継がれませんでした。


まだ必要なのかわかりませんが、ペイント範囲のサイズはdata\EditData\ToolUI\ModelPaintEdit\MPT_PaintPoint.datというファイルで指定しています。試したことないですが。

Re: いくつか試してみました

検証ありがとうございます!

のぞく人さん、お手数ですがパピヨンドレス、ペイントしてから一度alpを保存した後、ロードしなおしてみてもらえませんか?その状態でペイントした部分の色拾いをしてみてください。こちらでも今試してロード前は問題なかったのですが、これを試したところver5でも拾えませんでした。

目のテクスチャについては仰るとおりテクスチャのサイズの問題が大きいですね。あと、らぶデスヘッドはそれぞれUVマップが違うようで、その辺も悪影響があるのではと思います。

ペイントレイヤーのサイズについては、素材毎にデータ内部でサイズが決まっているようですが、面白いことにmqoからの読み込みの場合、これがまれにずれることがあります。おそらく、す~るを起動しなおせば問題ないんでしょうけれど、たとえば抱き枕に1024pxと2048pxの2種類のテクスチャを読み込みなおした場合、正しく反映されずにテクスチャサイズが元のサイズに合わなかったりします。(2048pxを読んだのに1024pxのペイントになったり)


あと、ペイントサイズの情報ありがとうございますwww

もしかしたら

すみませんがこちらの事情で2、3日パピヨンドレスの色拾いの確認ができません。(体験版が動かせそうなら後でやってみます。)

ですが1つ気付いたことがあったので。パピヨンドレスのテクスチャは皆1280×1280なんですが(さっき気付いた)、これを1024×1024とかにリサイズすれば普通に動いたりしないかなと。1280角だと多分2048角に拡大してペイント情報を記録してると思うので(1024に縮小かも)、その辺がペイントの動作に影響してるのかもしれません。(ペイント情報自体はALP2PMXかwbs2mqoで書き出してやればサイズ含めて確認できるかと。)

Re: もしかしたら

いえいえ、急いでおりませんので気が向いたときにでも。

テクスチャサイズですか。なるほど、確かに可能性がありますね。
衣装リストにも書いてありますが、特典衣装の多くにイレギュラーなサイズのテクスチャが使われています。

試しにいつも使っている異世界制服を使った武蔵を呼んでみました。いつも使うのはアンダーウェア(1024px)なので気づかなかったのですが、他の部分(1280px)はパピヨンドレスと同様にペイントした部分の色が拾えなくなっていました。

で、以前武蔵をPMX変換したときのデータが残っていましたので、ペイントレイヤであるtgaファイルを調べてみると、全て1024pxでした。原因はこれですね。龍驤の甲板も変換したものがあったので確認してみると、tgaが1024pxで、合成されたbmpは1280pxでした。

リサイズで行けそうです

やっと確認できましたのでご報告まで。す~るver.5で確認しています(ver.4の方が落ちる確率が高い気がするので)。取り敢えずパピヨンドレスだけです。

パピヨンドレスを着せて適当にペイントしまして、それをwbsファイルに保存しました。一旦別のキャラクターに変えてから(alp読み込み)保存したwbsファイルを読み込んでペイント画面に入りましたところ、色拾いができないことが確認できました。

次に一旦終了してテクスチャファイルを3つとも1024×1024にリサイズしたものと差し替えてから先のwbsファイルを読み込んでペイントを試してみましたが、今度は色拾いに成功しました。塗った場所の外縁のグラデーションになってるところもちゃんと拾えておりました(と思います)。

更にテクスチャを2048×2048にリサイズしたものに差し替えて試してみたのですが、今度はまた色拾いができなくなりました。(下地のテクスチャの色をただ拾うだけでなく、もう少し複雑・不可解な動作をしておりました。)テクスチャサイズがペイントデータのサイズの2^n倍なら大丈夫かと思ったのですが、駄目なようです。試してませんが、多分一度保存すればペイントデータが2048角になって普通に動作するようになるんじゃないかと思います。

まだ1つしか試してないですが、以上から考えてペイントかすたむが正しく動作するにはテクスチャファイルのサイズとペイントデータのサイズが同一でなければならないようです。「拡大・縮小を伴わない」の方がより正確ですか。縮小側は試してませんが。ペイントデータは縦横ともサイズが2^nになるので(同じである必要はないがす~るがそういうデータを作るかは未確認)、1280×1280のテクスチャはリサイズが生じてNGにしかならないと思われます。

表示だけなら、テクスチャとペイントデータでサイズが違っててもペイントデータをリサイズして合わせてくれるから問題無いんですけどね。あとテクスチャサイズとペイントデータのサイズが違う時はwbs2mqoがメッセージを出すことをすっかり忘れてました(ペイントデータを書き出さなくても)。


ブラウンドレスのUV値を見てみたのですが、場所によっては2.0を超えてました。(ゴスロリフリルドレス黒でも1.0を超えてるところがありました。)もしかすると塗れないところができる原因は、ラップアラウンド処理(で良かったっけ?要は1.0を超えた時の処理)が本来のODFの処理ルールとす~るとで違うとかいうものかもしれません。もしそうだとすると、ODFは1頂点でUV値を1つしか持てないので、今のところ思いつく対処がないです。(mqoのようにUVが面毎の指定だったらまた違ったんでしょうけど…)

Re: リサイズで行けそうです

検証ありがとうございます!

確かに、テクスチャ解像度を上げた場合はぼかしコピーもできませんね(前によく試してた)。保存したことが無いのでわかりませんが、おそらく色拾いにも同様に問題がでるのでしょう。

となると、店舗特典衣装のイレギュラーなサイズのテクスチャは全て、同様に色広いができないのかもしれません。そういえばFINALが発売された当時、イレギュラーなテクスチャの素材を弄っていて何かおかしくなった記憶があります。1280pxのものもありますし、ショートパンツ系にはさらにイレギュラーな縦横の比率が違うものまであります。この辺、メーカー側が考えずに作っちゃったのかもしれませんw

す~るでは素材毎にペイントサイズは決まっているようですが、のぞく人さんも仰っているとおり、alpやwbs等では2^n以外のサイズが指定できないのかもしれませんね。


mqoはこの辺可変のようですが(2^nではあると思います)、抱き枕mqoのときに『元のテクスチャサイズを変えた場合にぼかしコピーが正しく動作しない場合があった。いろいろ試しているうちに治った。』…というのは、一旦保存されたデータにペイントサイズが書き込まれていて、テクスチャを差し替えた場合に元のテクスチャとペイントのテクスチャのサイズが噛み合わなくて起こる不具合なのでしょうね。


ブラウンドレスはテクスチャをいじるしかないですねー。結構好きな素材なんですが…。
UVが共通している素材は、ペイントを受け付ける場所と実際にペイントできる場所の不具合が多いので困ります。

Re: リサイズで行けそうです

サイズが1280×960である南国ショーパンのショートパンツのペイントデータは、1024×1024のサイズになってます。テクスチャが1280×1280の時と同じですね。

もしかしたら特典データのテクスチャで1280幅のものが多いのは、「素材でなく完成品」という考えで敢えてそうしてあるのかもしれませんね。でもみんな店舗特典を選ぶ時は「どれが素材として面白そうか」という視点で選んでた気が…

Re: Re: リサイズで行けそうです

あるいはメインのモデラーの人が作らなかったか…ですね。このサイズでテクスチャって普通作りませんからね。一部のテクスチャがあまりに酷いのとか、モデル本体も流用ばかりで独創性の無い素材ばかりなので、もしかすると間に合わせのスタッフが作ったのかも…。

異世界制服の肩のパーツが腰の辺りにウエイトが乗ってたのは酷かった…。

UV値をいじってみました

ブラウンドレスのUVをいじったものをログイン式のアップローダーに上げておきました。どうも今は大変そうな御様子ですので、試せるようになったらチェックして頂けると助かります。

ゲーム付属のODFファイルは見た限りではUV値が正の値のものばかりだったのでどうかと思ったのですが、やってみたら負の値でもエラーにならないようです。負の値を使ったからといって「こちらからしか塗れない」の制限が完全になくなる訳ではないですが。一応全部塗れるようにはなったとは思います。

alp他のペイントデータのサイズが2^n×2^m(す~るがm≠nのデータを作るかは不明)になるというのは、今までそうなってるデータしか見たことないのでそうなんだろうなということです。(書いてる時はみんな知ってることのような気で書いてましたが、考えてみたらそんなこたあ全然ないですよね。)

Re: UV値をいじってみました

わざわざありがとうございます!
後で試してみますが、これが上手く行けば本当に助かる不具合修正になりますねー。

ペイントデータのサイズが2^nになるのは、情報量としても簡潔になりますし、まあ、普通テクスチャサイズについてはそうするでしょうね。

UV値ほか

ブラウンドレスとサンタ服の検証ありがとうございました。塗れる塗れないもあるんですが、本当に元のものと見た目が変わってないかとかデータ的には大丈夫なはずでも自分が見ただけだと不安なものですから。アーカイブに突っ込んであったRubyのスクリプトはC#で書き直してどこかのアップローダーに上げるつもりです(バグフィックス的なものなのでYomekoさんのところにしようかと思ってます)。当初の予定ではもう出来てるはずだったんですが、色々と事情やら思惑やらで遅れております…。

UV値は全体を調べたところ負の値を取るものもそれなりにありました。中には意識的に負の値にした訳ではなく「点を指定したら0より左側に行っちゃった」みたいに思えるものも有りますが(同様に「1を超えちゃった」的なのも有る)。また、エプロン(のフリル)や鎌(の柄)では縦(V)方向に0~1を超えた範囲でUV指定されてました。

中にはわざと0~1以外の値にしてす~るでペイント出来ないようにしたものもあるのかもしれないです。また1ヶ所からしか塗れない方が分かり易いという考えで値を調整したものもあるかもしれません。そういうものがあったとしても「自由にやらせてもらいます」ということですね。「自由」と言うにはかなり制限が残りますが。

0~1以外のUV値を含むODFファイルは確認したのですが、それらが全部す~るでペイント出来ない箇所があるかは確認しておりません。流石に全部確認するのは面倒なんでやらないでしょうが。


ヘッド関連の一覧表を作った時に判ったことを少々。以下のヘッドの組はそれぞれODFファイル的には同じものです(FC /B で一致します)。
 エイルヘッド(head_0000)とアナヘッド(head_AA)
 ロタヘッド(head_0100)とあゆみヘッド(head_R)
 委員長ヘッド(head_CC)と琴ヘッド(head_U)
 真帆ヘッド(head_DD)と翔子ヘッド(head_H)
 文緒ヘッド(head_EE)とみなもヘッド(head_T)
 えしろえヘッド(head_ES)とアナヘッド(head_AA)
かなみのヘッドはそもそもアナヘッドです。

以下雑談。
「かみさまのおえかき」が発表された時私が思ったことは「TEATIMEはそんなに急いで売り上げを立てないといけないのか」でした。なので内容抜きにこれは買わないといけないと思ったのですが、同様に考えた方は殆どいなかったようで…
実際内容的には確かに地雷(未だにやってないので伝聞)といいますか、多分らぶギアのおまけゲームの1つとして企画されたものなんだろうと思います。色んなデータがらぶギアのものですし。それをアンダロイド等で使い始めた新エンジンに乗っけて、独立したゲームとして売ることにしたんだと推測してます。す~るが付属しなかったのは、新エンジンにす~るをくっ付けるだけの時間が無かったんだと思います。

「恋愛+H」系でも「アンダロイド」系でもTEATIMEのゲームだったら3Dモデルのファイルが同じODF、名前が同じなだけでなくフォーマットが共通で(その時々での差違はあるがゲームの系統で違うということはない)ツールも共通して使えるというのは結構凄いことのような気がします。会社の規模的にも複数系統のデータフォーマットを作る(複数系統のツールを用意する)ことは出来なかったのでしょうけど。


「よくわからない」と言われてしまった気がしますが、コメントだから気にしないで行こうということで。

Re: UV値ほか

修正助かりました。現状、テクスチャをいじるよりもペイントした方が早くてそこそこ良い物ができるのでありがたいです。スクリプトについては、あまり知識が無いので他の得意な方に試してもらった方が早いでしょうね。

UV値については、たぶんほとんどは、当時、不具合として認識できていなかったんじゃないかなあとも思います。こういう部分、ユーザー側で小まめにバグ報告するべきでしたね。スタッフも足りてなかったとは思いますが。


質問ですが、ヘッドのodfが同じというと、具体的にはどの部分(全部?)が同じなのでしょうか。(ODFにどの程度の情報が含まれているのかわかってないのですみません。)

・頂点の位置
・頂点モーフ
・UVマップ

かみさまの~以降の素材はどれも流用の域を出ないというのは、大体わかりますが、私が以前調べた限りでは、委員長、真帆、文緒はペイント情報の引継ぎが特殊だったので、どの程度同じなのかなと気になりまして。ver5のヘッドは使ってないので詳しくないのですが、こねる側としては、この辺気になります。


かみさまの~は、tweetもしましたが、宣伝の仕方がどうもそれまでのTEATIMEとは毛色が違う感じだったので、完全に避けてましたね。それまでは、情報はできるだけ出す、売りになる部分は体験版を出す、エロイラストよりも普通のカワイイイラストで売る…と言った感じでしたし。まあ、メインの方が居ないのでイラストからして無理でしょうけど、それまでは作る側が楽しんで作ってる感があったからこそ買っていたんですよね。

カレマチも特典衣装が出ませんでしたし、公式のサポートにもアソビ心が無かったので、メインの方は発売後すぐに抜けられていた印象ですが、半年経っても次回作の発表が無かった時点で次は無いかもしれないなとは覚悟しておりました。


特典衣装の色拾いバグについては、解決方法を記事でまとめようと思います。

ヘッドのODF

ご質問の件ですが、全部分が同じです。要するに
 ・頂点の位置
 ・頂点モーフ
 ・UVマップ
の情報は全部ODFファイルに含まれています。(そしてバイト単位で全バイトが一致する。)テクスチャファイルの内容のみが違うということになります(名前は同じ)。

前にも書いたかもしれませんが、alp他のカスタムデータファイルが保持してるのは
 ・カスタム後の頂点の位置(モーフの情報は無し)
 ・カスタム後の頂点の法線ベクトル
 ・元テクスチャに重ねるペイントレイヤー
のみになります。

以上、お知らせまで。

Re: ヘッドのODF

了解でーす。ありがとうございます。

となると、ヘッド一覧の情報で同じ物ということで解説しておいたほうが良いですね。テクスチャなんて塗っちゃえば全部同じですし。ありがたく使わせていただきます(むだんけいさい

となると、odf以外の部分でペイントの共有情報決めているんでしょうかね。ver5のヘッドは、ペイントが引き継がれないことが多かったと思うので。もう一度検証してみますが。(いちばん信用できないのは自分自身の検証なので

目のテクスチャ

ペイント情報の引き継ぎは自分も試したことがないので分からないのですが、目のテクスチャサイズは一致しないものが多いので扱いに注意が必要かもしれないです。
 あゆみヘッド/琴ヘッド/みなもヘッド
では目のテクスチャサイズは256pxでしたが対応する
 ロタヘッド/委員長ヘッド/文緒ヘッド
では512pxになってます。また翔子ヘッドのAR目のテクスチャサイズは256pxですが、真帆ヘッドのAR目は512pxとなってます(通常目は512pxで同じ)。

わたくしの書いたことの転載などはご自由にどうぞ。と言いますか、まとめて頂いたり他の情報と結びつけて頂けるのは大変ありがたいことと思います。

Re: 目のテクスチャ

お、なるほど。つまり古いヘッドの低解像度テクスチャを改善したのがロタ/委員長/文緒ヘッドということですね。この三つのヘッドの瞳は、どのペイントグループにも属してない(他と共有されない)ので、おかしいとは思ってました。そして、私の資料、文緒ヘッドのペイントグループが間違えてましたw これ、1番じゃなく2番でした。

http://yonezon.blog.fc2.com/blog-entry-273.html

転載許可わざわざありがとうございますw

遅いですが

ブログ加筆された後になんですが、ログイン式のロダにヘッドODFファイルのメッシュやテクスチャの一覧表を上げておきました。上で触れたやつです。(表のロダで良いと思ったんですが、今手もとに取説無いので。)0~1以外の値をUVに持つODFファイル(Itemフォルダのもの)とそのメッシュの一覧も一緒に入れてあります。

が、説明を入れてないので、どちらも見方がよく分からないかもしれません。

上記エントリーの記事ですが、ペイントグループ一覧表の楓の行の目のグループ番号は7ではなくて4なのではないでしょうか?ペイントして確かめた訳じゃないですが、数字が飛んでたのでそう思いました。

Re: 遅いですが

おお、わざわざありがとうございます!
構造的に、いろいろ疑問だったものがわかるかもしれません。中には、ペイントレイヤが共通なのにUVマップが違うとか妙なヘッドもありましたしね。表の『デ』はなんでしょう?デフォルメ目ですか?

ペイントグループ表ですが、楓は確かに独立した瞳のペイントを持ってます。4番とは共通ではありません。こういうの、ところどころにイレギュラーがありますが、もしかすると、たむたむす~るに導入する際、修正したものかもしれません。推測でしかありませんが。

もしかすると、調べていないAR目にイレギュラーが他にもあるかもしれません。

Re:Re: 遅いですが

楓のペイントグループの件、了解です。リーサの6の次で7ということだったんですね。

「デ」は仰る通りデフォル目です。“4”はデス4以降の形式、“2”はデス2、デス3の形式を表してます。“21”と“22”はデス2形式ですが図柄の組み合わせが標準と異なるものです。

楓ヘッド

先程上げたヘッド情報一覧表ではわからないのですが、楓ヘッドだけは他のヘッドと違ってAR目のメッシュ情報が通常目より前に格納されてました。ペイント情報が他と共有されないのはこれが理由だと思われます。(多分通常目とAR目のペイント情報が逆転して引き継がれるんじゃないかと今思いました。)

Re: 楓ヘッド

お、なるほど、そういうことでしたか。納得です。いろいろ疑問が解消されて楽しいです。
というか、時間取られるでしょうに、わざわざ事細かに調べていただいてありがとうございます!
私は相変わらず気が向いたときしか動かず、次に何こねるかしか考えていませんw

ヘッド表移動しました

ログイン式のアップローダーに置かせてもらってました「ヘッド表」ですが、“よねぞんアップローダー”の方に移動させてもらいました。同時にメッシュ/テクスチャをODFファイル内での出現順に並べた表を追加してあります。(但し全メッシュでなく各テクスチャを最初に読み込むメッシュのみ。)これはalp他のカスタムデータファイル内での記録順と同じ順序になってると思います、多分。

なぜこの様な表を作ったかと言いますと、同種のメッシュ/テクスチャが縦に同じ列にある場合(出現順が同じ時)はヘッドを換えてもペイント情報が引き継がれるのではないかと思ったからです。その検証作業用ということですね。検証自体は追々やっていこうかと。(勿論どなたか他の方がやって下されば私楽ちんなのですが…。)

少々思ったのですが、例えば瞳のテクスチャを全部512pxに統一してしまえば作業時のトラブルが減らせるのではないでしょうか。もちろん要検証ですが。らぶデス系のヘッドは512に統一した方がいいのか256に統一した方がいいのかも分かりませんし。生成されるペイントデータのサイズも変わると思いますが、これが元来のテクスチャサイズでも正しく適用されるかも要確認ですね。

上に書いたようにODF/alp内でのメッシュの出現順を揃えることでペイント内容を引き継げるようであれば、実際にメッシュ情報の順番を入れ換えたODFファイルを作ってしまうのも良いんじゃないかと思います。ファイルからのカスタム情報の参照は記録順でなく名前で行われるので、既存alpファイルが読めなくなるとかいったことは無いはずです。まあ、ヘッドのグループが違えば参照してるテクスチャの数や種類が違いますから、らぶデス系ならペイント情報が全部共通になる、とかいったことは無理ですが。

そもそも「ヘッド途中で換えないからそんなもの要らない」と言われるとそれまでではあります。


ここで話題になったからということもありますが、最終的には自分の興味で動いてますからその辺はお気遣いなく。自分にとってのTEATIMEのゲームの楽しみ方は「調べる」ですから。

ペイントデータのサイズ

話がパピヨンドレスに戻っちゃいますが、書いとかないと忘れると思うので。

先ずパピヨンドレスのテクスチャを3枚目の“get_SKT_01.bmp”を残して2048px四方にリサイズしたものに変更しました。この状態で羽(テクスチャサイズは2048)をちょっとペイントしてwbsファイルやipsファイルを保存してみたところ、ペイントデータのサイズは2048pxでした。これはテクスチャ3枚分全部です。

次にスカート(テクスチャサイズは1280)をペイントしてwbsファイルを保存したところ、今度はペイントデータのサイズは3つ全て1024pxになりました。

次にテクスチャ3枚ともサイズを2048pxにしてからチョボチョボとペイントしてipsファイルを保存してみると、これはまあ予想通りなんですが、ペイントデータのサイズは2048になってました。更にこの状態で先程のペイントデータ(1024px)を読み込ませてペイントを追加してからipsファイルを保存してみたのですが、ペイントデータサイズは1024pxとなっておりました。これは自分にとっては予想外の結果です。2048pxになると思っておりました。

なんと言いますか、今一つよく分からない動作な気がします。ペイントデータサイズが3つ揃って変わるところとか。法則性を見出すほどたくさん実験した訳じゃないですが、何となく1024pxを基準に動作してるような印象を自分は受けました。

Re: ヘッド表移動しました

しばらく返事できてなくてすみません。

確かAK47シリーズやってたころに、瞳のペイントを512pxに差し替えてぼかしコピーしようとして上手くいかなかった(512pxになってくれなかった)ので、256pxで処理したような覚えがあります。それもあったからか、店舗特典のalpのペイントが可変と聞いて、すごい!と思ったのです。

もしかすると、前のペイント情報が残っていて256pxで処理されただけかもしれません。(一度保存すると差し替えるまでそのままのようですので。)実際に試してみないとわかりませんね、この辺。確かに、テクスチャサイズを統一する方が、面倒が減っていい気もします。

ペイントデータのサイズ2

服のカスタムデータを中心に見てきた自分としては、身体のテクスチャだったかで「テクスチャサイズを大きくしても記録されるペイントデータの解像度は高くならない」という報告を見た時に「そういうこともあるんだ」と思いました。服と言いますか、アイテム類は基本的にテクスチャのサイズがそのままペイントデータのサイズでしたので。もちろん2^n以外の幅/高さを持つものなど例外はありましたが。

2048pxのテクスチャですが、「リサイズで行けそうです」のところで書いた色拾いの問題が解消されてるかをチェックするのを忘れておりました。ただ、もし色拾いが大丈夫だったとしても他のテクスチャへのペイントでペイントデータのサイズが1024pxに変わってしまう辺りに動作に信頼が置けない印象を持ちましたので、テクスチャサイズは1024pxに留めておいた方が無難かもしれないです。プログラム的に2048pxを許容してるところとしてないところがあるんじゃないかと。


>しばらく返事できてなくてすみません。
またよねすけさんのPCの調子が悪いようでしたので「こりゃこちらの返事まで手が回らないだろうな」と思ってました。気に掛けて頂きありがとうございます。(ところで、出たりで出なかったりするトラブルというと接触不良、ケーブルの不良、電源の不良あたりが疑わしいと思いますが、電源のコンデンサーが飛んだのはそのPCではないのですか?)

関係ない話になりますが、性人さんが「かすたむ範囲を拡張した…」と書かれていた気がするのですが、どのようなことをされてるんですかね。性人さんもす~るの限界を極めてる方の一人だと思うので、結構気になります。

No title

ご心配をおかけしますー。

今、PCが安定しているので、なんとか明日までに服をこねてしまいたくてそちらを無理して優先しております。

たぶんコンデンサーが破裂したのは電源だと思います。見える場所に裂けたコンデンサが見当たらなかったので。電源を入れてしばらくが安定が悪く、ある程度時間が経ってしまえば安定するので、可能性はあります。音は間違いなくコンデンサの防爆弁が破裂した音でしたし。

もうひとつ、SSDも疑っております。このPCも4年近く経ちますし、どちらかというとまだSSDが安定し始めた頃のものでしたので、HDDにOSを入れて安定すればそれかなとも思います。とりあえず、次回クリーンインストールが必要になった場合はHDDにインストールしてみようかと思っています。

電源は、今のグラボを動かせる代わりの電源が手元に無いのと、無闇にパーツを買うのを禁止されてるのでw 以前、中古のM/Bを買って交換しまくってダメだったことがあってから、無闇にパーツ換えるなら新しいPC買えと言われてるので、代わりの電源は買えそうもありません。


性人さんの書かれていたのは股か何かじゃないでしょうかね?中は見ていませんが、前に改造板で少し話に出てたやつじゃないでしょうか?

リボンのUV値

ただ今ODFファイルのUV値正規化ツールを書いてるのですが、アルゴリズムを詰める為にす~るを起動したところ、数回続けてシステムごと固まりました。ペイントの確認ができません。困った…

電源を落としての再起動後は固まりこそしなくなりましたが、す~るの表示がおかしくなるので使えないことに変わりはありません。タイムリープぶーとべんちとかは動くのでハードウェア的な問題ではないとは思いますが、負荷が違うのでその辺何とも。

確認しようとしてたものの一つが「女の子の帽子」(acce_0200)と「学園指定帽子」(acce_0201)のリボンなんですが、ざっと見たところではこれらの全頂点のUV値が(0.0,1.0)となってます。これ、塗れるんでしょうか?法線マップとかディスプレイスメントマップも有るけど効いてるのでしょうか。UV値を(0.0,0.0)に変更しても状況に変化が出ないか確認したかったのですが(塗れてたのが塗れなくなったりすると困る)、今はちょっと無理ですね。

もう一つは「アイマスク」(acce_9901)で、直接ペイントできない場所があるかを確認しようとしておりました。落ちちゃうので判らなかったのですが、内側の茶色は色拾いできますけどあれテクスチャのどの部分なんですかね?


性人さんがされてる拡張は“キーワード対策”辺りと見ましたか、なるほど。あれは実行ファイル書き換えではありますが、配布データに影響が出ないという観点では一番スマートですよね。エロアイテムのやつもいつか再チャレンジしてみたいです。

趣味の範囲ならばPCの怪しそうなパーツを順に交換もアリだと思いますが、時間を掛けられればこそですよね。自分は以前は拡張カードの交換とか結構やったのですが、Windowsにアクティベートが必要になってからはめっきりやらなくなりました。

Re: リボンのUV値

ご心配をおかけしました。新しいPCにたむたむす~るが入ったので、もう無駄な時間は過ごさないと思います。まあ、性能を試すのに調子に乗ってFPSしてましたが…。PCパーツの交換チェックは中古といっても、それなりのスペックのものを用意してるとお金もかかりますし、ストレスもかかりますので気軽にできませんね…。とりあえず、SATAケーブルのしっかりしたのに変えて、SSD初期化してみる予定です。

ご指摘の部分、twitterに画像を貼っておきます。リボンについては、正面からはペイントできるのですが、2層?になっているのか、元の色の層とチラチラと切り替わります。元の層は塗れません。

アイマスクは、後ろ半分は繰り返しになっていますが、ロールがずれているのでペイントできない部分があります。

検証ありがとうございました

遅くにペイント試して頂きどうもありがとうございました。乱暴な言い方になりますが、リボンはどう数値をいじろうと現状より悪くなることは無さそうですね。全く塗れないかと思ったのですが、結果は予想の斜め上でした。

UV値が全頂点(0.0,1.0)になってる(まだ目視だけ)のはモデリングした人がUV展開を忘れたんでしょうが、(0.0,0.0)でなく(0.0,1.0)となってるあたりは謎です。Vの値が1.0に到達してるのに色が塗れる仕組みもよく解りません(有効な値は0.0≦U,V<1.0ではないの?)。す~るはまだまだ奥が深いです。

アイマスクはUが2.x~6.xという範囲にわたる一続きのメッシュがあるのでどんな感じになるのだろうと思ったのですが、普通に塗れないようですね。このメッシュは結構やっかいで(ここまで値が広範囲なのはまず無い)、0.x~4.xもしくは-1.x~3.xの範囲にUV値を変更したとしても直接塗れないところが結構残ってしまいます(0.0~1.0にあたってるところ以外は塗れないと思われる)。塗り残しができないかどうかもやってみないと分からないです。まあ、この辺の値を自動でどう決定するかですね。

いや本当にありがとうございました。ゴリマッチョさんのづほさんまだチェックしてない~

リボン続き

折角ペイントの確認までして頂いたのに、パソコンがす~るを動かして無くても固まるようになってしまい色々できません。NVIDIAのモニターで見る限りは気まずいほど高温になってるものは無いと思うのですが、去年も暑い時期は不安定になったのでいい加減マザーボードがお疲れなのかもしれません。

「女の子の帽子」のリボンですが、こちらのす~るver.5でペイントを試したところ全く塗れませんでした。(少々復活した時にどれ位復活したのか見る為にす~るを起動してみた。)よねすけさんはver.4で確認されたと思うのですが、どうもver.4とver.5では違う動作をするようです。

ミスマさんは私にあんな見事なGUIが作れると思ってるのでしょうか。なんか野越さんに申し訳ない…

Re: リボン続き

NVIDIAとWindowsはドライバ関連で相性が悪くて困り者です。前のPCの再インストールも毎回それで困っておりました。ゴリマッチョさんも相性悪かったようでAMDに変えてましたし。

3DVisionを機会があれば試そうと思っているのでNVIDIAにこだわってますが、機会が無いんですよね…。

ペイントですが、頭装備でしたのでver5で行いました。ver4用のボーンのリネームやってませんので。ペイントは、正面からだと塗れるのに、後ろからだと塗れませんでしたが、それではないですよね?

確認不足でした

リボンのペイントですが、こちらの確認不足でどうやら塗れていたようです。なんですが、ペイント画面では帽子の向きによってペイントした色で表示されたり元のテクスチャの色で表示されたりしました。多分前回は元の色で表示される方向から見て「色が付かないなあ」と判断したのだと思います。(ペイント自体はどこかをクリックすると全体に色が付くという感じでした。)

通常画面でのあのチラチラしたような表示は、向きによって塗った色で描画されたり地のテクスチャの色で描画されたりすることで起きているのではないのでしょうか?前回通常画面をちゃんと見ていれば変な風に塗れているのを確認できたのでしょうが、なにぶん固まるのが怖かったものでして(因みにす~るを閉じてしばらくしたら固まりました、その時は)。お騒がせしました。


PCは現在のところI/O関係のデバイスを2つほど無効にした(デバイスマネージャから)ところ安定しております。安定してスタンバイに落ちなくなった気もしますが。幸い自分のところではNVIDIAのドライバ由来と思われるトラブルに遭遇したことはない(と思う。ドライバはあまり更新しないので)のですが、I/O関連はUSBのものも含めて鬼門な気がします。割り込みやらウェイトやら色々あるのでしょうがないと言えばしょうがないのですが。

そう言えば以前USB接続のモデムを繋いだらTEATIMEのゲームが起動しなくなった(起ち上げるとすぐ「不正な~」が出て終了してしまう)ことがありました。モデムのドライバとかをアンインストールしたらゲームが出来るようになりましたので、ほぼ確実にUSBモデムが原因と思われます。いったい何がどう影響するとその様なことが起きますのやら…

Re: 確認不足でした

了解デース。
どちらが優先表示されるかはっきりしていない状態でテクスチャが複数被ると、たむたむす~るではあのようにチラついて見えるような感じですね。形状カスタムで複数のポリゴンの同士の距離を0に近づけるとよくあのようになります。ペイントレイヤーと下地のレイヤーの優先表示が上手くいっていないんじゃないでしょうかね。リッピングソフトで拾うと、テクスチャが二層になっているのが良くわかります。

NVIDIAの問題は以前ミスマさんも遭遇してましたが、Windowsが勝手にNVIDIAのドライバを独自のものにアップデートしてしまう問題で、PCがいきなりハングしたり落ちたります。OSインストール直後に拾ってくるドライバもこれのようなので、ドライバを完全に消去するツールを使って消し、正規のドライバを入れると安定します。普通に入れただけではダメなケースです。まあ、今まで安定していたのでしたら問題無いと思いますが、私もいつぞやの更新でOSに勝手にドライバを書き換えられたらしくて不安定になってました。そういえばミスマさんも去年の夏ごろだったような。

私も再インストールの際、TEATIMEのソフトを入れて起動する度に不安定になってたので心配になりましたw

境界処理の影響?

す~るが(多分ゲーム本体も)元のテクスチャとペイントレイヤーとでテクスチャを2層のまま保持してるというのは驚きです。てっきり合成してから貼り付けてるものと思ってましたから(自分なら多分そうする)。「どうせピクセルシェーダーは用意するのだからその中で合成すればいいや」と思ったのかはわかりませんが、それでもリアルタイムで2枚のテクスチャを合成しながら貼るよりは1枚だけ処理する方が軽いと思うのですけど。テクスチャキャッシュとかどの位の容量なのか知りませんが。

表示がチラチラする件ですが、mqo読み込みでも再現できるなら特殊効果にでも使えないかなと思って発生条件などを調べてみました。mqoアップローダーにあった学生鞄(1メッシュ構成)の全頂点のUV値を(0.0,0.0)、(0.0,1.0)、(0.5,0.5)にしたものをそれぞれ用意して、オリジナル剣の2に読み込ませるという簡単なものです。これらをす~る5のペイントで白く塗ってみたところ、結果は以下のようになりました。
 (0.0,0.0)→チラチラしないでただ真っ白
 (0.5,0.5)→チラチラしないでただ真っ白
 (0.0,1.0)→チラチラする
次に「じゃあペイントじゃなくて最初からテクスチャの左下隅が白かったらどうなんだ」と思い、テクスチャの左下を白く塗ってから(0.0,1.0)を表示させたところ、「黒」かった鞄の色が「グレー」になりました。(この元テクスチャを着色する場合とす~るのペイントで着色する場合とで結果が変わるというのも、テクスチャを2層で保持してることの証左の一つだと思います。)さらにペイントで白く塗ったところ今度はチラチラ表示に変わりました。

す~る4でも(0.0,1.0)の鞄mqoを読み込ませたところ、ペイントすると同じようにチラチラした表示になりました。カレカノのフリーH、FINAL!のフリーバトルでも確認できましたので、再現性は問題無いようです。

この間「UV値は 0.0≦U,V<1.0 の値をとるんじゃないか」と書きましたが、「0.0≦U,V≦1.0」が正しいようです。少なくとも通常は。何故自分が1.0側の等号を入れないと考えたかと言いますと、UV指定がテクスチャが1枚分で完結してればいいのですが、TEATIMEの3Dエンジンはテクスチャがタイル状に並べられてるものとして扱ってると思われるからです。1.0は次のテクスチャの0.0ということでもあるので、だったら最初から1.0という値は持たないと決めておいた方が面倒が無くて良いだろうということですね。

鞄の例でいいますと、UV値が(0.0,0.0)の時はピクセル座標(0,0)、(0.5,0.5)の時は同じく(255,255)(多分。尚kaban_01.bmpは512×512px)一点の色だけを見ればいいので、鞄全体の色が一意に決まってると思われます。UV値が(0.0,1.0)の時はピクセル座標(0,511)の色を採るのか2枚目の(0,0)のピクセルの色を採るのかが状況によって変わり、あのような表示になるのだと推測しました。(その状況判断をペイント画面ではメッシュ毎に行い、通常画面やゲーム画面ではピクセル毎に行ってるのでしょう。)尚、元テクスチャの座標(0,0)と(0,511)の2点で色が異なっても双方を合成したと思われる色で表示されただけだったので、状況によってどちらか一方の色で表示されるのはペイントレイヤーだけのようです。

因みにテクスチャをタイル状に並んでるものとして扱うモードはDirectXにちゃんと備わってるものだそうです。(www.c3.club.kyutech.ac.jp/gamewiki/index.php?%A5%C6%A5%AF%A5%B9%A5%C1%A5%E3%BA%C2%C9%B8参照。DirectXを使ったプログラムを書いたことがないので知りませんでした。)これを見た時「境界処理はどうしてるんだろ?」と考えましたが、先に書いたグレーになった鞄を見て「ああ、『適切に』処理してるんだな」と思いました。TEATIMEのエンジンもこのモードでテクスチャを処理してると思うのですが、境界(と言うよりペイントレイヤー?)の処理は違うようです。

あとUV値が(0.0,0.0)とか(0.0,1.0)の時のペイントデータも見てみましたが、隅っこを中心とした四分円状にペイントされており(範囲はブラシの範囲で変わる)、他の隅に回り込んだりとかはしてませんでした。まあ、回り込まれても困るんですが。

Re: 境界処理の影響?

いろいろと検証ごくろうさまです。

リッピングした場合、すべてのモデルが2重になり、片方は元のテクスチャ、片方はペイントされたテクスチャになります。リッピングの場合、たむ式メーカーと違い、す~るのスライダーをそのまま再現できるのでモデル自体のバランスが良いのですが、この二層のモデルの処理が面倒で諦めました。(視野角の問題もありますが)

元のテクスチャに2色の間の色が出ているというのは、元のテクスチャにはアンチエイリアスが効いているので中間色を拾っているのでしょうかね?もしかすると、1ドット左(0,511 黒)と(0,0 白)の境でアンチエイリアスが効いてグレー(完全に中間ではなく白よりとか?)になってるとか?

そういえばペイントレイヤーにはアンチエイリアスが効いていないというのも、実は2層表示用に部分的に透明化させてる(1か0かの透明ですし)ため、制限がかかっているのかもしれません。

画像ファイルは上下逆だった

UV座標及びす~るのペイントデータとも左上が(0,0)なのでそのつもりで書いてしまいましたが、bmp、tgaとも画像ファイルは左下が(0,0)でしたね。先程のコメント投稿は画像のピクセル座標も左上が(0,0)、右下が(511,511)のつもりでお読み下さい。(でもスクリーン座標系ってこっち方向で良かったよね?)

UV値(0.0,0.1)の頂点の色が(0,511)の色と(0,0)の色の中間になってるというのは、多分「どちらから色を拾ってくるのか決めようがないから中間をとろう」的な処理がDirectXに入ってるんじゃないかと。UVマップがちゃんと展開されていれば、1枚目から色を読み出すべきか2枚目からすべきかが決められるのでどちらかの色になるんじゃないかと思います(未確認)。ただ今回は全頂点のUVが同じ値なのでどちらを読むべきか決めようがないですから。エラーで止める訳にもいかないですし。

一応アンチエイリアス「なし」でもやってみましたが、グレーで表示されることは変わりませんでした。(す~る5の方は鞄のディテールがある程度判るのに対しす~る4の方はほぼ潰れた感じに描画されましたが、画質設定も全く同じではないです。)少なくとも通常のアンチエイリアスとは違うルートで色が決定されてるのだと思います。あと、チラつき表示はす~る5の方が変化が大きくて見てて面白いですね。

す~るのペイントデータは、塗られていない点の値が(01,01,01,00)となっています(リッピングではこの辺りのことも判るのでしょうか?)。確かBGRAの順です(因みにこれをライン単位で逆順にしてヘッダとフッタを付けるとtgaファイルになります)。一応αは値として持ってますが(ペイント結果も必ずしもFFではない)、合成の時にどう使われているのかはわかりません。リッピング結果のお話は、要するに1つの面(サーフェス)にテクスチャを合成しながら貼り付けてるのではなくてテクスチャを貼り付け終えた2つの面を合成してるということですよね(面は流石にコピーでしょうけど)。なんでそういう処理なのかちょっと見当がつかないですが(ペイント画面だけなら解らなくもない)、ペイントレイヤーにアンチエイリアスが掛からないのは両方に掛けると重すぎるとか計算量の割に効果が無いと思ったのかもしれません。単にペイントレイヤーの方は忘れられただけかもしれませんが。

mqoファイル

メタセコを少し動かしてみたのですが、もしかして全頂点のUV値を(0.0,1.0)に揃える簡単な方法って無いですか?だとするとチラつき表示を特殊効果として使うというのも難しいですね…

あと学生鞄のmqoファイルのUV値をいじったもの(含む未改変テクスチャ)を表のアップローダーに上げてもよろしいでしょうか?この30を超えるコメントを読んで実物が見たいと思う人がいないとも限らないので。

前回のコメントで面(サーフェス)がコピーだろうと書いたのは、二重になってる面の双方別々に頂点位置を計算することは流石にないだろう(一方だけ計算して他方はその頂点位置をコピー)という意味です。念のため。

Re: 画像ファイルは上下逆だった

リッピングのツールがどのようにポリゴンを拾ってくるのかはわかりませんが、ペイントできる部分はポリゴンが二層になってますね。

ちなみに、す~るのホーム画面をリッピングすると、モニターの画面枠?っぽい物が表示されます。そこを通して中の世界をのぞいているような感じで。こういうツール、詳しくないのでこんなものなのかどうなのか知りませんが。そして、NaNになった頂点は、この画面枠?あたりに伸びてきて1点(原点?)に集約されてます。オンボのグラフィックで線が画面端まで伸びて見えるというのはこのポリゴンの線だと思います。

それからカスタム画面をリッピングすると、すべて2D投影に変換されてしまいます。パースが無いためこのようになるのかどうかはわかりませんが。

あと、ポーズ編集でボーンを表示させると、ちゃんとボーンも拾ってくれます。実際にボーンにして使うには大変ですがw


メタセコの方はいつも勘で使っているのでよくわからないのですw 初めてウォーハンマーを作ったときからいくらも進歩してないのです、実はw

mqoいじった学生鞄、アップしてくださってもかまいませんよ~。私はちょっと確認できそうに無いですが、興味ある方がいらっしゃれば。

配布ご了承ありがとうございます

改変mqoの配布、ご了承頂きどうもありがとうございます。実は昨日UPした後変換スクリプトをJScriptか何かで書き直してUPし直そうかと思ったのですが、面倒になってやめました。WSHで動くものの書き方から始めなくてはならなかったので。中に入れておいた画像はアップローダーのサムネにしといた方が良かったですね。

カスタム画面をリッピングすると2D投影の画しか得られないというのは、DirectX的にアニメーションとは違うAPIを叩いて描画してるということではないでしょうか。す~る側で平面に投射するところまで行って、2Dの画をWindows側に渡してるのかもしれません。座標変換が無ければ計算もそんなに大変じゃないでしょうから。

延々とコメント欄だけ更新してたら広告出ちゃいましたね…

Re: 配布ご了承ありがとうございます

本当だ!広告とか出てたらあさはかさんに笑われるレベル!

よねぞんのコメ欄の続き

不具合情報ということで、よねぞんの記事「たむたむす~る 逆引きTIPS(FAQ)」のコメント欄の続きをこちらに書かせて頂きます。内容的にFAQから外れますし。

cloth_0200(女の子の服)で何かグシャッてなってると思い「胸の先端近くでポリゴンがひっくり返ってる」と書きましたが、元の形状がおかしいわけじゃなかったようです。体型スライダー(胸A、Bとも)に追従しない頂点がいくつかあって、その為に変な形になっていた模様(動かない頂点はショール以外にも)。

MORPチャンクをチェックしたところmorphデータとmeshとで頂点が正しく1:1で対応してないのが確認できました。頂点数は双方で一致してるので、対応関係を確認してインデクス情報を修正してやれば直ると思います。もしかすると、いくつかのポリゴンで2頂点がピッタリ重なってる影響でmorphデータに対応するmeshの頂点が見つけられなかったのかもしれません。

cloth_0700(みなも死神装束)でMVDファイルが妙だと書きましたが、これはcloth_0700に限ったことではないようです。例えば「wear_t0_L01」と「vwear_t0_L01」の様に片方の名前を完全に含むmesh名があった場合に、色々とおかしいMVDファイルが作られるようです(実はメカナース少女セットでも起きてました)。mesh名を変更してみたところ結構普通な感じのMVDファイルが作成されました。

なお「片方の名前を完全に含む」と書きましたが、確認したのは片方の名前の前に何かがくっ付いてるやつだけなので、頭が一緒で後ろに伸びてるやつはもしかしたら大丈夫なのかもしれません。が、未確認なので、読み込み用MQOファイルを作る時は避けた方が無難と思われます(MQO読み込みで作成されたODFファイルに対してもMVDファイルは作られるので)。

で、これが厄介なのは、MVDファイル作成ルーチンだけではなくどうやらす~るそのものがデータを正しく認識しなくなる点です。実はmesh名を変更したODFファイルを元にMVDファイルを作り、それをmesh名を戻したODFファイルと一緒に使ってみました。cloth_0700では形状かすたむでスカートの頂点が色々愉快な動きをしてくれるのが直ると思ったのですが、相変わらず意表を突いた動きをしてくれます。挙げ句、す~るは停止。MVDファイルには離れた頂点を一緒に扱うような情報が記録されていないので、形状かすたむのルーチンと言いますか、す~るのODF読み込みルーチン自体が誤認識を起こしてるものと思われます。

ODFファイルのmesh名を変更して対応するのが楽なのですが、これをやるとそのアイテムを使ったALPが使えなくなるので、す~るのプログラム側で対応するしかなさそうです。まあ、無理ですね…

あと修正MVDファイルについて。先のコメントにも書きましたが、MVDファイルの最初の8バイトは対応するODFファイルの更新日時でした(かすたむデータファイルの方は4バイトの値なので今まで気付きませなんだ)。で、この値が実際のODFファイルの更新日時と違っていると新しくMVDファイルを作ろうとするようです。

で、このODFファイルの更新日時ですが、これはファイルシステムに書き込まれているものなので本当に全て環境で一致してるものとして扱っていいのかが私には判りません。一旦FATファイルシステムのドライブにコピーしてから戻したりすると変わってしまいますし。zipファイル経由でも同じことが起こり得る(拡張ヘッダを扱えないソフトとかの場合)ので、バックアップから戻した環境だとODFファイルの更新日時が微妙に変わってるかもしれません。タイムスタンプが変わっていると、修正したMVDファイルがあってもアイテムを読み込んだ時にまた上書きされてしまいます。

ということで上書きされた時の対応ですが、ゲームのフォルダにあるMVDファイルの先頭8バイトを修正ファイルの先頭8バイトに上書きコピーしてやれば回避できます。要バイナリエディタなので万人向けではないですが。

しかし、cloth_0200にしろcloth_0700にしろノーマルマップを使っていたりしてこねる素材としては微妙な存在だと思うので、修正してもありがたく思う人少ないだろうなあ…。mesh名の問題の方はcloth_0700に留まりませんが、他に影響があるのかはまだ不明です(メカナース少女セットは確定)。

追加情報

先のコメント(まだ読めないですが)で書いたmesh名の問題です~るの動作がおかしくなる件ですが、どうやらcloth_0700(みなも死神装束)以外は問題無いようです。mesh名を全部チェックした訳じゃないのですが、問題の有りそうなMVDファイルが他に無かったのでそう判断しました。「『みなも死神装束』を使うとす~るに問題が起きる可能性が高いです」で済みそうです。あとはMQO読み込みアイテムを作る時にmesh名に気をつけるのと。

ちょっと思ったのですが、MQO読み込みのアイテムはmesh名の後ろに「_00」が付けられますけど、チェックする人が問題に気付いてて連番付けて回避するために「mesh名の後ろに00みたいな番号付けて」と言ったらプログラム書く人が全部に「_00」を付けるコードを書いた訳では…

cloth_0200の修正MVDファイルですが、これに入れ替えて形状かすたむしてから元のMVDファイルに戻すと形が変わってしまうようです。一度ALPに書き出してしまえば動きは変としても形だけは保つかと期待したのですが、ダメでした。ということでMVDファイルだけ配布してもあまり意味なさそうです。MORPチャンクを修正することでMVDファイルも直ることに期待します。

あとMVDファイルで指定された頂点の組ですが、殆どの値がきっちり揃っていました。本来一緒に動くべきでないのに指定されていることが疑われるデータは

cloth_80010(パティシエメイド)の
0.0004: Wear_052_t1_Bust_R の頂点191(-1.3719, 17.9531, -0.4899)と頂点647(-1.3722, 17.9528, -0.4898)
0.0016: Wear_052_t1_top_R の頂点201(-1.2447, 18.4641, -0.5688)と頂点231(-1.2454, 18.4655, -0.5690)
0.0016: Wear_052_t1_top_L の頂点82(1.2447, 18.4641, -0.5688)と頂点133(1.2454, 18.4655, -0.5690)

cloth_jac_goodwill(私立学園ブレザー)の
0.0003: Wear_103_t1_top_ERI_R の頂点230(-0.0011, 18.3526, -1.3999)とWear_103_t1_Bust_R の頂点296(-0.0009, 18.3525, -1.3999)
0.0003: Wear_103_t1_top_ERI_L の頂点287(0.0011, 18.3526, -1.3999)とWear_103_t1_Bust_L の頂点228(0.0009, 18.3525, -1.3999)

だけでした。どの辺りの頂点なのかはまだ全然チェックしていません。正しく指定されている可能性も十分にあります。

Re: 追加情報

うわ、すみません。また広告出てましたね。

元記事のコメントの方も含めて返信ですが、2つの頂点がまとめて動いてしまうというのは、のぞく人さんの10/21のコメントの通りです。ただ、片方を非選択にしてもう片方を動かすと、実は分けて動かせたりするものもある(確かスカートのどれか)んで、普通にカスタムできるように見えてしまうんですよね。実際は、カスタムを抜けた途端、くっついてしまうんですけどw


あと、改の方のコメントですが、死神装束かなにかのショール系で、以前、ウエイトがおかしいので近くの頂点からENVLを写してきてそれっぽくodfを修正したことがありますね(詳しい内容は忘れましたが)。あのファイルどこにやったかな…。

mvdについては、odfも含めてしばらく触ってなかったので頭がついていきませんスミマセン…。

検証結果の追加

MVDファイル(たむたむストレージで頂いた情報によると“Merge Vertices Data”の意味だそうです)はす~るが「この頂点とこの頂点を一緒に動かそう」と判断した結果を書き込んだファイルとでも言いましょうか。“頂点aの属するmeshのインデクス,頂点aの頂点インデクス,頂点bの属するmeshのインデクス,頂点bの頂点インデクス”という4つの値で1エントリーを構成して、ひたすらこれが並んでいるファイルです。嫁こさんのアップローダーに説明を書いたメモ書きが上がってますが、これ以上のことは特に書いてないです。

先によねぞん画像掲示板(yonezon.coresv.com/joyful/joyful.cgi?res%3A447=%95%D4%90M)の方に書いちゃいましたが、上で挙げたcloth_80010(パティシエメイド)とcloth_jac_goodwill(私立学園ブレザー)の座標が微妙に異なる頂点の組は一緒に動くものとして扱うのが適切なようです。ということで、見つけられた「不適切に一緒に動く頂点」はcloth_0200(女の子の服)とcloth_0700(みなも死神装束)のものだけでした。まだ他に切り口が有るのかもしれませんが、探すのは一旦終了します。cloth_0200が修正できるかちゃんと見ないといけないですし。

話は全然変わりますが、Soldatさんがtweetしてたまつ毛MODってヘッドのODFファイルの瞼あたりをベースにすると出来るかなあとかちょっと思ったんですが、どうですかねえ…。まあ、用意するモーフデータがかなりの量なのでやるかと訊かれればやらないと答えますが。頭装備として考えたんですが、MORPチャンクのデータを揃えておいたところで果たしてアイテムまで「ヘッドをこういう風にモーフさせるよ」の指令が届くのかどうかが謎です。そこがOKなら「やれば出来る」ということになるのですが、やっぱり動かないだろうなあ…


私は、ODFファイルに対する勘は結構取り戻せてきた気がします。でも“過去のオレ”に頼りっぱなし。

そう言えば広告が出てる時はコメントが承認待ちになるんでしたっけ?すっかり忘れてました。

Re: 検証結果の追加

mvdで判断してるんですか。じゃあ、生成時に、隣接点がある程度の距離以下のはまとめてmvdで処理したりとかなんですかね。

まつ毛の件は私もちょっと考えはしましたけど、頂点モーフがありますからね…。頂点モーフは、ボディの方は体型モーフとかをちゃんと反映しているので、顔も他に合わせて変形するのかもしれませんけど、とにかく顔はモーフの量が多いですからね…。ちょっと実験するにもたいへんそうですね。

まつげを弄れるなら、咲姫のまつ毛をまず修正したい…。目を閉じたときのモーフが何故か心愛と一緒なので。

Re:Re: 検証結果の追加

実際にプログラムの流れを追った訳でもないし相変わらずDirectXの勉強もしてないので、MVDファイルの内容を処理のどの段階で反映させてるのか分かってないです。まあ多分、連続するポリゴンは複数meshにまたがっていても先に連結してから描画に回すと思うのですが、その時境界線に乗ってる頂点にこっちのmeshとあっちのmeshとで違うインデクスが付いてるけど同じものだよってのを示すのが、MVDファイルのそもそもの役割なんだろうと思います。

距離以外でも頂点ウェイトなんかは見ていると思われます。他にもチェック項目が有るかもしれません。距離も、例えばcloth_jac_goodwill_imp.ODFのWear_103_t1_top_ERI_Lでは(0.0000, 18.3474, 1.4040)の頂点と(0.0011, 18.3526, 1.3999)の頂点が別のものとして扱われてますから、余程近くでない限りは距離だけみて1つの頂点として扱おうということにはならないかと思います。

ただ、それはODFファイルのデータに不備が無い場合であって、す~るで読んで表示可能な範囲のエラーであってもMVDファイルの作成ルーチンに影響が及ぶようです。cloth_0700ではmesh名に問題がありますが、6近く距離が離れた頂点同士が指定されたエントリーがあったりします。

ちょっと補足

上で書いてることを少々言い換えますと、MVDファイルはDirect3Dに渡す頂点バッファを構成する時の参照用に有ったんじゃないかということです。ただ一緒に動く頂点では明らかに頂点バッファに別の値が書き込まれていますから、どこかで使い途が拡張されて動きの補正に使われるようになったんじゃないかと。

ところで、まつ毛MODって心愛・咲姫ヘッド以外にmesh“T_LINE”(睫毛のmeshですね)の代わりを追加しようってものかと思ったんですが、その認識で合ってます?

Re: ちょっと補足

まつ毛MODは発言者の人的にはどうなんでしょうね?
私は心愛・咲姫ヘッドのまつ毛をオリジナルのものに交換した方が助かりますけど。

cloth_0200続き

cloth_0200_imp.ODFのMORPチャンクを修正すべくデータを見ておりましたが、何がおかしいか判別できたと思うのでご報告までに。

まず問題が有るmeshは「wear_t1_bust_L」(ショールの方)と「wear_t0_bust」(本体の方)だけのようです。頂点数の突き合わせと頂点morph情報へのマッピングのチェックしかしてないですが(他に何か出てきたらその時はその時ということで)。

wear_t1_bust_Lですが、親meshの頂点とmorph情報の頂点とのマッピングが一部おかしくなってるだけのようです。morphのnormal形状と親meshとで頂点数も座標も一致するので、マッピング情報を修正してやれば済みそうです。

少々補足しておきますと、MORPチャンクには頂点モーフの形状データが格納されているのですが(頂点モーフだけです。体型スライダーでの変形や瞬きや表情変化等に使用。四肢スライダーは別)、これの頂点順は親meshの頂点の順序と大抵一致しません。なのでMORPチャンクのデータにはmeshのどの頂点がmorphのどの頂点と対応するかのマッピング情報が含まれています。

話を戻しまして、wear_t0_bustはもう少し複雑です。以前meshに全く重なってる頂点があると書きましたが、これらの片方がmorph情報にマップされていません。morphデータ側は重なってる頂点の数の分だけ別の位置に頂点が増えています。逆から見るとmorphデータの増えた頂点にマップすべき頂点が親mesh側に有りません。(親meshのマップされてない頂点のうちmorphに対応頂点が存在する頂点も少々ありますが、ここでは省略。)

修正方針として「親meshの頂点をmorphに合わせて増やす」「morphの増えた頂点は無かったことにして、親meshで重なってる頂点はmorphでも重ねる」の2つが浮かんだのですが、前者を採用すると“data\EditData\DefEdit\nanami.alp”を読んだ時に問題が出る可能性大なので具合が良くありません。ということで後者を採ることとして、morph情報のどの辺りに重複頂点の座標を突っ込むと良さそうかこれから検討します。


ところでまつ毛MODですが、取り敢えず頭アイテムとしてヘッドのODFファイルをそのまま読ませたところす~るが落ちました。もうちょっと要らないところを削ったのだとまた違うのかもしれませんが。ヘッドのMORPチャンクには通常のアイテムでは使ってない部分も使われてるので、やっぱり落ちるのかもしれません。

勘違い判明

「一緒に動く頂点」はまだありそうです。先に「実際に描画されている形状はMESHチャンクの頂点座標に基づいたものではなく、MORPチャンクのmorphデータの座標に因っている」旨を書きました。また「meshで完全に重なってる頂点が結構ある」とも書きました。さらに、MESHチャンクでは頂点が重なっていても、morphデータでは重なった分を他所に置いているのが分かってきました。これらを合わせて考えますと、MVDファイルで重なった頂点を1つの頂点として扱う指定がなされていても、実際に描画される時はその2頂点は離れた場所に描画される訳です。

実際には重なった2頂点のうち片方はmorphデータにマッピングされてないのが殆ど(全て?)なのでMVDファイルの指定が直接適用されてるのではないのでしょうが、それでもどれかの頂点を引っ掴んで動かすものと思われます。ということで、重複頂点を持つことが判明してる「cloth_0300」「cloth_1001」「cloth_1507」「cloth_620000」「cloth_x2010」は一緒に動く頂点の組を持ってる可能性があります。

cloth_0200以外にもmorphへのマッピングに問題があるものがそれなりにあるようなので(上のも殆どそうです)、取り敢えずはマッピングデータを全部チェックする必要がありそうです。修正ファイル増えるな…

なかなか上がらない

3週間ほど音沙汰なしになってしまってますが、cloth_0200(女の子の服)の修正は進めています。ゆるゆるやっていたり時間が取れなかったりで遅くなっているだけです。wear_t1_bust_L(ショールの方)の修正は終わっています。

まあ待ってる人も居ないと思いますが、一応うやむやにはなってませんよ(今のところは)ということで。

cloth_x2010(サンタ服2011)も何かガチャガチャなのでクリスマスシーズンの前に修正したいところ。

Re: なかなか上がらない

こちらこそほったらかしですみません…。
ショール関係はかなり初期の頃から苦言を呈しておられていた方を何度か見かけたので、喜ぶ人が多いと思います。(最初はななほうさんだったかな?)
のぞく人さんが体調崩されたりしてなければ万事おkです。

それはそうと、不具合関係のファイルのリンクもまとめておかないといけませんね。

非公式(勝手に)修正ファイル

お気遣いどうもありがとうございます。まあ大きく体調を損なうことは無いんですが、自分が歳食ったと実感することはありますねー。

ファイルのリンクをまとめるとのことですが、こちらで把握してる修正ファイルとかデータ修正ツールとかを書きだした方が良いでしょうか?あ、でも他人様のでパッと思い浮かぶやつ無いな…

出雲さんのクリスマスコスはチェック用に有り難く使わせてもらおうと思います。何かいいタイミング。
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。