スポンサーサイト

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

形状スライダー適用ツール?

twitterの与太話からまたひとつ、素晴らしいツールが生まれました。もちろん、与太話をしていた本人たちが作ったのではなく、妖精さんが作ってくれたのですがw

私はほとんど触ることが無いのですが、形状スライダーは形状カスタムされた頂点モーフを0~100%の割合で、元のヘッドから線形変形してくれる便利な機能です。割と適当に顔カスタムしても、形状スライダーを下げると、程よい顔になったりします。また、ちょっとリアル寄りに作った顔を、幼くすることもできます。

ただこの形状スライダー、形状カスタム時には通常、適用されていません。私は知らなかったのですが、形状カスタムで一度クイックセーブしたものをロードすれば、形状スライダーが適用された状態でカスタムすることができます。ただ、やはり手間がかかったり、例えばALP2PMXでpmx変換する場合に不具合がありますので、今回のツールの出番となります。

画像の左は形状カスタムされた元の形状、右は、左のものの形状スライダーを50%程度にし、ツールで処理したものです。形状スライダーが適用された状態で、スライダー最大となっているのがわかると思います。形状スライダーを多用される方にオススメです!

なお、こちらのツールを適用後は、予期せぬ不具合を防ぐため、一度、たむたむす~るで保存しなおした方が良いとのことです。(詳細はコメント欄にて)

tech_e68.jpg

テーマ:美少女ゲーム - ジャンル:ゲーム

コメントの投稿

非公開コメント

ブログ更新ご苦労様です

Twitterで話をされてたもう一かた、借紳士さんからの講評がまだ頂けてないので、変換が本当に大丈夫なのかチョット不安が残ります。形状スライダーを実際に駆使される方なので、氏からOKを貰えるようならまず問題無いはずです。

ツールの解説(なのか?)

「問題が…」という声も聞こえてきてないので、現状で良いものとして少々解説を。公開物にはソースを入れてあるので併せて読むといいかもしれません。(ソース読んで全て理解できる人には多分要らない話です。)

まず顔かすたむの形状スライダーですが、右端の時(ALPファイル、FSPファイルに記録される値は100.0)はカスタムした通りの形状でキャラクターが(通常画面で)描画され、左端の時(値は0.0)は未カスタムのヘッドの形状で描画されます。スライダーを動かしてみると何となくリニアに(比例でも線形でも直線的でも1次関数的でもピンと来る言葉で理解して下さい)変化してるように見えたので、「未カスタム時の頂点座標とカスタム後の頂点座標を線形補間してやればスライダーの位置に応じた形状が再現できるだろう」という推測しました。変換結果が妥当に思えるところを見ると、推測は当たったようです。

次に頂点座標をどこから得ているかについて。先にカスタム状態の方から行きますと、これはそのままALP及びFSPに記録された値を使ってます。zlibで圧縮されたデータを伸長して読み込んでるだけです。当初はFMSファイルも書き換える対象に含めるつもりだったのですが、FMSファイル(及びALP、FSPのFMS相当部分)には形状スライダーの値が書き込まれてないことに気付き対象から外しました。(頂点座標はこのブロックに書き込まれてるんですけどね。)

そして未カスタム状態の形状データについて。これはODFファイルのMESHチャンクからデータをそのまま持ってくればいいと当初考えておりました。今まで服等のアイテム類(data\odf\Item配下のファイル群)を弄ってきてmeshの形状がそのまま描画されてると思っていたからです。が、meshの値とカスタムデータの値を両端に計算したものを実際に表示させてみると、表示されるはずのないデフォル目が表示されたり通常目/AR目が奥に引っ込んだ位置に描画されたりと、明らかに異常が見られます(よねすけさん、借紳士さん、検証ありがとうございました)。顔ベース(mesh名だとBODY_HEAD_FACEALL_XT)などは大丈夫そうでしたが、目やデフォル目といったモーフで表示を切り替えてるものでは線形補間に使ってる片側(未変形側)の値がおかしいようだと思いました。

で、取り敢えず各ヘッドの未カスタム状態のFSPファイルを出力して更にその形状データをMQOに書き出してみました。通常目、AR目、デフォル目、ほっぺ、涙などのmeshをそのままMQOにしたものと較べるとやはり違いがあります(涙などはヘッドによって一致するのもある)。他にODFファイル内にある形状データといえばMORPチャンクにあるモーフデータです。基本形状(だと思う)と比較してみたところ大体同じに見えたので(実は全頂点でちゃんと比較してない)、未変形側の値はMORPチャンクから引っ張ってくることにしました。

今まで形状カスタムはmeshの値を操作してると思っていたので、モーフデータの基本形状をベースにしてるという今回の結果は自分にはかなりの衝撃です。もちろんモーフデータを一切持たないmeshの場合はmeshの形状を直接弄る以外に無いでしょうが。

補足しておきますと、ODFファイルのMORPチャンクにはPMXファイルで言うところの(他の3Dフォーマットでも?)頂点モーフとUVモーフが合わさったみたいなデータが入ってます。PMXでは頂点モーフを変形量(オフセット)で定義しますが、ODFでは基本状態や変形状態の形状データ(便宜上「子morp」とか「sub-mesh」とか呼んでる)がmeshと同じ形でそっくり入ってます。大抵の場合は基本状態モーフの形状はMESHチャンクの形状データと同じ(微妙に異なることはある)なのですが、ヘッドのODFファイルではmeshによってはかなり違う値のデータが入ってるようです。心愛ヘッドのデフォル目を見るとMESHチャンクのデータがそのまま描画に使われるのではないことがよく解ります。今までMESHチャンクだけ見て何とかなってたのは偶々ということのようで(それで問題が出るのはヘッドくらいと願いたいです)。

そんなこんなで、ヘッドの各meshのうち以下のものはMORPチャンクの値をベースとして形状スライダー適用後の形状を計算しております。
・eye_A(通常目):EYE_Change_A.Mop
・eye_AR(AR目):EYE_Change_AR_.Mop
・BODY_HEAD_EYE_sp1(デフォル目):SP1_eye.Mop
・hoppe(ほっぺ):Hoppe_.Mop
・namida(涙):Namida_.Mop
「~.Mop」というのは値を引っ張ってきたモーフデータの名前です。通常目やAR目(顔ベースなんかも)は対応するモーフデータが複数あります。上に挙げた以外のmeshはMESHチャンクの値をそのまま使っています。多分違いが無いだろうと思ったので(そっちの方が処理が簡単)。なお、「『EYELASH_DEFO』meshは通常はモーフデータを持たないけれど、持っていた場合も形状カスタムのベースになってるのはどうもmeshの方の形状らしい」と思ったことも併せて書いておきます。

で、ここまでスルーしてきた法線ベクトルの話なんですが、本当は「それぞれの向きを求めてスライダーの位置に応じた角度だけ回転させる」といったあたりが妥当な処理だと思うのですが、最初に書いた「ベクトルをm:nの割合で足してサイズだけ正規化」という処理から変えておりません。これは、このツールの使用場面を考えた場合出力ファイルは必ずもう一度す~るに読み込まれるだろうと考えたからです。配布する場合やALP2PMXで変換する場合などは、一度す~るで保存し直して法線ベクトルを再計算することをお薦めします(多分再計算してくれると思うんだけど…)。

蛇足ですが、今回「ODFファイルから値を読み込んで(計算して)それをALPファイルに突っ込む」ということで、「頂点復活」のソースをかなりの割合で流用しました(最近の書き方に合わせて直すこともしてない)。あとサムネイルは弄りようがないので何もしておりません。

いつも以上にまとまりが無く、読み辛くてすみませぬ。以上、長文失礼。

Re: ツールの解説(なのか?)

詳しくありがとうございます!
私じゃ大体しか分かりませんが、どなたかの詳しい方の役には立つはずですねw
とりあえずは、たむたむす~るで一度保存しなおすべきと追記しておきます。

No title

あけましておめでとうございます!

顔の形状カスタムじゃなく
PMX変換時、髪の長さスライダーにも
適応させたいのですが可能でしょうか?

Re: No title

あけましておめでとうございます。

髪の長さスライダーは、PMXなら頂点モーフではなく、ボーンのスケールで調整できると思います(たぶん

ありがとうございます

よねすけ様
早急な解答ありがとうございます。
スケール調整でほぼ出来ました
細かいトコはいろいろやってみますね
感謝です♪
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。