多少、諦めがついた。
2006年11月04日（Sat）
何が、というとコレ。
オブジェクト上のエッジに近い面に不正な光や陰が現れる問題である。
画像自体は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では変わってないだろうけど。
