流転四界ぶろぐ

Poser 7日本語版で、バンプマップに異なるイメージファイルが適用されてしまう問題。どうも、本気で困っている人はあまりいないようだ。

というのも、未だに「どうにかしよう」という動きが見られないからである。

まともに検証されていらしたのはcasiopeaさんのブログぐらいで、あとはどこも起こった現象をただ騒ぎ立てているだけ、読むに値する情報はほとんどない。価値ある情報を集約しようという動きもない。だからきっと、誰も本気では困っていないのだ。ただ鬼の首を取ったように、他者を公然と攻撃できる機会を見つけて喜んでいるだけなのだろう。

Poserのマテリアルは、Poser 4以前に使用されていた形式（P4書式）と、Poser 5から採用されたシェーダツリー形式の部分から構成されている（P4書式はシェーダツリー形式の一部を記述しているので、Poser 4でPoser 5以降のデータを読み込んでも、一応なんとか表示はされる）。

長くPoserを使っていらっしゃる方々には周知のことだろうが、Poserはシーンファイルを開いた時やフィギュアや小道具をライブラリから読み込んだ時点では、P4書式のマテリアルのみを反映する。P4書式で指定されている画像はこの時にロードされるので、ファイルが見つからないとか怒られるのは、主にこのタイミングだ。シェーダツリーの内容は、この時点では反映されていない。

そして、マテリアルルームに入ったりレンダリングを開始したり、マテリアルに深く関わる操作を行うとシェーダツリーの内容を反映する。P4書式では記述されないツリー深部のイメージマップなどはこの時点でロードされるので、ヘタをするとロード時とレンダ時で二回テクスチャの所在を尋ねられたりする（実際にはもうちょっと違ったりもするのだが、大雑把に言うとこんな感じだ）。

Poser 4用のデータなど元々シェーダツリーを持たないデータは、マテリアルルームに入ったりした時点で初めてシェーダツリーが付加される。P4書式とシェーダツリーの内容が異なる場合は、シェーダツリーが反映された時点でP4書式を上書きする形になる。

さて。今回のバグについて、今までに見た情報を整理すると。

おそらく、最初にP4書式の記述によってロードされたイメージファイル用のメモリのアドレスだか何だかが、うまく保持されていないのではないだろうか？　そしてその部分に、シェーダツリーで最初にロードされるマテリアルグループの内容が入り込んでしまう。そして、P4書式でロードしたファイルはシェーダツリーの反映時にはロードされない（二度手間になるからだ）ため、「読み込んであるハズなのに存在しない・別のイメージを適用してしまう」という現象が起こる。

そう考えれば、バンプ用のイメージマップノードとの間に何らかのノードを挟むと、現象が発生しなくなるのも頷ける。ルートノードに直接接続されていないイメージはP4書式には記述されない。シェーダツリーを反映して初めてメモリに格納されるので、結果、事故を回避することになっている。

もっと詳しい条件が明らかになれば、シーンファイルをロードした時点でルートノードに直結している全てのバンプマップを読み込み直すようなPythonスクリプトを組むことも可能かも知れない（ただ、同名のイメージファイルは普通キャッシュされるので、確実に直るかどうかはわからない。複数のフィギュアが存在する場合に、一つだけイメージをロードし直せば全てが正常になるのはそのためだ）。

もっと詳しい条件とは、例えばシェーダツリーを反映しない時点でのメモリの状態はどうだとか、P4書式で記述される他のテクスチャマップ・トランスマップ・リフレクションマップはどうなっているのかとか、発生しない条件があるのかどうかとかいったことだ。

だがまあ、自分はこの問題を調べることはできない。自分はPoser 7は日本語版のユーザではなく、英語版のユーザだからだ。今更困難な目に遭う為に出費しようという気にはなれない。だから検証のしようもなければ、場凌ぎ対策を打っても動作確認すらできない。ホントの事を言ったら、口を出す立場でもないのかもしれない。第一、こういうことは、実際に困っている人が調べるべきだろう。どうでもいいとか、特に急ぎでないとかいうなら、黙ってSR1が出るまで待っていればいい（いつごろ出るのかはわからないが）。

誰も彼もに順序立てて検証する能力や、Poserに対する深い知識があるわけではない、というのは単なる言い訳に過ぎない。自分で調べられなくったって、ネット上の情報を探索したり集約することは一般社会人なら充分にできるはずだ。広く知恵を募ればいいのである。それもせずにいつまでもただバグだ、信じられない、などと騒ぎ立てるのは、無意味どころかネット上にゴミ情報を量産する意味では有害ですらある。これがバグであり、製品の品質や企業としての姿勢を疑われかねない問題であるのは、最初の数例報告が上がった時点で誰の目にも明らかなんだから。

思えば、Poser 6もリリース直後はマテリアル関係の不具合が多かった。イメージファイルが読み込まれない問題や、再現性は低かったものの、先頭にあるマテリアルグループのイメージが別のマテリアルグループに適用されてしまう問題にも遭遇したことがある。ここいらの暗黒の歴史は今でもSR1のリリースノートを参照すればよくわかる。

そして今、自分はPoser 7英語版を使用しているが、やはりマテリアルルーム関係でつっかかりを覚えている。クロスシミュレーションやセットアップルームの動作が（私が記憶している限りPoser 6リリース直後のように）不安定という話も耳にする。

まるで、Poser 7は英語版も日本語版も、Poser 6のService Releaseで改善された点をまるごと置き忘れてきたかのようである。

これはまったくの憶測だが、Poserというソフトそのものが、今のプログラマブルシェーダ（マテリアルルーム）やクロスシミュレータを、アプリケーションとして実装しきれていないのではないだろうか。Poserのシェーダやシミュレータは、外部の著名なエンジンを使用していると聞いた事がある。これらを完全にPoserに直結させることができていないが為に、パッチがあたっていない「素」の状態のPoserは、とても不安定でバギーなのではないだろうか。

本当のところはわからない。だが現状の不安定さ、頻発するバグは、Poserが抜本的に生まれ変わらない限り、いつまでもついて回るような気がして仕方がないのである。