流転四界ぶろぐ

中華展で使用した中華風アイテムのセット、Chinese Dream（ベタなネーミング）をこっそり配布しています。壺と団扇モドキ以外はまともにUV貼ってないので、テクスチャも使えないような代物ですが、それでも良いという心の広い方は前回のエントリのコメント中のアドレスからダウンロードして下さい。

＊

それでもって2つ目の作品は、一作目とは打って変わって動きのあるものにしたいと考えた。
構えているポーズはまあ大丈夫として、実際に闘うシーンとなるとどうなんだろう？　という興味と、まあ時間も押しているので軽いノリで……。
というわけで対決シーン。
お相手は作った時にはまさか何度も絵を作ることになろうとは予想だにしてなかったAssassin。被写体的には手前の人物よりこちらの方がメインかも。



ビルの屋上を想定して、ポーズを付けたら水平に近い角度からライトを数個当てる。特撮モノのような過剰なライティングを意識するも、どうもイマイチぴたりと嵌まらない。手前側の人物の絵画調なタッチと、奥の人物、それから背景セットのテクスチャの解像度が見事にバラバラで統一しきれなかった。時間があれば長袍と髪のマテリアルに手を入れて質感を統一したり、もっと丁寧にポストワークを施してタッチを整えたり……と出来たのかもしれないが後の祭り。ブラーや走査線はその辺りを緩和するため効果だが、それもただ単にかけただけな感じになってしまった。

というわけで反省の生レンダ1/4サイズ。



さて、自分はDCを使う時、作品用のシーンファイル内でシミュレーションを行うことはほとんどない。シミュレーションを使うと大体の場合30フレーム目が完成フレームとなるわけだが、それを基準にして30フレーム目でシーンを構築しようとするとアイテムを追加した時など煩雑だし、ダイナミクス計算用の一時ファイル（dynファイル）が出来てしまうのも煩わしいからだ。

そんなわけで今回ならば、ポーズとカメラアングルが決まった時点でまず手前のGuardianのポーズとカメラをライブラリに登録する。フィギュアの位置調整にはhipのx移動やz移動は使わず、必ずBODYの移動を使うようにする（もちろんポーズとしての調整には使う）。
で、新規ファイルにフィギュアとDCを呼び出し、30フレーム目に保存したポーズを適用する。さらに、総フレーム数を60まで延長し、最後から少し手前の55フレーム目でBODYを移動させる。



シミュレーションをさせるなら、実際の動きと布のパラメータをそのまま再現するのが一番だ。この場合、長袍の裾は構図的に左になびいて欲しい。ならそのようになるよう、人物は右後方に跳びすさるのが一番である。大体2メートルを0.5秒ぐらいだろうか？　布のパラメータが適切なら、シミュレーション結果は現実と同じような動きをするはずである。

が、この長袍、そんな厳密なセッティングは施してない（暴露）。さらに試行錯誤を重ねパラメータを追求する時間的余裕もない。

というわけで、布がそれっぽくふわりと動くだろうなー、と予想されるモーションを付ける。



まあこんな感じ。案外適当である（笑）

で、シミュレーションが終了したら作品用のカメラを適用して、30フレーム目から60フレーム目までをコマ送りし、一番いい感じになびいているフレームを探す。フレームを決めたらグルーピングツールで全てのポリゴンを含むポリゴングループを作成し（既にあるならそれを選択し）、「新規小道具として作成」でそのフレームの状態を小道具化する。



小道具は親パートのワールド変換を相殺した形で作成される。ワールド変換（トランスフォーメーション）とはつまり移動、軸回転、拡大縮小である。この場合なら、書き出ししたフレームでのBODYパートは+X方向と-Y方向に移動しているが、それが0であるとしてユニバースの直下に新しい小道具が作成される。もしそのフレームでBODYを50％縮小していたら、新たな小道具は200％で作成されてしまうので注意。



で、BODYがワールド変換を受けていない、つまり最初のフレームに戻り新規小道具をBODY直下にペアレントし、そのままライブラリの小道具に登録。作品用のファイルを開き、フィギュアを選択して小道具をロードすればちゃんと重なる。



WavefrontOBJ形式で書き出さずに新規小道具を作成するメリットは、マテリアルをそのまま継承できる点である。外部ファイルをインポートする手間もない。また、モーフではなく実ジオメトリとして作成されるので、マグネットによるちょっとした修正も容易になるし、作品用のシーンファイルにシミュレーションを含めなくてもいいので若干軽くなる。作成された小道具はDCではなくただの小道具なので、シミュレーションに対応していない外部アプリケーションでも難なく読み込める。さらに、ポーズとセットで保存すれば後々使い回しも効く。自分のライブラリには、ＡさんとＢさんの法衣がずらりと並んでいる。どれもシミュレーション専用のシーンファイルから登録されたもので、自分はこの作業を型取りと呼んでいる（笑）

難点は親階層と自分自身のワールド変換が相殺されるという点だけである。なので、ポージングの際のhipの移動とBODYそのものの移動は厳密に区別し、DCに拡大縮小などは掛けないようにする。逆に、シミュレーション中にBODYパートを変な方向に動かしていたとしても小道具化すれば元に戻るので、風のような表現をするときはウインドデフォーマを使うことよりもBODY自体を動かすことの方が多い。

そんなわけでチャイナは一段落。次はクリスマスと正月をどうするか考えないと。



来るもの拒まず去る者追わず。（『サイテー！（by ユーティ）』）

某所のアレ＝MUKAさん家のチャイナ展に出展完了。
この為に長袍作ったというのに、下手したら間に合わないんじゃないかと冷汗を浮かべることしきり。Poserの3Dテクスチャのお陰で、テクスチャを使わなくてもある程度見栄えのするマテリアル設定ができるのでなんとか時間短縮、という感じかも。誰かさんが専用テクスを要求するもんだからもう……。

というわけで1/4生レンダ（部分レンダ合成済み）。レタッチしないと女性よりＡさんの方が色白なのがご愛嬌（爆）



珍妙な話だがＡさんには一端のアイデンティティーがある。
本職・悪の僧侶というイメージに捕らわれず（笑）、オファーを与えればPoserフィギュアらしく割となんでもこなしてはくれるものの、それでもやっぱり「これだけはタブー」というのがいくつかある。

いちばん困るのが「刃のついた武器を身に付けてはいけない」ことだ。
これ、WIZをプレイしたことがある方ならおわかりいただけると思う。ゲーム上のルール、僧侶の装備の制約である。棍棒で殴り殺すのは全然オッケーなのだから、どうやらただ単に宗教上の理由によるものらしい。
「そんなルールまで持ち出さなくたっていいじゃん」
「これPoserだしファンタジー界でもないし」
「お願い、構えてポーズとるだけでいいから！」
……どんだけ理由をつけても頑固に抵抗される。冷静に考えれば自分（の深層心理）が取捨選択しているだけだとはわかっているものの、ここまで「自分がやってみたいこと」と「キャラにできること」に隔たりがあると、なんだか本気で拒否されているような気持ちになるから妙なものである。
とりあえず無理矢理手渡してみる。



なんか、受け取り方にも独特の作法がある……っぽい。

Ａさんには密かに黒髪別肌の日本人バージョンが既に用意されているにも関わらず、こんな調子なので侍・武士・時代劇モノ、中国武侠モノ、演舞系、全滅である。じゃあなんで日本人バージョンなんか用意したんだ……というのは、まあ置いといて（やってみたかったんだけどなー）。

もう一つ、これもかなり困りモノの制約があって、これは今回の絵の別アングル。



どうも、Ａさん（とＢさん）は「他人との皮膚接触」がNGらしい。

そんな設定もルールもない筈なのだが、とにかくダメらしい。性格的にもあり得なかろうと思うのだが、とりあえず人前じゃ駄目らしい。なんでやねん。
自分が面倒臭いとかそういうわけじゃない。KOD'sの三人なら全然大丈夫なんである。ポージングは確かに手間だがそんなに苦痛でもない。ところがこの二人となると、せいぜいが蹴りを入れるぐらいで……。



かえって面倒臭いんだけど。どのみちカメラからは見えないし。

女性ファッション誌の広告のような、イカニモあざとい系エロエロ画（←あまり深く考えないように）などを作りたいな〜と、去年（笑）からずっと考えているのだけど、どうしても上手くいかない。女性側が無個性なのがいけないんだろうか、などと本気で悩んでみたりして。

そんなわけで多分これきりお蔵入りしそうなアジアンアイテムたち。

じぇーむずのToeのEndPointが左右で異なるというのは、なんだかんだ言って結構辛い。JPの調整で対称コピーを使うとどちらかの値がもう一方にもコピーされてしまうわけで、調整時に確認しながら左右で同じ値を入れるか、調整後に元の骨を参照しながらエディタでコピー＆ペーストするかの二択。
作業量からコピー後に修正する方を選んだのだが、如何せん面倒臭い。いっそ元の骨を対称化してしまおうかと思ったが、それをすると自分が使う分にはいいけど配布する場合にまずいわけで。じぇーむず本体のEndPointを変更したり戻したりするポーズファイル同梱……ンなアホな。
そう言えばKojiはどうなってるんだろう？

そんなわけで某所のアレ用にじぇーむずアイテム作成。



テクスチャ描くの面倒臭いなぁ。

何が、というとコレ。



オブジェクト上のエッジに近い面に不正な光や陰が現れる問題である。
画像自体はDAZの非常に優れた売り物なのだが、それでもこの通り。つまりこれはShadeのメッシュの扱いの問題ではなく、Poserの描画の問題なんだということだ。なので、もうあんまり気にしなくてもいいかな、と。まあ、あまり目立ち過ぎるのもアレだけど、そういう部分はもうメッシュを細かくすることでどうにか対応しようと思う。

この問題、遭遇したり似たような問題を見かける度に検証したりネットで調べたりするものの、探し方が悪いのか、未だに自分が満足する答えには辿り着けていない。

何が原因で、何故起こるのか。どうすれば回避できるのか。

今の時点で自分に出せる結論は、これはPoserの旧バージョンの不完全な機能を未だに引きずっている弊害なのだろう、ということ。そしてその根拠は、この問題にはUVマップが深く関わっている、ということだ。

PoserのスムースシェーディングがUV値を参照していることは、去年の時点でわかっていた。
なぜなら、この問題はUVをマッピングしていない（全ての頂点のUV値が(0,0)である）オブジェクトでは起こらないからである。また、これがスムースシェーディングの問題であるというのは、やや微妙だが現象を観察してみれば見当がつく。ライトを回してみれば、その部分だけ近隣のポリゴンとは別に明るくなったり暗くなったりする。つまり「影」になっているわけでなく、「面の向きが異なると誤って判断されている」ために「陰」になっている、ということがわかる。

試みに、UVマッピングの異なる同形状を読み込んでみる。



ポイントは、円筒マッピングを施した円柱ではエッジが消えてしまっているという点だ。
このことから、Poserは連続した面のエッジを判別する時、UVマッピングをある程度判断基準としていると推察できる。てゆーか、他に考えられないだろう。

これはPoserの立場になって考えてみれば不思議ではないように思える。
もともとPoserはポリゴンメッシュをウニウニ変形させるのが肝のソフトだ。今ほどハイポリゴンのモデルが無かった頃は、ちょっとした屈伸で面が鋭角を描くこともあっただろう。他のソフトでは、スムースシェーディングを掛けるかどうかは面の接する角度を基準にすることが多い。が、それでパーがグーになった途端にカクカクしてしまうようでは、人体メインのPoserでは非常に都合が悪い。だからPoserはかなり強引にスムースシェーディングを掛ける仕様になっているのだろう、しかしそれでは小道具などを作る時によろしくないので、面が分離しているかどうかを判別するのに、テクスチャを手掛かりにするようにしたのではないか……。
というのが、自分の妄想である。（あくまで妄想で）

通常、面の向きを示すのには法線が使われるし、Wavefront OBJ形式では頂点に点法線というものを設定できる。本来ならこの点法線によって、その角がスムーズであるかエッジになっているかを判断するのだが、この点法線は仕様を読む限り「定義されてなかったら適当に面法線から補完してねん♪」という曖昧なもののようである。なので、このUV値によるスムースシェーディング機能自体は悪くないはずなのだ。問題は、アルゴリズムがしょぼいせいか、UVの不連続な稜線に極端な角度が付くと、正常にシェーディングできなくなる「ことがある」点である。
絶対に起こるというわけではないのが、またいやらしい。

面を分離したり稜線を追加したりして、エッジを立てても構わない形状ならまだ話は楽だ。問題はそれができない形状、スムースシェーディングを掛けたいけれどもUVマップ上は離れていて、事によると結構急な角度が付くけれどもそれを予測して稜線を追加するわけにはいかない、つまりダイナミッククロスの様な形状だと、これはもう手詰まりなんである。



誰か助けて（笑）。

自分はこの問題を、旧バージョンの機能を引きずっている弊害だと判断する。
なぜなら、現行バージョンではもはやスムースシェーディングを掛けるか否かにテクスチャを参照する必要はないからである。
折り目角度、そしてスムージンググループ（スムーズID）。
これらを使えばUV値は必要ない。面を分離したり稜線を追加する必要もない。使い方はマニュアルにちゃんと書いてある（ハズ）、普通にグループ分けしてIDを振ったらいいだけである。そいでもってこれはれっきとしたWavefront OBJ形式の仕様である。むしろ率先して使うべきではないだろうか。



Poserを使っていて非常に残念に思うのは、こういったアップグレードによる地道な進歩が見過ごされがちなことだ。折り目角度がファイルに記述できるようになったのはバージョン6からだが、下位互換のためにこの記述を削除している配布物も多いのではないだろうか。勿体ない話である（実際には読めない記述があっても無視して動くだけなのだが）。

スムージングとスムースシェーディングを混同している向きが多いのも気になるところだ。もっともこれは開発側も混同しているのだろう。特性パレットのスムースポリゴンのチェックを外すと、折り目角度のテキストボックスが無効になるのがその証左だ（笑）。
どちらも名称に「スムーズ」が付くし、以前はスムースシェーディングしかなかったのだから仕方ないが、スムースポリゴンとスムースシェーディングはまったく別のモノである。
スムースポリゴンはレンダリング時にだけ有効になるサブディビジョンサーフェイス（みたいなの）だ。スムースシェーディングは実際のオブジェクトを変形せずになだらかに陰影付けする手法である。
Poserのスムースポリゴンは折り目角度によってスムージングを制御する仕様になっているが、折り目角度は本来スムースシェーディングを制限するパラメータである。スムースポリゴンを使用しないからといって、無効になってもらっては困るのだ。

下位互換などすっ飛ばしてでも、Poserのコードを書き直して欲しいと強く感じるのはこういう時だ。旧来の無理な仕様はそろそろ切り捨ててもいいのではないかと思う。でないといつまで経っても現行ユーザは旧来の仕様にしがみつくし、新規ユーザにとってPoserの仕様は古臭い。もっと先のことを考えないと、いずれ袋小路に嵌まり込むような気がして仕方ない。

とりあえずシェーディングにUV値を参照する仕様だけはどうにかしてほしい。
まあ、多分Poser 7では変わってないだろうけど。

カボチャのデータをShadeからPoserへ移動した時に、たまたま気付いたこと。

ShadeのWavefront OBJエクスポータで出力すると、1形状が1ポリゴングループになるが、その時形状名（＝ポリゴングループ名）を半角スペースで区切ると複数のグループを作成することができるらしい。

こんな形状を出力する。出力するときの名称もこの通り。



出力したobjファイルのポリゴングループの記述。そのまま半角で区切られている。



Poserで読み込むと、球と立方体を含むgroupA、球のみのball、そして立方体のみのblockと3つのグループが出来ている。



これをそのまま「ポリゴングループに既存グループを含める」で出力すると、Shadeから出力した時と同じように半角スペースで区切られている。



ということは、これがWavefront OBJ形式の標準的な書式なのだろう。

インポート時に「同一頂点を融合」を使用することで、Shade-Poser間のデータの受け渡しはかなり自由になっていたのだが、これでさらに自在にやりとりが出来るようになったと思う。

あとはShadeのエクスポータがマテリアルグループ名を吐き出せたらいいんだけど。もともとShadeはマスターサーフェイスでない限り表面材質に名前を付けることができないから、この仕様から直してもらわないとアレだけど。そうすると階層ごとに材質設定を上書きできるメリットが……難しいな。

まあ何にせよ、普通に小道具やフィギュアを作る上で、ShadeからPoserへのデータの移行での不自由はほぼ無くなったかな。