流転四界ぶろぐ

実はウチにも居たりする。

ちなみにマテリアルは調整済み・Photoshopで色調補正。

どんなんかなー、というただそれだけの興味本位でポッチリ購入。もちろん特に使う予定もなく、関連アイテムも所有していないので単なる持ち腐れだ。非道な家主の元に来たものである（←自分で言う）。

美人かどうか、可愛いかどうか、は人の好みそれぞれだから置いといて、実際にロードしてみるとその造形の素晴らしさ、テクスチャのクオリティに驚く。そしてフィギュア自体の出来の落差に二度驚く。この落差はじぇーむず以上かもしれない。まあじぇーむずも大概だし、じぇしーはそれ以上だけど。

とりあえずデフォルトのマテリアルはふざけてるとしか思えない出来なので、マテリアルルームでちょっと真面目に手を入れる。なーんか、どこかで見たような感じかなー。誰に似てるんだろ。

見せ方とかキャラクター性とか魅力とかを考慮せず、ただ見栄えを変えるだけなら彼女はPoserの機能を駆使すればそれだけで化けるフィギュアだと思った。だけど、それはとてもとても悲観的で皮肉な見方をするならば、 Poser向け……というより、Poserユーザー向けではないというようにも感じられる。

ユーザーはどういう意図で、どのように見せるかをキッチリと求められる。そしてそれに応えている人の絵の中では、彼女はとても魅力的だ。ひょっとしたら、彼女はPoserユーザーにとって試金石なのかもしれない。ちょくちょく付き合っていけば、何かしら身に付くんではないかと思う。

■頂いたコメント■

»Read More

中華展で使用した中華風アイテムのセット、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の三人なら全然大丈夫なんである。ポージングは確かに手間だがそんなに苦痛でもない。ところがこの二人となると、せいぜいが蹴りを入れるぐらいで……。

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

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

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

《2011.11.15追記》
一部リンク先のコンテンツが破棄されたため、該当リンクを削除しました。

しばらく潜伏して（という程でもないか）こんなブツを作っておりました。

Ａさん専用に作るつもりが、何をトチ狂ったか汎用性を持たせようとするから後の祭り。じぇーむずとこーじは不完全クローンだわ、G2は靴を履くと足の指を置き忘れるわ、マグネット地獄だったり、意外とまいこーさん短足だったり（笑）

とりあえずチャイナっぽく見えるダイナミッククロスです。よかったら使ってやって下さい。ご使用の際にはReadMeファイルとシミュレーションメモをご一読下さい。

そのほか、厚かましくも載せきれなかった注意書きなどを。

• 自分用に作ったブツなので　＊　容 赦 な く ハ イ ポ リ ゴ ン　＊　です。シミュレーションの際はそれなりに覚悟して下さい。ちなみに自分の環境（PowerMac G5 2.5 Dual/Poser 6 SR2-122）では上下とも計算開始から終了までに5分程かかります。
• シミュレーション後にモデラで加工修正するのを前提に作ってありますので、厚みも継ぎ目もありません。よきにはからってください。
• 精度向上のため三角ポリゴンを使用しているので、角度によってはスムースシェーディングが綺麗にならない場合があります。レタッチなどで誤魔化して下さい。
• 袖口は裏を向いているので「ノーマル_前」にチェックが入っています。これを外すと綺麗にレンダリングされません。またこの部分のポリゴンを反転させてシミュレーションを実行すると問答無用でPoserが強制終了します。
• 長袍はフォーマル服（だそう）です。あまり激しく動かず行儀良くして下さい。

……なんか、使う人いるのか？　って感じだなぁ（笑）

ダイナミッククロスは今でも遅い・精度が悪い・よく分からないというレッテルを貼られて充分に使われていないように自分などには思われる。よく分からないというのは絶対的なテキストが存在していないからで（多分P5のマニュアルが一番分かりやすいと思う）、それは発売元に一端の責任があるが、速度や精度については使う側にもある程度問題がある。

物理的に有りえない状況を計算させようとしたり、
布というには不適切なオブジェクトをクロス化したり、
自分のマシンパワーを把握しないまま無闇に負荷を増やしたり、してはいないだろうか？
シミュレータはつまり計算機だから、多少ヘンな使い方をしても律義に計算してくれる。今のアップデータ（P6 SR122）ではエラー回避も随分有能になってきたが、無理な計算をさせればそれだけ時間がかかるのは道理である。

要は、何度も言及しているが接触・貫通させてはいけない、ということだ。自分の見た目にとってではなく、シミュレータの視点から見て、である。衝突オフセットと衝突深度の意味と、どのように衝突判定がされているかを把握すればそんなに難しいことではない。（といっても、それを理解するのがまず難関なんだけど）

シミュレータは何でも吐き出してくれる夢の機能ではなくて、現実の物理法則の一部を（時には疑似的に）再現する計算機である。その限界がどこにあるかを把握するのが習熟の第一歩ではないだろうか。

まあ、どんなことについてもそうだけど。
そういう意味では、DCとDHはとてもPoserらしい機能だと言えるかもしれない。

で、自分はと言えばＡさんに専用テクスを強要されているのであった。
（端切れ屋にでも行ってこようかな……）

■頂いたコメント■

»Read More

じぇーむずのToeのEndPointが左右で異なるというのは、なんだかんだ言って結構辛い。JPの調整で対称コピーを使うとどちらかの値がもう一方にもコピーされてしまうわけで、調整時に確認しながら左右で同じ値を入れるか、調整後に元の骨を参照しながらエディタでコピー＆ペーストするかの二択。

作業量からコピー後に修正する方を選んだのだが、如何せん面倒臭い。いっそ元の骨を対称化してしまおうかと思ったが、それをすると自分が使う分にはいいけど配布する場合にまずいわけで。じぇーむず本体のEndPointを変更したり戻したりするポーズファイル同梱……ンなアホな。
そう言えばKojiはどうなってるんだろう？

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

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

ライティングのまとめ、最後に取り上げるのはアンビエント・オクルージョンだ。Poserでは環境閉塞という名前で呼ばれているが、この微妙な翻訳はPoserだけのものなので、3DCGで一般的な「アンビエント・オクルージョン（Ambient Occlusion、以下AO）」と呼ぶことにする。直訳すると「環境光の遮断」というところだろうか。

AOは正確にはライティングに関わる技術ではなく、拡散IBLライトの回のクイズで答えたようにマテリアル（材質設定）の一種である。ただ、拡散IBLライトを使用する時には必須といっても過言ではないので、ここで基本的な使い方をまとめておくことにする。

AOを使うには二通りの方法がある。まずは基本的な、マテリアルとしての使い方から。

まずはマテリアルルームに入り、AOを適用したいマテリアルを選択して、ウィンドウ右のWacro「環境閉塞のセットアップ」をクリックする。すると現在選択しているマテリアルの拡散値と鏡面値に「環境閉塞」というノードが接続され、レンダリングオプションの「レイトレーシング」のチェックが（手動設定の場合）ONに変更される。

とりあえず、そのままテストレンダしてみよう。AOを適用したマテリアルの、周囲が狭くなっている箇所に影が落ちているはずだ。

このように、AOは「狭くなっている部分を自然に暗くする」という材質設定である。Wacroを使用せずにAOを適用する場合は、新規ノード＞ライト＞レイトレース＞環境閉塞でノードを作成し、拡散値と鏡面値に接続しよう。代替拡散色や代替鏡面色に何らかのノードを接続している場合は、そちらの入力にもAOノードを接続してAOの計算結果を反映させるようにしておくといい。

それでは、AOがどのようにして周囲を「狭い」と判別しているのか、その仕組みを見てみよう。

レイトレーシングを使用しているとき、カメラの視点から画面の各ピクセルに向かってレイ（視線）が飛ばされる。そのレイはAOの適用されているオブジェクトに衝突すると、その地点から半球状のランダムな方向に、サンプル用のレイを数本飛ばす。サンプルレイは設定された一定の距離を進み、その間に何らかのオブジェクトに衝突すると「障害物アリ」だと判断する。そして、サンプルレイがどれだけ障害物アリになったかでその地点の密集度を判断し、その狭い分だけを黒く塗りつぶすのだ。そしてこれを画面に映る全てのピクセルについて繰り返す。

ここで、最大距離はサンプルレイが探索の為に進む距離（単位は環境設定による）、サンプルはレイの衝突地点から飛ばすサンプルレイの本数である。サンプルを増やすと精度は向上するが、当然レンダリング時間は伸びるので注意しよう。強度は塗りつぶす強さで、値を1にするとサンプルレイが全て「障害物アリ」になったときその地点を完全な黒色に塗りつぶす。

ここで注意したいのが前回説明した非平面ポリゴンとレイバイアスである。非平面ポリゴン上で上記のような障害物判定を行うと、Poserのレイトレースは非平面ポリゴン自身を障害物だと判断してしまうので、すべて「障害物アリ」、つまり強度が1なら真っ黒に塗りつぶされてしまうことになる。そこで、レイバイアスでレイが非平面の谷間を脱出するまでサンプルレイを飛ばさないように設定してやるのだ。

レイバイアスの単位も自分が環境設定で設定している単位による。距離は非平面を脱出できるぐらいあれば充分である。あまり大きく設定しすぎると、サンプルレイを飛ばす基準位置が本当に判定しなければならない障害物より遠ざかってしまう。ノイズが発生しない距離でなるべく小さめにするといいだろう。

マテリアルルームでAOを設定する場合、品質を細かくセッティングできるのが利点だが、逆に適用したいマテリアルに全てにノードを追加しなければならないので結構な手間になる。特に拡散IBLライトを使用すると、全ての材質に影を落とす必要が出てくるのでこれがかなり面倒臭い。そういうときは、マテリアルではなくライトにAOを設定する。

ライトの特性パレットで環境閉塞のチェックをONにすると、マテリアル設定に関わらず全てのオブジェクトにAOの効果が適用される。この時、最大距離、レイバイアス、そしてサンプル数はシーンＡＯオプションダイアログで、強度は上のダイヤルで設定する。

AOをライトに適用する場合、計算はライトごとに行われるのでAOの適用されたライトが当たらない部分にはAOの効果は適用されない。だからといってシーン内にやたらと多くのライトを読み込み、そのすべてにAOを適用するとレンダリング時間が飛躍的に増大するので、その場合はマテリアルで適用するようにしよう。

ライトの特性パレットでAOを適用するメリットは、すべてのオブジェクトに対する設定を一括で指定できるところだ。ただし、シーン内のオブジェクトの大きさに差がある場合、最大距離やレイバイアスをどのオブジェクトに合わせるかで効果はガラリと変わってしまう。小さいオブジェクトに合わせると大きなオブジェクトには不十分だし、大きなオブジェクトに合わせると小さなオブジェクトには暗過ぎるばかりか、非平面ポリゴンがある場合にはノイズを回避できなくなる。

また、ライトとマテリアルの両方でAOを適用した場合、効果は二重に適用されてしまう。レイバイアスや最大距離を似たような数値で設定すると、暗くなり過ぎるので気をつけよう。逆に拡散IBLライトを使用する時など、ライトのAOは背景小道具のような大きなオブジェクトを基準に数値を設定し、人物の服や目鼻など小さなパーツの陰影はマテリアル側のAOで描画するなど、効果的に使い分けるといいだろう。

また、ライトにAOを適用した場合、あまり効果を適用したくない部分（特に髪など非常に入り組んだところ）まで懇切丁寧に計算するので、レンダリング時間がとてつもなくかかってしまうことになる。もし、髪の毛などどうしてもAOを適用したくないオブジェクトがあるのなら、そのオブジェクトの特性パレットで「レイトレースで表示」のチェックを外してしまうのも有効だ。

「レイトレースで表示」のチェックが外れているオブジェクトはレイからは見えなくなり、あらゆるレイトレーシング計算の対象外になる。

ただ、例えば髪の「レイトレースで表示」のチェックを外した場合、当然頭皮なども髪が存在しないものとしてAOの判定を行うので、若干リアリティは低下するだろう。また、影にレイトレースシャドウを使用している場合は、影も落とさなくなってしまうので要注意。

さて、長らく続いたライティングのまとめも今回で一応終わりということになる。もちろん新しく知ったネタや未検証だった部分など、今までと同じく思い出したように取り上げることもあるだろうが、まずはこれで一区切り。

とりあえず一通りのことは網羅できたと思うが、少しはお役に立てただろうか。まだまだ自分も未熟だし、出来ない手法、解明できていない現象、伝えきれていない言葉が山のように残っている。それでも、何かほんの少しでも誰かの絵作りに影響を与えられたなら、そして喜んでもらえたのなら、こんなに幸せなことはないと思う。

果たして。

これがもともとレタッチTipsの前フリだったなんて、今更誰が信じるだろうか（爆）

■頂いたコメント■

»Read More

何が、というとコレ。

オブジェクト上のエッジに近い面に不正な光や陰が現れる問題である。
画像自体は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へのデータの移行での不自由はほぼ無くなったかな。