よねぞん画像掲示板

今更ながら気づいたのですが
衣装で四角変形で頂点を消しても読んで動作するということは、
ボディも頂点数（ポリゴン数）を増減しても読んで動作するんじゃないかということで試しにメタセコでボディにナイフ機能で面を増やして（四角面を三角面にして）みました。
ちゃんと動作します。
実際には面の増やし方は一面ずつ成型が必要でしょうが、これでボディのどこでももっと細かく作りこみたいなと思うところが作りこめるということがわかりました。
これであと10年はたむたむで戦えそうです。
モーフ仕込めてくぱぁができればもうあと100年は戦えるんですが……
0

Re: ポリゴン数増やせる - のぞく人 2020/06/21(Sun) 16:29 No.843
何か勘違いしていたらごめんなさい。また気付くのが遅れたのでずいぶん遅い返信となってしまいました。

残念ですが、頂点数の増減があると色々と問題が生じます。

す〜るの動作自体はODFファイルがフォーマットに則ってさえいればOKなので、ボディのODFファイルを別のものに差し替えることもできます。が、既存のALPファイルをその通りに再現することができません。ヘッドやアイテムのかすたむ結果を引き継ぐことはできるので(ボディもスライダーの値は引き継げると思う)、ボディのかすたむ結果を捨てて新しいボディで行くというのも一つの考えとは思います。

ALP読み込み時の影響ですが、今ちょっと確認できないので記憶を元に書かせて頂きます。確か、ALPに記録されている頂点数と対応するODFのメッシュの頂点数が異なる時はALPに記録されたかすたむ内容が無視されたと思います。ペイントは確かめたことがなかった気がしますが、形状かすたむの方は無視だと思います。藻消しボディで胸のあたりが大きく崩れる件があったので、ちゃんと確認しないと何とも言えませんが。とにかく問題は出ます。

確かゲームに付属するeir.alpだったと思うのですが、服か何かにODFのメッシュの頂点数とALPの頂点かすたむデータの頂点数が一致してない箇所があります。それでも読み込まれた時に問題が有るように見えないというのが「無視」と判断した根拠です(記憶だけなので根拠弱いですね)。このALPの場合デフォルト形状なので、部分的に変形してないメッシュが混ざっていても見た目に問題は起きません(ALP2PMXで変換が上手くいかなくてデータがおかしいと分かった)。スライダーの値もちゃんと反映されますし。
Re: ポリゴン数増やせる - のぞく人 2020/06/21(Sun) 17:05 No.844
続きです。

ALPの互換性以外に、ODFファイルのメッシュを差し替える時にモーフデータの一部に問題が起きると思われます。

以下メッシュ差し替え時にODF(神ツールの方)を使用することを前提にしています。別のツールや完全手作業の場合は当てはまりません。あとずいぶん前の記憶に基づいているので違っていたらごめんなさい。

ODF(神ツール)には様々なモーフ編集機能がありますが、扱えるモーフデータは「normal」と「変形状態」の2つの状態しか持たないものに限られていたと記憶します。ボディのODFファイルのモーフも大体は当てはまるのですが、「ぽっちゃり」モーフは「細い側の変形状態」「normal」「太い側の変形状態」の3状態のモーフデータになっています。それぞれスライダー値で言うと50、100、150に相当するデータです(形状データとしては更に60相当と思われるものも持っているが使用されていない)。

ツールで3状態のモーフが作成できないと、ぽっちゃりスライダーを動かした時の変形の仕方がメッシュを差し替えた部分だけ違うので、周りのメッシュとの間に段差ができてしまいます。かと言ってモーフデータに手を付けないと、メッシュの頂点数とモーフの頂点数に違いができてしまいます。これを吸収する手立てはありますが、ODF(神ツール)では編集できない部分だったはずです。

ボディ全体を2状態のモーフデータに差し替えてしまうという手もありますが、ぽっちゃりスライダーの分だけとは言え結構な作業量ですし、既存の服データの中にはそれだと困るものも小数ながらあると思われます。

モーフデータに関してはそんな感じです。
Re: ポリゴン数増やせる - のぞく人 2020/06/21(Sun) 17:53 No.845
以下技術的説明です。

す〜るで行う「頂点削除」ですが、これは描画されるポリゴン数は確かに減るのですが、元のODFファイルのメッシュには何の影響も与えません。

ALPというか形状かすたむデータの中身ですが、これは移動後の頂点座標とその頂点の法線ベクトルがひたすら並んだものになります。面の構成情報を始めとするその他の情報は元のODFファイルのものをそのまま使用します。ODFとALPで頂点数や順序が一致していることを前提としています。

画像はALPファイルの圧縮部分を展開したものをバイナリエディタで見たものです(ALPは性人さんのものを使わせて頂きました)。Posというラベルが付いた行が頂点座標で、NVというラベルが法線ベクトルになります。上で書いたように座標と法線の値が並んでいる様子が分かるかと思います。

画像中で並んでいるデータの中に、“FFC00000”というものが幾つもあります。これはNaN(not a numberの略)と呼ばれる特殊な値で、「数値でないもの」を表しています。座標に「数値でない」値が入っている場合コンピュータがどう反応するかですが、DirectXの場合その様な頂点は描画されません(と言うか本当はそういう頂点を描画パイプラインに入れてはいけない)。す〜るで四角変形の結果頂点が消えるのはこういう仕組みに因ります。

す〜る側の操作で頂点を消していると言うよりは、表示できないデータをGPU側で消すという動作になっています。Intel製CPUの内蔵GPUの頂点シェーダはこのNaNを含む頂点座標を(0,0,0)に置き換えてしまうので、その結果ポリゴン伸びが起きます(描画パイプラインに直接放り込まれた(NaN,NaN,NaN)は描画されないです)。

四角変形で値が無限小とかではなくNaNになるのは意図された動作なのかたまたまなのか、そこまではちょっと判断つかないです。まあ、これによってす〜るのかすたむの幅が広がったのは確かなので。

画像中には座標は具体的な値が入っていて法線ベクトルだけ値がNaNになっている頂点もありますが、す〜る上ではこれらも表示されます。描画する時の法線の値をODFファイルから引っ張ってくるのか単純に周りの面から計算するのかよく分かりませんが、消えずに残ります。

尚、画像中の説明に「頂点と座標の値がNaN」とあるのは「座標と法線の値がNaN」の誤りです。


以上です。長文、連投失礼。

Re: ポリゴン数増やせる - yomeko2905 2020/06/28(Sun) 22:08 No.846
アドバイスありがとうございます。

>藻消しボディで胸のあたりが大きく崩れる件があったので、ちゃんと確認しないと何とも言えませんが。とにかく問題は出ます。
そういえば藻消しボディだとスカートが崩れる衣装もありましたね。
らぶデス２のcosmodeだと頂点数が変わると異常終了するというのを見たことがあってボディの頂点数を変えられないと思い込んでいたのですが、とりあえずヌード時に性器部分だけでも高精細にできればいいと思っていたのでこれは使えると思ってしまいました。
odfをmqo出力するとたくさんのメッシュに分割されてますが
一つのメッシュ内ならどうなのかメッシュをまたがったらどうなのかというのは時間ができたら実験してみたいと思います。

「問題」を強調しすぎたかも - のぞく人 2020/06/30(Tue) 00:43 No.847
久しぶりにcosmodeの見本画像見てみましたが、改めてスゴイですね。す〜る無しでこれだけのものが作られていたというのがまた…。

当時は改造データやコミュニティの存在を知らなかったのでどんなやり取りがなされていたのかわかりませんが(改造板のログは読んだかもしれない)、「頂点数を変えると異常終了する」というのは「必要な変更が全部行われてなくて、ODFファイルとしてどこか壊れてしまった」ということなんだと思います。多分(その場に居合わせた上での判断ではないです)。

まだ神ツールが無かった頃ですし、TTToolも公開されてなかったはずなので(手元にあるやつの日付を見る限り)ツール作者の間でもODFファイルのフォーマットを全体的に把握してる方は少なかったんじゃないかと推測します。実際、自分が改造板を見るようになって「ODFフォーマット全体の説明ってどこかにあるの？」と強く思いました。

で、す〜るの話なんですが、ODFファイルとしての要件とボディのファイルとしての要件(ボーンやスライダーに関するモーフの要件)を満たしていれば、部分的に改造したファイルだろうと全く新規のファイルだろうと何でもOKのはずです。ただ、「今あるボディのファイルを改造してしまうとそれを使った既存のALPを読む際に支障が出る」ということと「ボディとしての要件を全部満たそうとすると神ツール(ODF)だけでは間に合わない」ということです。

新しいボディを(例えば)ボディNのように新規に登録する、ということが自由にできるといいのですが、す〜るver.5でもできたかな？登録自体はできるのですが、UIから選択する時に選べないという事態が発生したりします。改造板のログ見れば実験結果あるかも。

ボディAとCはメッシュ数、メッシュ名、頂点数、面情報全てに於いて同じだったはずなので、どちらか一方を潰すというのも一つの手です。既存ALPを読む場合はボディの情報の所だけ(TSXBINとかで)書き換えてやれば、そのままもう一方のボディで読めると思います(す〜る上でボディ変更した時もかすたむ結果全部引き継がれましたっけ？)。

この辺り？ - のぞく人 2020/06/30(Tue) 02:07 No.848
メッシュの頂点数を増やした時にどこに波及するかも考えてみました。

まずはMESHチャンクです。そのメッシュ自体の情報、頂点数や座標や法線や面情報などはODF(神ツール)が適切に処理してくれるはずです。ただ頂点情報の中にあるウェイト情報と対象ボーンのindexに関しては、ENVLチャンクがこの時点で変更されていないので、情報の食い違いが起きる可能性があります(対象ボーンのindexの方は食い違いは多分起きない)。ウェイト情報の食い違いが原因でエラーが起きるところまで行くかどうかは、実験したことがないのでよくわかりません。

次にMORPチャンクです。メッシュの頂点数が変わると、関連するモーフデータも増えた頂点数に合わせて全部書き換えるのが原則と思います。モーフデータの中に「メッシュの頂点とモーフの頂点を紐付けるマップ」があるので、そこを編集すれば「メッシュの頂点は増えたけどモーフの頂点はそのまま」ということも可能ですが(着替えアイテムには両者で頂点数が一致しないケースがそれなりにある)、す〜るの動作的には「モーフデータが存在する時にはメッシュではなくモーフの形状を用いて描画する」ということのようなので(ヘッドや着替えアイテムはそうなっている)、MESHチャンク内のデータだけ頂点を増やしても甲斐がないと思われます。あと、このマップの編集は神ツールではできません。

モーフデータですが、あそこあたりを書き換えたいかなーということになると、Fat_A(ぽっちゃり)、Fat_C(ウエスト)、Nin_A(ぽっこり)といったモーフデータが必要になります(この掲示板の505からのスレッド(http://yonezon.coresv.com/joyful/joyful.cgi?res%3A505=%95%D4%90M)も参考にして下さい)。2状態のモーフデータに関してはその内2つ(形状データは3つ必要)はメッシュの形状そのままでいいので、あとは最大変形時の形状を用意します。Fat_Aは3状態のモーフなので、痩せている側の形状と太っている側の形状データを用意します。形状データの用意は神ツールに既存の形状に合わせてメッシュを変形させる機能があったはずなのでそれを応用できると思いますが、3状態の形状データをMORPチャンクに突っ込む(置き換える)ことが神ツールではできなかったいう記憶があります(思い違いだったらごめんなさい)。

後はENVLチャンクに影響が出ると思います。ENVLチャンクには頂点ウェイトの情報が書いてありますが、極端な話ここは修正しなくてもエラーが起きることはないと思います。ただ、メッシュが変更されればウェイト情報で使われている頂点indexが指す頂点も当然変わってくるので、想定外の頂点があらぬ動きをするということになります。なので修正は必須かと。神ツールを駆使すれば修正できそうな気がします(実際にやった訳ではないので、やってみるとどこかで詰まるかも)。

ENVLチャンクで値の修正が起きた頂点は本来MESHチャンクの頂点データに修正値を書き戻す必要があります。が、神ツールがこれをやってくれるのかがよくわかりません。ここの齟齬が原因でエラーに至るかは不明と上に書きましたが、同時にENVLチャンクの値とMESHチャンクの値のどちらが優先して使われるのかも分かりません。MESHチャンクの値の方が優先されるとすると、個々の(MESHチャンクの)頂点データへの書き戻しは必須ということになります。でもこれ、手でやるとなると結構…

取り敢えずこの3つのチャンクについて書き得ればいいのではと思います。FRAMチャンクやANIMチャンクとかはそのままでOKかと。

余談ですが、手作業でやる時に面倒なのは変更後のチャンクサイズの計算かなあと。神ツールは有り難いです。

ODFと食い違うALP - のぞく人 2020/06/30(Tue) 23:51 No.849
最初の返信(843)に書いたeir.alpの件ですが、当時のメモが見つかったので補足を。ゲーム付属のALPファイルでALPの情報と着替えアイテムの状況に差違があったのはeir.alpとrota.alpでした。

eir.alpは女騎士装衣(105200,cloth_0000)のメッシュ数が違う(ALPの方が1つ少ない)、相互に相手側に存在しないメッシュ名がある、メッシュ名が一致していても頂点数が違う(頂点数が一致するメッシュもある)といった食い違いがあります。また女騎士のスカート(105530,skirt_0000)はメッシュ数、メッシュ名は一致するものの、頂点数は全て異なります。

rota.alpは魔導士法衣(105201,cloth_0100)のメッシュ数が違う(ALPが2つ多い)、ALPにしか存在しないメッシュ名があるといった食い違いがあります。また魔導士スカート(105531,skirt_0100)ではメッシュ数が違う(ALPが8つ多い)、相互に相手側に存在しないメッシュ名があるといった食い違いがあります。頂点数は両アイテムとも確認しておりません。

こういう状況ですが、eir.alpもrota.alpもゲームで読み込まれて問題が起きることはありません。ALPと実際のアイテムの状況が異なる時はALPのかすたむデータを無視していると思われます。

ただそうだとすると、藻消しボディで問題が起きる理屈がよく分からないんですよね。ボディとアイテムとで扱いが違うとかあるのかなあ…


らぶデス2の頃のODFファイルフォーマットの解析状況ですが、海外勢のことを忘れておりました。もしかしたらあちらでは解析結果が出揃っていたのかもしれません。でもあちらのサイトに情報を漁りに行ったことがないので、自分としてはよく分からないのでした。

Re: ポリゴン数増やせる - yomeko2905 2020/07/04(Sat) 22:04 No.851
>らぶデス2の頃のODFファイルフォーマットの解析状況

www.chadoki.netのスレに解析スレがあってそこでMESHチャンクなどの解析経過等が書かれてましたし、アニメーションの解析している最中の画像も貼られていました。
cosmodeだけでなくアニメもいじれるようになるのかと期待していたのですが、3以降モーフ導入などで仕様がどんどん変更されて追いつけなくなったように記憶しています。
その後たむたむすーるでキャラだけでなくモーションもカスタムできるようになりらぶギアで本編内でカスタムしたキャラとモーションを使えるようになりすっかり忘れていたのですが、今となってはスレの内容を保存しとけばよかったかなと…

自分もプログラミングはかじったことはあるのですが、3Dのフォーマットになるとお手上げで、http://uppervolta-3d.net/でのODFConvertorなどを見てはうらやましく思っているのです.

Re: ポリゴン数増やせる - のぞく人 2020/07/07(Tue) 00:34 No.852
「改造に関する情報スレ」のhtmlだけ見つかったので、よねぞんアップローダーに置いておきます。どうも読めなくなる可能性とか考えなかったようで、画像は保存していません。

あのスレを読んだ当時の感想は
「参考になる。が、色々足りない。後は自分で何とかするか」
だったのですが、今の目で改めて見ると参考になりそうなことがまだまだ詰まっている気もします。特にアニメ周りとか。

それにしても当時配布されていたらしいソースコード類を入手できなかったのは残念です。ソースが公開されていなかったツールで今でもソースが見たいものもありますし。特にODFCや(時期は下りますが)神ツールはあんなことやこんなことをどの様に処理しているのかとっても気になります。


ODFファイルのモーフデータを含めたメッシュの入れ替えですが、神ツールの[Mqo入力]でメッシュ・モーフ一括で入るみたいです。Twitterを読み返していたらありました。形状データを予め全部組んでおく必要がありますが、手間としては楽そうです。ODFCはメッシュの頂点数が増えた時にENVLチャンクの再構築もやってくれたようなので、神ツールもそうだと更に助かります。

Re: ポリゴン数増やせる - yomeko2905 2020/07/08(Wed) 00:37 No.853
>「改造に関する情報スレ」のhtmlだけ見つかったので、よねぞんアップローダーに置いておきます。

ありがとうございます。

6811さんへの返答の範疇を超えると思うので別スレッドで。

ALP2PMXを使った方法以外でテストしてみた時の画像です。何れも右側の心愛さんは6811さんから頂いたサンプル�@のボディAを、左側はボディCを使用しています。

一番上は827の書き込みと同じ画像でボディCはデフォルトのままです。

真ん中はファイルRT_body_type_C.ODFのFRAMチャンク内、ボーン名Frame_2_RT_base_Layer1_Pivotのボーン名と行列データをいじったものです。行列の回転部分の数値を1.0から0.84(サンプル�@のODFファイルのものと同じ)に変更し、ボーン名は後ろに“#Modified”を追加しています。

一番下は、832の書き込みに書いた透過好きさんがモーションアップローダー273として公開されている「縮小POS.zip」の中から「0.9倍ボーン.pos」を利用したものです。正直POSファイルの利用の仕方をまだ把握しきれてないのですが、まあなんとか縮小できてるように見えます(本当はまだ問題抱えてるのですが、静止画だと分かりません)。RT_body_type_C.ODFはオリジナルのものです。

取り敢えず画像のみで。
0

Re: サイズ変更テスト - 6811 2019/09/15(Sun) 21:43 No.838
せっかくご紹介いただいたので、透過好き様がモーションアップローダーで公開されているファイル
(http://yonezon.coresv.com/joyful4/joyful.cgi?read=273)を使用させていただき、HAN作って
FINALフリーH上で動かしてみました。HANでPOS利用の類似ケースを辿ると、
男をでかくするパターンでたいぞう様がモーションアップローダーで公開されています。
(http://yonezon.coresv.com/joyful4/joyful.cgi?read=241)

このSSはここ用にワンシーン作って全コマコピペした物です。3Pの3P-Fェラです。
のぞく人様の書かれたとおり、[Aボディだけを縮小化]のスレッドで私がやろうとしていた事と
同じ事が全ボディで可能です。

先に許可を仰ぐべきだったかも知れません。yomeko様に[Aボディだけを縮小化]のスレッドの
リンクを貼らせていただきました。事後報告になってしまい、大変申し訳ありません。

たむたむす〜るで長さを膝丈に長くした[英国っ娘スカート]が、長くした分だけ原寸で伸びる
珍現象を確認しました。FINALフリーH上限定で起きます。シャツをワンピ化したり、
長くする変形は良くやるのですが、他のは通常通りに縮みます。
「本当はまだ問題抱えてるのですが〜」の件も作業してみると把握できますね。

---Aボディだけを縮小化してしまう方法---
前列真ん中の3名と後ろのモンスター肩乗り3名全6名だけがAボディです。
歴代らぶデスキャラは原寸保持のままAボディからCボディに変更、サキュバス
はそのまま、モンスターはたむたむH編集時の寸尺の状況で撮ったSSです。
今回の方法が既出でしたらスミマセン。

---やってみたALP2PMX縮小寸---
ALP2PMX固有機能の等身伸縮という項目を試してみました。
ど素人ながらも出力されたフォルダの中に [base_body_A] という
かつて中身を弄った事のあるフォルダがあるのを見つけました。
このフォルダを弄った事の無い者だけが罪人に石を投げなさいという
あれですね。という事はAボディ全部に適用が及ぶのか……個体別は無理そう。

�@まずお手持ちのAボディ使用のALPをひとつ用意して、ALP2PMXで読み込みを
実行させます。動作確認的な意味でこちらでもサンプルを用意しますが、
お手元の環境を全て引き継がせるには各自の環境下にあるALP使用が最良です。
できればお手元の環境下で一度以上更新履歴のあるALPを使用して下さい。

�A開くのボタンから行くと、下部[ファイル名]のマス目に[xxxx.alp]と
フルネームでコピペ入力しないとALP2PMXは読み込んでくれません。
下半分の左側に等身の項目があります。以下は偶々上手く行った数値を
書きます。

�Bチェックマークは全部入れたままで、左の数値入力を上から
114、0.72、0.72、0.72、0.21、と埋めます。
�CALP→ODFボタンで出力させます。
出力後に表記数値が変化してる場合がありますが、特に留意は不要です。

同じ数値を打って出力させたのに、たむたむす〜るを起動すると縮小が
実行されていない事態は数度経験しました。逆に一度通用したものは何度
でも通るようで、途中から縮小しなくなる事態には遭遇していません。
縮小は起きるか否かの2択のように見えます。今の所入力数値の差異を実感
できる状況には対面出来ていません。

---[らぶデスＦＩＮＡＬ！] 内のフォルダを弄る---
�@[\らぶデスＦＩＮＡＬ！\data\odf\Body] 内に同名の [base_body_A]
というフォルダがあるので、これをバックアップ取ってから削除します。
�AALP2PMXから出力されたフォルダ内に存在する同名フォルダ [base_body_A]
をこのフォルダだけ抜き出して [\らぶデスＦＩＮＡＬ！\data\odf\Body]
内にコピペで置き換えます。上書きはしないで下さい。

で、やってみた所、ボディに留まらず頭、髪、服、武器に至るまで
一括で全部縮小できてしまいました。どういう理由か首だけ少々長目に
なるみたいですが、この程度ならば個別の体かすたむで吸収可能な範疇です。
(SS中の6名が該当します。無修正だとこのような首の長さになります。)
とりあえず、置換実行前の [\らぶデスＦＩＮＡＬ！\data\odf\Body] の
[base_body_A] という元フォルダを多重でバックアップ保全取っておけば
何度でも元に戻すことが可能です。てか作業時は原寸の方が圧倒的に扱い易い。

あと、試した範囲内ではこのSS以下には縮小しないみたいです。
何故なのかとかは全く不明です。先述の通り可か不可かでしか結果が出ません。
プログラムやデータ解析方面は苦手で、普段から意味も分からずに数値入れて、
結果半泣きでOS入れ直すような奴なので、後は詳しい方々に道を譲りたいです。
ご質問等あろうかと思いますが、恐縮ながら何も答えられないと思います。
らぶデスFINAL、たむたむす〜る両方共プログラム実行時に何の問題も起きず、
尚且つ簡単に元に戻せるのが長所でしょうか。しかし因果は不明であり、
最悪OS入れ直すような状況が起こり得る可能性があるという点に御留意下さい。
自己責任でお願いします。しつこいですが、バックアップ必須です。

---アップロードしました---
説明文作成に一番時間が掛かってしまいました。以下の内容でアップします。
�@加工済みbase_body_Aフォルダのサンプル2種→52MBを10MBに圧縮かけてます。
�A縮小時用HAN2種→2807氏作のAボディ用と汎Aボディ用。両方低身長限定です。
�B5月末に出した4人組の更新ALP→今回用に身体微調整の上、秋服着せました。
引用元ALPは5〜6月のと同じです。今回下着だけ紳士No1039氏作のSDK SDJ Bdk
Bdjを新規追加しました。作者の皆様、ありがとうございます。

http://kienizer.com/download/493265
DLパスは英小teatimeです
0

Re: Aボディだけを縮小化 - のぞく人 2019/09/08(Sun) 17:40 No.827
初めまして。面白い情報ありがとうございます。

添付されているサンプル(�@の方)で試させて頂きましたが、なるほど手持ちアイテムまで小さくなりました。なお差し替えるのは「RT_body_type_A.ODF」だけでいいようです。

ALP2PMXにOdfHeightというツール(古い)が同梱されているのですが、これの説明に
「ODFの身長を変更する場合ODAも変換しないとダメ」
とあるので、ツールが作られた当時とどこか動作が変わってるのでしょうね。うん、何故ODAファイル(アニメーションデータのファイルです)を書き換えなくてもいいんだろう？

そのOdfHeight、何となく「ODFファイルの身長変更はこれがあれば大丈夫」と思い込んでいたのですが、これかすたむシリーズより前のODFファイル用だったのですね(FINAL!のRT_body_type_A.ODFを放り込んだら対応してないと怒られました)。ファイルの日付見れば明らかなんですが。なので、もしODFファイル自体の身長を変更しようと思ったら6811さんが書き込んで下さったようなことが必要になるのだと思います。

RT_body_type_A.ODFのどこが書き換わったから着てるものから手持ちアイテムまでみんな縮小されるのかとか、ALP2PMXの頭身設定で「ALP値」にチェックが入ってる時に数値設定がどの様に反映されるのかとか、調べどころが色々ありそうです。

Re: Aボディだけを縮小化 - 6811 2019/09/08(Sun) 20:14 No.828
のぞく人様、踏み込んだ詳細情報をいただき、ありがとうございます。充分な準備や精査もなく、
半可通にも満たない領域に迷い込んでしまった状況に助け船を出していただけて大変恐縮です。
Re: Aボディだけを縮小化 - 6811 2019/09/09(Mon) 18:09 No.831
のぞく人様よりご指摘いただきましたように、どうやら縮小が起きる、または起きない時の差はたむたむ起動時の
[base_body_A]フォルダ内のファイル[RT_body_type_A.ODF]にあるようです。縮小が起きないときは更新日が元に
戻っているのを確認しました。

OdfHeightというツールの情報をいただきましたのでこちらも試してみました。
手持ちのだと[ODF ver1.05]の[身長変更]ボタン押すと出てくる奴です。理由不明ながら[RT_body_type_A.ODF]は読み込み可能でした。
少々ノーマル時と上の縮小適用済みサンプル�@の[RT_body_type_A.ODF]を使用して数値入れ替えを色々試してみたところ、
こちらのツールの方が入力数値の差異が結果に反映するようです。縮小が起きない確率はALP2PMXの時と同じ位あるようです。
ただ首が長くなるバグがなくなってたり、こちらのツールの方が優れていると思いました。
OdfHeightと設定値込みでSS撮りました。もう少し色々試してから投稿書き直ししてみます。

Re: Aボディだけを縮小化 - のぞく人 2019/09/10(Tue) 01:44 No.832
OdfHeightの新しいのがODF(神ツール)から呼び出せるようになってたんですね。気付いてませんでした。前の書き込みで「かすたむシリーズのODFファイルが読めない」と言ったのはomakeフォルダにある古いバージョンのことなので、ODFの[身長変更]ボタンで呼び出されるOdfHeightでかすたむシリーズのODFファイルが処理できるのは正常動作です。

OdfHeightはらぶデス2か3の頃からあるツールで身長変更に特化してるので、「ALP2PMXで書き出してコピー」より簡単確実かと思います。ちなみに身長計算のベース値になっているのはらぶデス2のODFファイルで、aa:愛美、a:あゆみ、b:みなも、c:琴、d:奈々美、e:よつば、という対応です。かすたむシリーズのデフォルト身長だと一致するのが無いかもしれません(心愛さん158？)。

と、ここまでOdfHeightの説明をしておいてなんですが、OdfHeightやALP2PMXでボディのODFファイル(RT_body_type_A.ODF)を書き換えなくても、POSファイルやANMファイルなどで同じ事ができると思われます。

画像はRT_body_type_A.ODFをODF(神ツール)でMQO書き出ししたものですが、概ね左側がデフォルト、右側が6811さんから頂いたサンプル�@のものになります。見て頂ければ解るとおり、形状データ自体は縮小されていません。

ではどうやって縮小しているのか調べてみたのですが、ODFファイル内のFRAMチャンクという部分…ここにはボーンの情報が書かれているのですが、ここに書き込まれている情報を書き換えることで実現しています。で、これはPOSファイル等のモーション系のかすたむファイルがやっていることとほとんど変わりません。

単純に、頭と胴体で縮小比率を変えないので良ければ、透過好きさんがモーションアップローダーで公開されているファイル(yonezon.coresv.com/joyful4/joyful.cgi?read=273)が利用できるかと思います。Yomeko023さんが公開されていたPosEditというツールがあればOdfHeightが施す変更と同じ事をODFファイルの書き換え無しで多分できると思うのですが、残念ながらこのツールは現在入手できません。何れにしても、HANファイルが作り直しになってしまうのが一番の問題かもしれません。

何かやる気を削ぐような事を言って大変申し訳ないのですが、動作的にはそんな感じで他にも方法はあるよ、ということです。ただOdfHeightは数値入れると適当に計算してくれるので楽だろうと思います。PosEditでやろうとすると、自分で計算してトライ＆エラーということになるでしょうから。

Re: Aボディだけを縮小化 - 6811 2019/09/10(Tue) 09:48 No.833
のぞく人様、題材の核心に纏わる情報を、私のような者にも理解し易い文章でご解説いただき、感謝至極です。
神ツール作者様をはじめ、文章中にご紹介いただいた歴代の職人様方にも改めて感謝します。

私の場合、HANファイルを配布している都合上、DLして下さる方々とある程度環境を揃える必要があります。
なので今回の投稿の落とし所は「OdfHeight」を利用した[RT_body_type_A.ODF]を数種作成して、その条件下で
完全に動くHANファイルを別途作り直す事にしました。そちらの完成はもう少々お待ち下さい。

のぞく人様には大変お世話になりました。なりっぱなしで申し訳ないです。ありがとうございます。
Re: Aボディだけを縮小化 - のぞく人 2019/09/11(Wed) 00:54 No.834
いえいえ、そこまで言って頂き大変恐縮です。

何か調べ物をすれば必ず持ち帰るものがありますので、その辺はお気になさらずに。

Re: Aボディだけを縮小化 - 6811 2019/09/14(Sat) 03:17 No.836
---[Aボディだけを縮小化]完結編---

のぞく人様よりご提供いただいた情報を元に、9月5日投稿の[Aボディだけを縮小化]という題材について
修正とまとめをやってみたいと思います。
　
最初の投稿にありましたALP2PMXを使用して云々の件は、すべて不要になりました。
代替で、[ODF ver1.05]の[身長変更]ボタン押すと出てくる「OdfHeight」というツールを使用します。
[ODF ver1.05]は、ALP2PMX ver1.06に同梱されています。

---9月5日分との差を以下に書きます---

�@フォルダ[base_body_A]を入れ替える必要が無い。
�Aフォルダ[base_body_A]内のファイル[RT_body_type_A.ODF]だけを置換する。
　(バックアップ対象は、[\らぶデスＦＩＮＡＬ！\data\odf\Body\base_body_A]内のファイル
　[RT_body_type_A.ODF]これひとつだけになります)
�B入力数値はちゃんと反映される。これは作る方も明確な標的を持てますし、環境を共有する際の
　指標にもなります。
�C首が長くなるバグがない。
�D9月5日分のALP2PMXの時と同じく、たむたむ/FINAL起動時に縮小が反映されない時がある。
　(ファイル[RT_body_type_A.ODF]の更新日が元に戻っているので判別が楽)
�E作業が大幅に簡易化、簡略化されました。

---手順をまとめてみます---

�@[\らぶデスＦＩＮＡＬ！\data\odf\Body\base_body_A]内のファイル[RT_body_type_A.ODF]を多重で
　バックアップを取って下さい。
�Aコピペした[RT_body_type_A.ODF]ファイルを[ODF ver1.05]に読み込みさせます。
�B[ODF ver1.05]の[身長変更]ボタン押すと「OdfHeight」というツールが起動します。
�C今回のSSにあるように数値を色々入れて試してみて下さい。
�D[OK]ボタン押すと入れた数値が反映され、読み込んだ[RT_body_type_A.ODF]ファイルが更新済みになります。
�Eこの更新済み[RT_body_type_A.ODF]ファイルを[\らぶデスＦＩＮＡＬ！\data\odf\Body\base_body_A]
　内の[RT_body_type_A.ODF]ファイルと置換します。バックアップさえ取ってあれば上書きで構いません。

9月5日にアップしたZIPファイルを補完する形で追加分のZIPファイルをアップします。
「OdfHeight」で加工更新済み[RT_body_type_A.ODF]ファイルのサンプルを3種、[105cm近辺][115cm近辺]
[125cm近辺]と、これらに対応するHANファイルが6種入ってます。[125cm近辺]という今回分のサンプルが、
前回のサンプル�@�Aの近似値になります。なのですが首の長さが合わなかったためHANは作り直しました。
下記よりダウンロードお願いします。DLPは英小teatimeです。

http://kienizer.com/download/494168

のぞく人様、おかげさまで題材に対して、よりレベルの高い道が開けた感じがしています。
ありがとうございます。

す〜るのペイント画面を見るとわかりますが、瞳テクスチャは4ヶ所(かおる、のどか、たむたむヘッドは3ヶ所)を交互に表示することでハイライトを揺らしています。と言うことで心愛さんのテクスチャから切り出してGIFファイルにしてみました。

外部ツールでフルペイントする場合も4ヶ所でハイライトの位置を変えれば揺らすことができるはずです。実験してませんが。画力があれば炎を揺らすこともできるかもしれません。4コマしかありませんが。

どの表情でテクスチャのどの部分(AかARか、と1・3段目か2・4段目か)を使用しているかを一覧表にしてみました。よねぞんアップローダー(yonezon.coresv.com/upload/upload.cgi)の00099です。ペイントの参考になれば良いかなと思います(個人的には細かい違いがあるのを見てるだけで楽しい)。
0

Re: 瞳のハイライト - よねすけ 2019/02/26(Tue) 20:26 No.816
外部ツールで4箇所でハイライトの位置を変えて塗れば揺れますね。なお、す〜るのペイントでは、たとえ一瞬のクリックでも4箇所全てにペイントされてしまいます。

以前、エルガイムとか百式の横に流れるキラキラをやってみようかと思いましたけど、コマ数少なすぎて断念した覚えがあります。
Re: 瞳のハイライト - のぞく人 2019/02/26(Tue) 21:17 No.817
ちゃんと揺れますよね？
よかったー

ペイントは実際にカーソルのある位置ではなく、最初から4ヶ所同時に書き込む仕様になっているようです。かおる、のどか、たむたむの3つのヘッドはテクスチャを3コマ分しか使っていなくてペイントのカーソルも3コマ間でしか動きませんが、クリックすると4ヶ所全部に書き込まれました。

なので揺らそうと思ったら外部ツール必須ですね。

外部ツールでのペイント - のぞく人 2019/02/26(Tue) 21:20 No.818
最初の書き込みからの続きです(でも直前も受けてる気がする)。

外部ツールを使ったペイントのやり方についてはよねすけさんがよねぞん改に記事「たむ式メーカー（ALP2PMX）でテクスチャを変える」(yonezonkai.blog.fc2.com/blog-entry-19.html)を書かれていますのでそれを参考にして下さい。編集対象のファイルが「head_xxxx」フォルダの中にあるというところが違うだけです(ボタンも[ALP⇒TGA]でOKです)。

あと私がこちらに書き込んだもの(No.488「ペイントデータをいじる(目)」からのスレッド)も参考にできると思います。但し、そちらにも書きましたが、使用したツールで扱えないヘッドが有る点にご注意下さい。

ALP2PMXはたくさんのファイルを書き出すので、初めてだと「どのファイルを編集したらいいかわからない」となるんじゃないかと思います。ペイントデータは全て

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

というファイル名で書き出されるので、それを探して編集して下さい。

瞳テクスチャの場合は以下の様なファイル名になります。基本的にファイル名の頭に「eye_A」「eye_AR」が付きます。

・かすたむ系、らぶデス555系、20773ヘッド
　eye_A@HEAD_RT_BASE.ODF.tga
　eye_AR@HEAD_RT_BASE.ODF.tga
　但しエイルヘッドはODFファイル名が違うので
　eye_A@HEAD_0000.ODF.tga
　eye_AR@HEAD_0000.ODF.tga

・らぶデス4系、らぶデス3系ヘッド
　eye_A_Mesh_HEAD_RT_base_Layer2@HEAD_RT_BASE.ODF.tga
　eye_AR_Mesh_HEAD_RT_base_Layer2@HEAD_RT_BASE.ODF.tga

・らぶデス2系ヘッド
　Mesh_HEAD_RT_base_Layer2@HEAD_RT_BASE.ODF.tga
　但しあゆみヘッドは
　Mesh_HEAD_RT_base_Layer2@HEAD_R.ODF.tga
　またロタヘッドは
　Mesh_HEAD_RT_base_Layer2@HEAD_0100.ODF.tga

らぶデス2系ヘッドだけ名前が「eye_」で始まらないので注意して下さい。また通常目しか無いので編集対象のペイントデータも1つです。

これらのファイル名はどのヘッドを使用しているかだけで決まります。顔かすたむで目のタイプを変えていても関係ありません。らぶデス2系の目を選択していてもヘッドがそれ以外であれば、通常目とAR目のペイントデータは別々に保存されます。

同様に、どの表情で瞳テクスチャのどの部分を使用するのかもヘッドだけで決まります。これも目のタイプを変えていても関係ありません。瞳テクスチャをペイントで完全に塗りつぶしてしまうのであれば、目のタイプはどれを選んでいても関係ないです(プログラム的に余計な操作が入らないという意味でデフォルトがお勧め)。

表を作っていて気付いたこと - のぞく人 2019/02/26(Tue) 22:29 No.819
気付いたことをいくつか。

上にも書きましたが、かおる、のどか、たむたむの3つのヘッドは瞳テクスチャ4コマ分のうち3コマ分しか使用しません。使わないのは3・4段目の右側です。これは通常目、AR目どちらでも同じです。

但し、ペイントに関しては上にも書いたように使わない右下にも書き込まれます。ヘッドを換えた時にペイントデータが引き継がれても問題はありません。それも含めてただ「3コマ分しか使ってないんだなあ」というだけで、別段問題になることは無いと思います。

次。らぶデス4系ヘッドはデフォル目を使用する表情で指定と実際に表示される表情がずれています。「びっくり」はいいのですが、他は

？　→　＞＜
＞＜　→　ほっこり
ほっこり　→　キラリッ！
キラリッ！　→　？

という具合に別の表情が表示されます(きちんと確認していませんが、デフォル目の表示だけがずれているのではなく表情モーフの指定がずれていると思われます)。

スクリーンショットを撮る際はそれを考慮した上で表情指定すれば済む話ですが、いくらか面倒かなと。フリーモードとか戦闘モードだと間違った表情になっているものと思われますが、遭遇することがあるのかどうか。

次。こちらもデフォル目絡みです。みなも、奈々美、よつばの3ヘッドは表情に「？」「＞＜」「ほっこり」「キラリッ！」が指定された時に瞼の影響が出ます。みなも、よつばヘッドは瞼が動いているのがわかり、奈々美ヘッドは瞼は閉じた状態で固定されていますが、デフォル目のメッシュより上に出てしまっています。

らぶデス2系ヘッドのデフォル目は「びっくり」以外は放置状態(テクスチャは一応あるが切り替えるようになっていない)なので、ビューワーモードではこれらの表情を使わなければいいのだと思います。こっちもフリー／戦闘モードで出くわすかもしれませんが、アップにしなければ気付かない…か？

最後。カレマチカノジョとす〜るv.4体験版で気付いてらぶデスFINAL!では起きてないことを確認してますが、つばめヘッドでAR目を表示させると(「無表情放心」等)瞳が(正面から見て)左に寄ります。ただ「大泣き」では寄りません。

モーフ指定は他の555!系ヘッドと同じなのにつばめヘッドでだけ起こります。謎です。そしてODFファイルは全く変わっていないのに、らぶデスFINAL!では起きなくなりました。

原因のわからない不思議な現象だとは思いますが、問題になることは無いと思います。が、ビューワーモードで「視線が思う方を向いてくれない！」とかなるかもしれません。未確認ですが(FINAL!使ってる分には起きないし)。

以上。長々と失礼しました。

追加 - のぞく人 2019/02/27(Wed) 21:27 No.820
ペイントデータのサイズについて補足です。

瞳テクスチャのペイントデータのサイズ(ファイルサイズじゃなくて画の大きさの方)は、ODFファイルで指定されたテクスチャのサイズと同じになります。「目のタイプ」で本来のテクスチャより大きいサイズのテクスチャを選択しても解像度は上がりません。

例えば、同じODFファイルを使用するあゆみヘッドとロタヘッドでは指定する瞳テクスチャのサイズが違うので、ペイントデータのサイズもそれぞれ256dot角、512dot角と異なります。あゆみヘッドで目のタイプにロタを選択しても、ペイントデータのサイズは256dot角のままで512dot角にはなりませんでした。

ATOKを使っているとファイルを保存する時の漢字変換の最中にす〜るが落ちるという現象ですが、回避できそうなので報告します。

現象が起きたのはWin7Pro32bitのPC(ATOKは2014)です。同じような構成でもWin7Home32bitの別のPCではファイル保存時に落ちることはないので、発生条件は今一つはっきりしません。ただ「こうなると落ちる」は分からなくても「落ちる時はこうなっている」の方は見えてきました(多分)。

ATOKはデフォルトの設定だと、変換候補のウィンドウが表示された後2・3秒止めていると情報ウィンドウという候補の言葉の補足説明のためのウィンドウが表示されます。落ちるのはこの情報ウィンドウが出た後に思えたので自動で表示されないようにしたところ、ファイル保存の時の漢字変換中に落ちることはなくなりました。

なお「情報ウィンドウが出た後」と書きましたが、落ちるタイミングはウィンドウ表示直後であったりウィンドウ消去の時であったりとまちまちです。

Microsoft IMEで変換する分にはす〜るが落ちることはないのですが、こちらは情報ウィンドウのような追加のものを出さないことが関係しているのかもしれません。
0

設定手順1 - のぞく人 2018/12/09(Sun) 17:26 No.751
回避のための設定変更ですが、ATOKの環境設定から行います。

まず言語バーのメニューのボタンをクリックしてATOKのメニューを表示させて、比較的下の方にある「プロパティ(環境設定)」を選択します。

ATOKの設定はユーザー毎であってアプリケーション毎ではないので、別にす〜るを起ち上げてやる必要はありません。でも、画像です〜るを起ち上げて設定をしているのには理由があります。

私の場合PCは通常一般ユーザーで使うことにしています。一方す〜るは起動時に管理者パスワードが必要、即ち管理者アカウントで動いています。なので、す〜るのファイル保存時に呼び出されるATOKを設定するには管理者アカウントのATOKを設定しなければなりません。一旦ログオフすればいいのですが、す〜るのウィンドウがカレントになっている間は管理者アカウントの言語バーが表示されるので、そのタイミングで設定を行った次第です。同じようにPCを運用してる方はほとんどいらっしゃらないと思いますが、参考までに。

設定手順2 - のぞく人 2018/12/09(Sun) 18:01 No.752
「ATOK プロパティ」のウィンドウが表示されたら左側の「設定項目」から「表示」を選びます。次いで「情報ウィンドウを表示」の項目を「する(自動)」から「する」もしくは「しない」に変更します。あとはOKで抜けて設定完了です。

「情報ウィンドウを表示」を「する」に設定した時は、「End」キーを押すと情報ウィンドウが表示されるようになります。即ちす〜るのファイル保存の時に誤ってEndキーを押すとす〜るが落ちます。ただ他のアプリケーションを使う時に情報ウィンドウが表示されないというのも嬉しくないことだと思うので、個人的には「しない」より「する」がお勧めです。

取り敢えずATOKの設定変更について書きましたが、もちろん漢字やかなを使ったファイル名を付けなければ回避できます。また前の方にも書きましたが、Microsoft IME(MS-IMEから名前変わってた模様)なら問題が起きないようなのでそちらを使うという手もあります(す〜るの時だけ切り替えるのはちょっと面倒だと思う)。そもそもATOKなら必ず問題が起きるという訳でもなさそうですし…


イベントログを見てわかったのですが、実はWin8以降でMQO読み込みを行った後に落ちる時と同じアドレスです〜るが落ちています。何回かに1回は「障害が発生しているモジュール名: XAudio2_7.dll_unloaded」とログに残ります(頻度はかなり違う)。なので、確認はしていませんが、XAudio2対策パッチでも対処できるのかもしれません。MSの人が「Win7でだって同じことが起きうるよ」と言っていたのが証明されたと言いますか…

双方に共通しているのは「す〜るから外のプログラムを呼び出してそのウィンドウを表示させている」といった辺りです。こういったことはシステム(Windows)側に変更があったりすると影響を受けやすいので、古いプログラムには一番辛いところなのかもしれません。