上書きについての走り書き / 2007年02月26日
バンプの不具合の件。
前回アップロードしたファイルを数人の方にテスト頂いて、いくつかの事が明らかになった。
テストして頂いた有志の方に感謝しつつ、簡単にまとめてみると。
とりあえず不具合内容は、
「Poser 7日本語版でルートノードのバンプにイメージマップノードが直接接続されているフィギュアや小道具をロードすると、イメージマップノードのファイルが正常に読み込まれておらず、そのためレンダリングすると他のイメージが適用されてしまう」
である。これはマテリアルルームでイメージマップノードのファイル指定をイチからやり直すことで対処できる（回避じゃないぞ、遭遇してしまってるんだから）。複数のイメージマップノードで同じファイルが指定されている場合、Poserは1つのファイルを使い回すので、一回だけ指定してやれば全てのイメージマップノードが正常に戻る。
これを、もうちょっとなんとかならんか、ということでウダウダ考えている。
casiopeaさんのブログで、P7Jのファイルの記述が怪しいという記事を拝見した。シェーダツリーによるP4書式の上書きの法則性も知りたかったので、作成したファイルをP6JとP7Eで読み込んで動作を確認してみる。
使用したファイルはテストデータのNoP4、P4書式はNO_MAP指定で、シェーダツリーは ":runtime:textures:test:test1.jpg"という指定になっている。
まずはシーンファイルを開いた状態のP6J。
P4書式はサクられたまま、シェーダツリーではファイル名しか保存されていない。
また、ロード時にテクスチャを読み込んでいないので、テクスチャシェーディングにしていてもテクスチャは表示されない。
これがP7Eの場合はと言うと、
Mac版ではアプリケーションフォルダからの絶対パス（しかもスラッシュ区切り）に変わっている。
次に、このシーンをそのまま一度だけレンダリングし、ファイルを別名保存したところ（もちろんレンダ結果は正常である）。P6J。
ボカシで大変失礼だが、この部分はボリューム名：ユーザID：〜と続いている。基本的にMac版P6Jはファイル記述は全てボリュームからの絶対パスである。レンダリング時にシェーダツリーの記述によってファイルは読み込まれているはずだが、まだP4書式への上書きは行われていない。また、テクスチャシェーディングにもテクスチャは反映されていない。
P7E。
ここでシェーダツリーのファイルパスが何故か元のpz3の記述に戻っている。あとはP6Jと同様。
ここで、一度シーンファイルを閉じ、「Poserを終了せずに」同じファイルを開き直してみた。Poserは一度ロードしたファイルは、Poserを終了するまでその所在地を記憶している。この場合、P4書式をカットしていることがどう影響するか。というわけでP6J。
ファイルを開いた直後に、そのまま別名保存したものである。P4書式の部分にも絶対パスでファイル指定が入り、テクスチャシェーディングも始めから適用されている。
次にP7E。
こちらはRuntimeからの指定で、やはりP4書式が上書きされている。つまり、Poserはロードの時点で、ファイルの読み込みは行わないもののシェーダツリーを読み出していて、メモリ上に同名のファイルがあればさっさと適用してしまうようである。
さて、では最初のファイルを開いて、そのままマテリアルルームでマテリアルグループを一つだけ表示させ、その状態でファイルを別名保存してみよう。マテリアルルームの操作は、ファイルにどのように反映されているか。
P6Jでは、マテリアルルームに入り、マテリアルグループを選択した瞬間にその部分のテクスチャがテクスチャシェーディングに反映された。シーンファイルも、その時点でP4書式が上書きされていることがわかる。マテリアルルームで表示させていない部分の記述は最初のケースと同様だった。
P7Eでも同様である。
この一部だけテクスチャシェーディングが反映された状態で、一度ファイルを閉じて開き直してみよう。P6J。
やはり、一部のテクスチャシェーディングだけは反映、そしてP4書式への上書きも行われている。
P7Eでも同様。
さて。
と、いうことは、P4書式の上書き（というかP4書式とシェーダツリーの整合性のチェック）は、マテリアルルームで該当のマテリアルグループを操作した時、そしてフィギュアや小道具をロードした時に行われている、ということになりそうだ。ただし、ロード時にはシェーダツリー内のイメージの読み込みは行わない。その為、Poserを起動した直後の状態ではP4書式に上書きするべきファイルパスが見つからないためNO_MAPのままとなっている……という感じだろうか。
Poserは外部ファイルを読み込む時、実はファイル名でしかファイルを区別しない。だから別のディレクトリに同名のファイルが存在する場合、それは「同じもの」として扱われてしまい、さらに、「先にロードしたファイルのファイルパス」を意固地に保持している。
仮に、テクスチャを01.jpgと名付け、texturesフォルダ下に保存したとしよう。次にテクスチャを変えたくなって、別のファイルに同じ01.jpgと名付け、textures:testフォルダ下に保存する。すると、マテリアルルームでいくらtextures:test下の01.jpgを指定しようとも、あるいはtextures:test下の01.jpgを指定したファイルをロードしようとも、最初に読み込んだtexturesフォルダ下の01.jpgを表示してしまうのである。
これはテクスチャだけではなく、ジオメトリファイルでも同様である。大人しくファイル名を変更するか、Poserを終了してエディタでファイルパスを変更するしかない。この辺の仕様はPoser 7になっても変わらない。
とりあえず変更されるタイミングがわかったので……うーん……。
……保存時にサクっちゃうとか……どうだろ。
とりあえず、わふうてんまであとよっか。
前回アップロードしたファイルを数人の方にテスト頂いて、いくつかの事が明らかになった。
テストして頂いた有志の方に感謝しつつ、簡単にまとめてみると。
とりあえず不具合内容は、
「Poser 7日本語版でルートノードのバンプにイメージマップノードが直接接続されているフィギュアや小道具をロードすると、イメージマップノードのファイルが正常に読み込まれておらず、そのためレンダリングすると他のイメージが適用されてしまう」
である。これはマテリアルルームでイメージマップノードのファイル指定をイチからやり直すことで対処できる（回避じゃないぞ、遭遇してしまってるんだから）。複数のイメージマップノードで同じファイルが指定されている場合、Poserは1つのファイルを使い回すので、一回だけ指定してやれば全てのイメージマップノードが正常に戻る。
これを、もうちょっとなんとかならんか、ということでウダウダ考えている。
- どうやらライブラリからの追加やシーンファイルのオープンでフィギュアやプロップがロードされる時、同時に読み込まれるはずのバンプマップがまずいことになってしまうらしい。
- ロード時に読み込まれるのはマテリアルにP4書式で記述されているイメージファイルである。
- なので、このP4書式をサクってロード時のイメージファイル読み込みを行わなければ、シェーダツリーが適用された時にファイルは正常に読み込まれるので、問題を回避できる。
- これはマテリアルルームで手動対応するよりは、多少は楽かもしれない。
- マテリアルファイル、マテリアルコレクションファイル、MATポーズファイルを適用した場合にも同様の現象が起こるらしい。これが同じプロセスで発生しているのかどうかは不明。
- Poser 7Jでしか発生しないが、シーンファイル自体は英語のファイルでも発生する。
- 間違って適用されてしまうイメージファイルは、2度目のレンダリングからは先頭のマテリアルグループに存在するファイルだが、テスト結果を頂いた限り、1度目のファイルにも実は法則性があるっぽい。
casiopeaさんのブログで、P7Jのファイルの記述が怪しいという記事を拝見した。シェーダツリーによるP4書式の上書きの法則性も知りたかったので、作成したファイルをP6JとP7Eで読み込んで動作を確認してみる。
使用したファイルはテストデータのNoP4、P4書式はNO_MAP指定で、シェーダツリーは ":runtime:textures:test:test1.jpg"という指定になっている。
まずはシーンファイルを開いた状態のP6J。
P4書式はサクられたまま、シェーダツリーではファイル名しか保存されていない。
また、ロード時にテクスチャを読み込んでいないので、テクスチャシェーディングにしていてもテクスチャは表示されない。
これがP7Eの場合はと言うと、
Mac版ではアプリケーションフォルダからの絶対パス（しかもスラッシュ区切り）に変わっている。
次に、このシーンをそのまま一度だけレンダリングし、ファイルを別名保存したところ（もちろんレンダ結果は正常である）。P6J。
ボカシで大変失礼だが、この部分はボリューム名：ユーザID：〜と続いている。基本的にMac版P6Jはファイル記述は全てボリュームからの絶対パスである。レンダリング時にシェーダツリーの記述によってファイルは読み込まれているはずだが、まだP4書式への上書きは行われていない。また、テクスチャシェーディングにもテクスチャは反映されていない。
P7E。
ここでシェーダツリーのファイルパスが何故か元のpz3の記述に戻っている。あとはP6Jと同様。
ここで、一度シーンファイルを閉じ、「Poserを終了せずに」同じファイルを開き直してみた。Poserは一度ロードしたファイルは、Poserを終了するまでその所在地を記憶している。この場合、P4書式をカットしていることがどう影響するか。というわけでP6J。
ファイルを開いた直後に、そのまま別名保存したものである。P4書式の部分にも絶対パスでファイル指定が入り、テクスチャシェーディングも始めから適用されている。
次にP7E。
こちらはRuntimeからの指定で、やはりP4書式が上書きされている。つまり、Poserはロードの時点で、ファイルの読み込みは行わないもののシェーダツリーを読み出していて、メモリ上に同名のファイルがあればさっさと適用してしまうようである。
さて、では最初のファイルを開いて、そのままマテリアルルームでマテリアルグループを一つだけ表示させ、その状態でファイルを別名保存してみよう。マテリアルルームの操作は、ファイルにどのように反映されているか。
P6Jでは、マテリアルルームに入り、マテリアルグループを選択した瞬間にその部分のテクスチャがテクスチャシェーディングに反映された。シーンファイルも、その時点でP4書式が上書きされていることがわかる。マテリアルルームで表示させていない部分の記述は最初のケースと同様だった。
P7Eでも同様である。
この一部だけテクスチャシェーディングが反映された状態で、一度ファイルを閉じて開き直してみよう。P6J。
やはり、一部のテクスチャシェーディングだけは反映、そしてP4書式への上書きも行われている。
P7Eでも同様。
さて。
と、いうことは、P4書式の上書き（というかP4書式とシェーダツリーの整合性のチェック）は、マテリアルルームで該当のマテリアルグループを操作した時、そしてフィギュアや小道具をロードした時に行われている、ということになりそうだ。ただし、ロード時にはシェーダツリー内のイメージの読み込みは行わない。その為、Poserを起動した直後の状態ではP4書式に上書きするべきファイルパスが見つからないためNO_MAPのままとなっている……という感じだろうか。
Poserは外部ファイルを読み込む時、実はファイル名でしかファイルを区別しない。だから別のディレクトリに同名のファイルが存在する場合、それは「同じもの」として扱われてしまい、さらに、「先にロードしたファイルのファイルパス」を意固地に保持している。
仮に、テクスチャを01.jpgと名付け、texturesフォルダ下に保存したとしよう。次にテクスチャを変えたくなって、別のファイルに同じ01.jpgと名付け、textures:testフォルダ下に保存する。すると、マテリアルルームでいくらtextures:test下の01.jpgを指定しようとも、あるいはtextures:test下の01.jpgを指定したファイルをロードしようとも、最初に読み込んだtexturesフォルダ下の01.jpgを表示してしまうのである。
これはテクスチャだけではなく、ジオメトリファイルでも同様である。大人しくファイル名を変更するか、Poserを終了してエディタでファイルパスを変更するしかない。この辺の仕様はPoser 7になっても変わらない。
とりあえず変更されるタイミングがわかったので……うーん……。
……保存時にサクっちゃうとか……どうだろ。
とりあえず、わふうてんまであとよっか。
P7Eのバンプ / 2007年02月23日
複数箇所でP7Eのバンプの効きがイマイチだという記事を拝読した。私の答えは「シェーディングレートとテクスチャフィルタリング」だ。特殊解かもしれないが、以下導出過程。
Poser 7のFirefly周りで大きく変更されたことの一つに、テクスチャフィルタリングの設定がレンダリングオプションからマテリアルのイメージマップノードの項目になったことが挙げられる。テクスチャごとにONにするかOFFにするか決定できるようになったわけで、まあおおむね改善と言えるだろう。
ところで、テクスチャフィルタリングとは何だろうか？
私は以前自サイトのTips「レンダリング設定について」で、テクスチャフィルタリングとはテクスチャがレンダリング範囲に比べて細かすぎる時、フィルタをかけて自然にぼかすことでモアレの発生を防ぐ機能だ、と説明した。
さらに言い換えるなら、最小シェーディングレートによって設定されたマイクロポリゴンの分割サイズに応じて、テクスチャにフィルタをかけ最適化する機能、と言えるだろう。
テスト用の形状の、左は2DテクスチャのWeave（テキスタイル）を適用したもの。右はWeaveを適用した板ポリゴンを一度レンダリングして、テクスチャとして読み込んだイメージマップノードを接続したものだ。バンプ強度は1ミリ。
これを影無し・シェーディングレート0.2・テクスチャフィルタリングオン、つまり高画質な感じでレンダリングする。（以下4つの画像はクリックで原寸表示）
どちらも目立った違いはない。細部まで綺麗に表現されているし、Poser 6とPoser 7、Weaveとイメージマップの違いもない。
では、シェーディングレートを4ピクセルあたりにしてレンダリングしてみる。
イメージマップを使用した方がバンプの効きが弱くなっている。特にPoser 7の方は顕著だ。
では、テクスチャフィルタリングをオフにしてみよう。Poser 6ならレンダリングオプションで、Poser 7ならそれぞれのイメージマップノードでNoneにする。
すると、今度は汚くなったがバンプの効き自体は強くなった。Poser 6とPoser 7に違いはない。
Poser 7でバンプの効きが悪くなったと思ってしまうのは、テクスチャフィルタリングを使用していながら、シェーディングレートの値を上げてレンダリングしているからだ。Poser 7のテクスチャフィルタリングのデフォルト値は「Quality」なので、普通に低画質でレンダリングすると必然的にこうなってしまう。
ではなぜ、バンプの効きが弱くなるのだろう？ これは明白だ。
ぼかしフィルタがかかることによって、イメージそのものがボケているからである。
マイクロポリゴンは1枚につき一つの色を与えられる。シェーディングレートを大きくするということは、マイクロポリゴンの分割サイズを大きくするということだ。すると、マイクロポリゴン1つに与えられる色よりも、貼られたテクスチャの色の方がずっと多くなってしまう。
睫毛のトランスマップのような、輝度差の激しい詳細なテクスチャを想像してみよう。レンダリングイメージの1ピクセルよりも大きなマイクロポリゴンが、それよりもはるかに細かいテクスチャの、白い部分を拾うか黒い部分を拾うかで、レンダリング結果は大きく異なってしまう。モアレが発生し、マスカラがダマになったように汚れてしまうのである。
それを防ぐのがテクスチャフィルタリングだ。マイクロポリゴン1枚が約4ピクセルなら、だいたい4ピクセルが一つの色になるように、その都度テクスチャにぼかしをかける。白と黒が縞になっているのなら、混ぜて灰色にしてしまえばいい。そうやって見た目を改善するのである。
シェーディングレートがレンダリングイメージに対するパラメータであるのに対し、テクスチャの画素数は固定なので、マイクロポリゴン1枚に割り当てられるテクスチャの画素数はレンダ内容によって可変になる。カメラの中で対象が小さく（遠く）なればなるほど、テクスチャサイズが大きいほど、テクスチャのより広範囲にフィルタをかけなければならなくなるのだ。Poser 6以前で、テクスチャフィルタリングがリソースを大量消費してしまうのはそのためである。Poser 7ではその辺が抜本的に改良されたらしい（細かいことはまだわからないけど）。
ちなみに、2Dテクスチャや3Dテクスチャなどプロシージャルテクスチャは、始めからマイクロポリゴンのサイズに応じて生成される。フィルタリングもかからないので変化が見られないのである。
フィルタリングのデフォルト値が「Quality」であることは、Poser 6以前とPoser 7で共通するデータを使用する場合や配布物などには注意が必要になるだろう。バンプはシェーディングレートを上げれば鮮明にはなるが、完全に「None」の場合と同じにするのはマシンパワー的にも難しい。Poser 7用のマテリアルコレクションを作るか微妙なところだ。むしろ使用者がフィルタリングの効果についてもっとよく理解し、自分の求めるレンダリング品質に応じてコントロールするべきかもしれない。
自分はPoser 6では髪と頭だけテクスチャフィルタリングをオンにして部分レンダしていた。オンの状態での一括レンダはまず無理だから、というのが根本的な理由だが、やはり衣服や背景プロップのディティール（っていうかザラっとした感じ）が弱くなってしまうのが大きい。Poser 7でテクスチャごとに設定できるようになった点はありがたいが、できればレンダリングオプションでフィルタリングの一括オフが欲しかったところだ。シェーディングレートはActor単位とレンダリングオプションの両方で制御できるのだから、ここは一つ次バージョンで取り入れて欲しいところである。
……。
……さて。
前回のP7Jのバンプについては、ロード時に（P4書式による）イメージ読み込みを行わなければ、とりあえず回避できるところまでは明らかになった。が、P4書式を削除してもマテリアルルームに入れば元に戻ってしまうし（要らんのに…）、そもそもシェーダツリーを持たないP4データにはこれっぽっちも歯が立たない。
というわけで、P7Eで作成した2バイト文字を含まないテスト用シーンファイル。
お心の広いP7J使いの方、どうか……。
（2007年2月26日追記）
テストデータのリンクを削除しました。テストに御協力頂いた方、ありがとうございました。
……。
…………ああ。
…………こんな事してる暇があったら。
ああああぁ（弱）
Poser 7のFirefly周りで大きく変更されたことの一つに、テクスチャフィルタリングの設定がレンダリングオプションからマテリアルのイメージマップノードの項目になったことが挙げられる。テクスチャごとにONにするかOFFにするか決定できるようになったわけで、まあおおむね改善と言えるだろう。
ところで、テクスチャフィルタリングとは何だろうか？
私は以前自サイトのTips「レンダリング設定について」で、テクスチャフィルタリングとはテクスチャがレンダリング範囲に比べて細かすぎる時、フィルタをかけて自然にぼかすことでモアレの発生を防ぐ機能だ、と説明した。
さらに言い換えるなら、最小シェーディングレートによって設定されたマイクロポリゴンの分割サイズに応じて、テクスチャにフィルタをかけ最適化する機能、と言えるだろう。
テスト用の形状の、左は2DテクスチャのWeave（テキスタイル）を適用したもの。右はWeaveを適用した板ポリゴンを一度レンダリングして、テクスチャとして読み込んだイメージマップノードを接続したものだ。バンプ強度は1ミリ。
これを影無し・シェーディングレート0.2・テクスチャフィルタリングオン、つまり高画質な感じでレンダリングする。（以下4つの画像はクリックで原寸表示）
どちらも目立った違いはない。細部まで綺麗に表現されているし、Poser 6とPoser 7、Weaveとイメージマップの違いもない。
では、シェーディングレートを4ピクセルあたりにしてレンダリングしてみる。
イメージマップを使用した方がバンプの効きが弱くなっている。特にPoser 7の方は顕著だ。
では、テクスチャフィルタリングをオフにしてみよう。Poser 6ならレンダリングオプションで、Poser 7ならそれぞれのイメージマップノードでNoneにする。
すると、今度は汚くなったがバンプの効き自体は強くなった。Poser 6とPoser 7に違いはない。
Poser 7でバンプの効きが悪くなったと思ってしまうのは、テクスチャフィルタリングを使用していながら、シェーディングレートの値を上げてレンダリングしているからだ。Poser 7のテクスチャフィルタリングのデフォルト値は「Quality」なので、普通に低画質でレンダリングすると必然的にこうなってしまう。
ではなぜ、バンプの効きが弱くなるのだろう？ これは明白だ。
ぼかしフィルタがかかることによって、イメージそのものがボケているからである。
マイクロポリゴンは1枚につき一つの色を与えられる。シェーディングレートを大きくするということは、マイクロポリゴンの分割サイズを大きくするということだ。すると、マイクロポリゴン1つに与えられる色よりも、貼られたテクスチャの色の方がずっと多くなってしまう。
睫毛のトランスマップのような、輝度差の激しい詳細なテクスチャを想像してみよう。レンダリングイメージの1ピクセルよりも大きなマイクロポリゴンが、それよりもはるかに細かいテクスチャの、白い部分を拾うか黒い部分を拾うかで、レンダリング結果は大きく異なってしまう。モアレが発生し、マスカラがダマになったように汚れてしまうのである。
それを防ぐのがテクスチャフィルタリングだ。マイクロポリゴン1枚が約4ピクセルなら、だいたい4ピクセルが一つの色になるように、その都度テクスチャにぼかしをかける。白と黒が縞になっているのなら、混ぜて灰色にしてしまえばいい。そうやって見た目を改善するのである。
シェーディングレートがレンダリングイメージに対するパラメータであるのに対し、テクスチャの画素数は固定なので、マイクロポリゴン1枚に割り当てられるテクスチャの画素数はレンダ内容によって可変になる。カメラの中で対象が小さく（遠く）なればなるほど、テクスチャサイズが大きいほど、テクスチャのより広範囲にフィルタをかけなければならなくなるのだ。Poser 6以前で、テクスチャフィルタリングがリソースを大量消費してしまうのはそのためである。Poser 7ではその辺が抜本的に改良されたらしい（細かいことはまだわからないけど）。
ちなみに、2Dテクスチャや3Dテクスチャなどプロシージャルテクスチャは、始めからマイクロポリゴンのサイズに応じて生成される。フィルタリングもかからないので変化が見られないのである。
フィルタリングのデフォルト値が「Quality」であることは、Poser 6以前とPoser 7で共通するデータを使用する場合や配布物などには注意が必要になるだろう。バンプはシェーディングレートを上げれば鮮明にはなるが、完全に「None」の場合と同じにするのはマシンパワー的にも難しい。Poser 7用のマテリアルコレクションを作るか微妙なところだ。むしろ使用者がフィルタリングの効果についてもっとよく理解し、自分の求めるレンダリング品質に応じてコントロールするべきかもしれない。
自分はPoser 6では髪と頭だけテクスチャフィルタリングをオンにして部分レンダしていた。オンの状態での一括レンダはまず無理だから、というのが根本的な理由だが、やはり衣服や背景プロップのディティール（っていうかザラっとした感じ）が弱くなってしまうのが大きい。Poser 7でテクスチャごとに設定できるようになった点はありがたいが、できればレンダリングオプションでフィルタリングの一括オフが欲しかったところだ。シェーディングレートはActor単位とレンダリングオプションの両方で制御できるのだから、ここは一つ次バージョンで取り入れて欲しいところである。
……。
……さて。
前回のP7Jのバンプについては、ロード時に（P4書式による）イメージ読み込みを行わなければ、とりあえず回避できるところまでは明らかになった。が、P4書式を削除してもマテリアルルームに入れば元に戻ってしまうし（要らんのに…）、そもそもシェーダツリーを持たないP4データにはこれっぽっちも歯が立たない。
お心の広いP7J使いの方、どうか……。
（2007年2月26日追記）
テストデータのリンクを削除しました。テストに御協力頂いた方、ありがとうございました。
……。
…………ああ。
…………こんな事してる暇があったら。
ああああぁ（弱）
最近、モヤモヤしていること / 2007年02月21日
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が抜本的に生まれ変わらない限り、いつまでもついて回るような気がして仕方がないのである。
というのも、未だに「どうにかしよう」という動きが見られないからである。
まともに検証されていらしたのは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が抜本的に生まれ変わらない限り、いつまでもついて回るような気がして仕方がないのである。
再びやって参りましたよ。 / 2007年02月16日
えー……。
Jezzさんすみませんすみませんすみません（平伏）。なんか曲解且つ暴走している模様です（汗）
というわけで。
再び拙宅に「貴方の３Ｄ絵に登場した、あのキャラのことが知りたーい！」バトンが巡ってきた。今度はなんとJezzさん宅のゼニス（伊香川）氏から直々に、KOD'sのギタリスト・ユーティを御指名である。……いつの間に仲良くなってんだ、おまいら。うらやましいぞ、くそう（本音）
今回は多分読んでらっしゃる方に対する失礼はないと思うが、自己主張度の高いキャラであるため別の意味で色々心配だったりして（笑）。まあいいや。
ちなみにバトンの原文はseisuiさんのブログかroseさんのブログで確認することができる。
また、ＡさんとＢさんのバトン記事なども参照いただくといいかもしれない。
では、始めよう。
＊
１．親御さんにお願い。キャラを１５文字以内で紹介してください。
前向きで不純でお人好しな君主。
（※君主はWIZの職業名なので、別に領地を持ってたりするわけではない）
２．親御さんにお願い。キャラのリソースを教えてください。
ベースフィギュアはまいこーさんRR。顔は自作、標準体形。Ken1さんのPGM3RR02に自作まいこーさん皮（Ｂさん皮）とAery SoulさんのLunaを配合、眉はDarya。髪はLisbethさんのParis Hair（レンダロフリー）をテクスチャの色替えで。
３．親御さんにお願い。主に使用している２Ｄ、３Ｄソフトを教えてください。
前回答えたソフトに加えて、Hexagon（UV展開器）、mi（エディタ）。
それからMaconverter、Thumbnailer、CleanArchiverは配布物作成の三種の神器（笑）
さて、ここからはお待ちかね（？）、本人登場である。ついでに真面目なプロモ画を撮り下ろし。
４．お名前は？
「ユーティ。綴りは似てるけどジュディさんじゃないよ」
５．おいくつですか？
「今年22…あれ、3だったっけ？ なんか起きてから感覚無くなっちゃったんだよねー。……え？ ああ。僕、5年間意識不明やってたから。っていうのはこっち（バンド）設定なんだけど。んーっとね、15まで普通にパブリックスクール行ってましたー、ある日目が覚めたらハタチ越えてましたー、みたいな感じ？ あっはっは。『中身は十代』って言ってる※のは、まあそういうコト。これ、そのうち作者がネタでやると思うよ。いつになるかわからないけど」
６．持っているレアアイテム(３Ｄ)を教えてください。
「えーっと、自作とか改変モノは含まないんだよね？ うーん、僕はせりちゃんからもらったファンレターかなー。特大の。あれは嬉しかったな。似顔絵がまた上手でさ」
７．（親御さんに対する）悩みはありますか？
（恥ずかしいポーズ談などを聞かせてください。証拠画像があればLINKしてください）
「これねぇ！（←いきなりトーンが上がる） 最近スレスレなネタばっかり僕のところに持ってくるの、ひどいと思わない？ やるのは別にいいんだけどさ、それで僕が主犯みたいに書き立てるのはやめて欲しいなぁ。僕の人格は作者が形成してってるんだからさ、せめて共同責任にしてよ。それに、どうせ際どいネタやるんだったらさ、女の人と絡ませて欲しいな。そういうのは全部彼（※Ａさん）が持ってっちゃうんだもの、不公平だよ」
８．お好きな衣装と苦手な衣装は？
「好きな服は……BAT laboratory謹製の礼服とか。仕立てがすごく良くって。あとBilly Factory製のボトム、合わせやすくて好き。今穿いてるコーデュロイパンツも、これブランドはRock Styleなんだ。いいでしょ（笑）。一枚モノはハデ柄が好きだなー。古着屋とかさ、セールやってるとつい買い込んじゃうんだよね。5枚で1ゴールド（約5百円）のシャツとか（笑）。そういうのはもう、パッと一回着たら終わりだけど……やっぱり、いつも着回すのはちゃんとしたところの、いいモノになっちゃう。ステージ衣装兼用だしね……貧乏だから。あはは。苦手なのは……夏に着た着流しはちょっとショックだったかな。首がね、長く見えちゃってバランス悪くって。同じ体形のアランはそんなことなかったから、髪型かなぁ。結構ね……いつも苦労してるんだ、実は」
９．３Ｄアイテムは主にどこで仕入れますか？
（お買い物、フリーモノなど、差し支えなければサイト名を教えてください…）
「彼らから答えさせてもらってるから、僕から付け加えることはあまり……『こういう服が着たい』っていうのは結構あるんだけどさ、売ってないから……。自作してると今度は逆に、僕らが表に出る仕事が減っちゃうし。服はまだまだ足りないよねぇ。ね、そう思わない？」
１０．貴方が保存されているライブラリについて２言
「んー……。僕ら3人、通常版の他に着衣版で保存されてるんだよね。けど、そうすると後でマテリアルを調整したやつとか、バージョンが合わなくなっちゃって……気になるっていうか、大丈夫なのかなって……。あ、でもこういうこと言うと作者がヘンなプレッシャー感じるみたいだからさ、やっぱり今のナシで。え、ダメ？ これ生？ あっそうだ！ こないだ見つけたんだけどさ、隣の建屋（商用不可Runtime）に新しいギターとかエフェクターとか積んであるんだ。あれって僕用だよね。早く演ってみたいなぁ！ ねぇライブやろうよ、ライブ！」
＊
こいつもよく喋るなぁ……（誰のせいだ）。
転職に伴う5年の老化現象は、WIZをプレイされたことがある方なら誰もが知っているシステムである。これをそのままバンド物語設定に持ち込むのはかなり無理があるのだが、こいつに限って言えば人格形成に関わるギミックとして使えるんじゃなかろーか、というわけで無理を承知で採用。ウィードのトンデモ設定と共に、そのうちネタにまとめてUPするかもしれない。少なくともストーリーを進める前には……って、いつになるやら。
では、次のバトンの送付先。せっかくなのでユーティ自身に紹介してもらおう。
「ねぇ、これって公開ナンパ？（笑） ああウソウソ、冗談だって。ちょっと待ってね、こんなチャンス滅多にないからさ、この機会に声をかけたいコがたくさん……たくさんはダメ？ ちぇー。じゃあね、まずは……sannziさんちのMiu Jさん。色んな役をこなしていらっしゃるんだけど、どれも雰囲気あるんだよね。それに美人だしさ、いっぺんお話ししてみたいなーって。……それから、きゃりばーさん宅の澤渡舞さん。カッコよくっていかにもプロって感じだよね。それに24話だっけ。あれでグッと来ちゃってさー。それから……え？ もうこのへんで？ ホントにダメ？（←上目遣い） ……ちぇ、わかったよ。じゃあ、今言った御二方、どうかよろしくお願いします！（威勢よく頭を下げる）」
＊
……なんか、書いてて恥ずかしくなってきた（爆）
というわけでsannziさん、きゃりばーさん、こんなヤツからのバトンですが、どうかよろしくお願いします。
とりあえず進捗というか…… / 2007年02月14日
真紅の法衣はモデルを2度ほど作り直してみたものの、やはり片側（向かって左側）だけがずり落ちてしまう現象に変わりはない。
仕方ないのでクロスのパラメータで、伸縮抵抗や剪断抵抗の値をハネ上げることで多少の軽減を試みる。
まだちょっと許容範囲というには遠いのだが、原因がハッキリしない時に完璧を目指しても成果が上がるはずもなく。とりあえず正面から撮らなければなんとか……というところでキリをつける。
ヒダヒダが弱くなっちゃったなぁ。
腰紐の部分は、今までやっていた「衝突対象で直接絞り込む」方法から、Poser Fashionのチュートリアルに掲載されている「フィギュアを使って強制グループで変形させる」方法に変えてみる。
やり方を変えてみた理由は、現状だとフィギュアの姿勢によっては衝突対象が布を突き破ってしまい、制御不能になるケースが結構多いからだ。その点、強制グループは「ペアレントされているフィギュアの中で、衝突対象となっているパートのデフォーミングを受ける」という仕組みとなっている。デフォーミングというのはつまり拡大縮小とか、ジョイントチャンネルによる変形である（モーフチャンネルの影響を受けるかどうかは試していない）。この場合は強制グループは衝突の判定を行わないので、衝突対象を貫通してしまうこともなく、確実に絞り込むことができるわけだ。
ただ、この場合強制グループに割り当てられた頂点は文字通り縮小してしまう。つまり、紐でくくって布を折るような変形ではなく、裏にゴムを縫い込んだみたいな変形になるというわけだ。果たしてどちらが良いのかは微妙なところ。また変えるかもしれない。
とりあえずこれで法衣の方は一段落して、腰紐もちゃんと仕立てようと思う。今までただの小道具だったから、毎回毎回位置合わせが手間だったのだ。ちゃんと着用一発できるようにしよう。
で、Ａさん用ができたらＢさん用とまいこーさん標準体形用を作って、肩飾りと肩掛も作って……。
ホントは今頃2月画を仕上げているはずだったんだけど、なんかもうこの際だから優先で。
大変恐縮ながらJezzさんからバトンを頂いた。次回のエントリを請う御期待（！？）
仕方ないのでクロスのパラメータで、伸縮抵抗や剪断抵抗の値をハネ上げることで多少の軽減を試みる。
まだちょっと許容範囲というには遠いのだが、原因がハッキリしない時に完璧を目指しても成果が上がるはずもなく。とりあえず正面から撮らなければなんとか……というところでキリをつける。
ヒダヒダが弱くなっちゃったなぁ。
腰紐の部分は、今までやっていた「衝突対象で直接絞り込む」方法から、Poser Fashionのチュートリアルに掲載されている「フィギュアを使って強制グループで変形させる」方法に変えてみる。
やり方を変えてみた理由は、現状だとフィギュアの姿勢によっては衝突対象が布を突き破ってしまい、制御不能になるケースが結構多いからだ。その点、強制グループは「ペアレントされているフィギュアの中で、衝突対象となっているパートのデフォーミングを受ける」という仕組みとなっている。デフォーミングというのはつまり拡大縮小とか、ジョイントチャンネルによる変形である（モーフチャンネルの影響を受けるかどうかは試していない）。この場合は強制グループは衝突の判定を行わないので、衝突対象を貫通してしまうこともなく、確実に絞り込むことができるわけだ。
ただ、この場合強制グループに割り当てられた頂点は文字通り縮小してしまう。つまり、紐でくくって布を折るような変形ではなく、裏にゴムを縫い込んだみたいな変形になるというわけだ。果たしてどちらが良いのかは微妙なところ。また変えるかもしれない。
とりあえずこれで法衣の方は一段落して、腰紐もちゃんと仕立てようと思う。今までただの小道具だったから、毎回毎回位置合わせが手間だったのだ。ちゃんと着用一発できるようにしよう。
で、Ａさん用ができたらＢさん用とまいこーさん標準体形用を作って、肩飾りと肩掛も作って……。
ホントは今頃2月画を仕上げているはずだったんだけど、なんかもうこの際だから優先で。
大変恐縮ながらJezzさんからバトンを頂いた。次回のエントリを請う御期待（！？）
うわぁああぁん / 2007年02月11日
クロスシミュレーションが上手くいかないよぅ〜（号泣）
法衣のリニューアル版。いい加減PoserもDCもよくわかってなかった頃のモデルをいつまでも使い続けるのも色々アレなので、とようやくスキを見て作り直してみたのだけど、肝心のシミュレーションが上手くいかない。
何度繰り返しても、完全に左右対称なモデルのはずにも関わらず、服の片側だけがでろーんと伸びてしまうのである。
ジオメトリが完全に左右対称なのは間違いない。片側は反転コピーで作ったものだし、モデルの操作はしてないんだから違いができるはずがない。再テストだってしている。
衝突対象のJames Hi Resが左右非対称で、その影響が出ているのかもしれないのかとも考えたが、基本小道具や自作の完全シメントリなダミーオブジェクトを衝突対象に差し替えても結果は同じ。
モデルを左右反転させても同じ。
P6JでもP7Eでも同じ。
頂点番号・UV値を変えてみたりしても同じ。
袖や裾の折り返しや襟や袖自体を削除した簡易モデルでも同じ。
決まって向かって左側が伸びてしまうんである。
あと何が原因として考えられるだろう……（苦悩）
簡易モデルのシミュレーション中の動きを観察して気付いたことは、どうも衝突判定の時点で左右の違いが出ているっぽいこと。ひょっとしたらこのシミュレーション、衝突判定は右から順番に解決しているとかそんな感じなんだろうか……。
三角ポリゴンは四角ポリゴンより稜線が多いし普通目が細かくなるから、その所為で伸びやすくなってるのもあるんだろう。頂点数約16000、稜線数約46000、面数約30000。シミュレーションは走りさえすれば計算自体はそこそこ快適なのだが……。とりあえず、目を粗くする方向で作り直すしかないかなぁと考えている。
あと、裾の途中でメッシュを細かくしたら、案の定伸び具合が変わって目立つようになってしまったので、その辺も併せてやり直し。
せっかく袖のあたりは良くなったんだけどな〜。
そんなこんなで2日のタイムロス。
モデリング担当と絵作り担当とネタ担当で、あと三人は自分が欲しいと思う今日この頃。
法衣のリニューアル版。いい加減PoserもDCもよくわかってなかった頃のモデルをいつまでも使い続けるのも色々アレなので、とようやくスキを見て作り直してみたのだけど、肝心のシミュレーションが上手くいかない。
何度繰り返しても、完全に左右対称なモデルのはずにも関わらず、服の片側だけがでろーんと伸びてしまうのである。
ジオメトリが完全に左右対称なのは間違いない。片側は反転コピーで作ったものだし、モデルの操作はしてないんだから違いができるはずがない。再テストだってしている。
衝突対象のJames Hi Resが左右非対称で、その影響が出ているのかもしれないのかとも考えたが、基本小道具や自作の完全シメントリなダミーオブジェクトを衝突対象に差し替えても結果は同じ。
モデルを左右反転させても同じ。
P6JでもP7Eでも同じ。
頂点番号・UV値を変えてみたりしても同じ。
袖や裾の折り返しや襟や袖自体を削除した簡易モデルでも同じ。
決まって向かって左側が伸びてしまうんである。
あと何が原因として考えられるだろう……（苦悩）
簡易モデルのシミュレーション中の動きを観察して気付いたことは、どうも衝突判定の時点で左右の違いが出ているっぽいこと。ひょっとしたらこのシミュレーション、衝突判定は右から順番に解決しているとかそんな感じなんだろうか……。
三角ポリゴンは四角ポリゴンより稜線が多いし普通目が細かくなるから、その所為で伸びやすくなってるのもあるんだろう。頂点数約16000、稜線数約46000、面数約30000。シミュレーションは走りさえすれば計算自体はそこそこ快適なのだが……。とりあえず、目を粗くする方向で作り直すしかないかなぁと考えている。
あと、裾の途中でメッシュを細かくしたら、案の定伸び具合が変わって目立つようになってしまったので、その辺も併せてやり直し。
せっかく袖のあたりは良くなったんだけどな〜。
そんなこんなで2日のタイムロス。
モデリング担当と絵作り担当とネタ担当で、あと三人は自分が欲しいと思う今日この頃。
なにやら飛んで来ましたよ（Ａ面）。 / 2007年02月09日
えー……。
再び某薔薇館の女帝ペンギン様からバトンが巡ってきた。今度はPoserキャラに対するバトンだ。
題して「貴方の３Ｄ絵に登場した、あのキャラのことが知りたーい！」バトン。震源地は闇部隊特別顧問ことseisuiさんのミラクル変形レシーブ（笑）。その内容はPoserキャラに自分自身と家主のことを語ってもらうというPoser界ならではの企画である。そして拙宅に対してはこともあろうにＡさん指定である（笑）。まさに光栄の極み、恐悦至極、戦戦慄慄、阿鼻叫喚（ぇ）。
Poserワーク開始当初から主役を張るウチの看板キャラではあるものの、とても聖職者には見えない言動と行動を繰り返し（いや半分ぐらいは自分のせいだけども）、時にいい人フラグが立ったりオーバーワークでShade世界にサボりに行ったりするＡさん。「謎が多い」とも「よくわからない」とも言われるのは当然かもしれない。
そこで不安はあるものの、今回Ａさんにはできるだけ営業要素のない「素」に近い状態で答えてもらうことにした。以下の彼の発言はキャラとしての発言であって、Kyotaro自身に作為があるわけではないので、読んでもどうか気分を害されないよう御容赦頂きたい。
と同時に、「まっとうな聖職者」であるＢさんにも同時に答えてもらうことにした。二人の発言を比較してもらえれば、彼ら、そして彼らそれぞれのことが少しわかりやすいかもしれない。
Ｂさんへのインタビューはこちらから！
＊
１．親御さんにお願い。キャラを１５文字以内で紹介してください。
Wizな世界の悪の僧侶。
２．親御さんにお願い。キャラのリソースを教えてください。
使用フィギュアはPoser 6 James詳細。ぽざくらのブログを最初からご覧になられている方には既知のことだけども、ほぼ全てが手作りである。詳しくは過去ログ「メンバー紹介vol.1」の辺りを参照していただければと思う。
３．親御さんにお願い。主に使用している２Ｄ、３Ｄソフトを教えてください。
こちらは自サイトに記載している通り、Photoshop CS・Shade8.5Pro・Poser 6J。
Macと優秀なテキストエディタと根気さえあれば、これで充分なんとかなると思う。
さて、というわけであとはＡさん本人に回答していただこう（もーどうなっても知らないぞー）。
４．お名前は？
「過去ログを参照して下さい」
５．おいくつですか？
「年が明けたので24……ですね。もっとも、こちらの世界では去年も24でしたし、来年もおそらく同じでしょうが」
６．持っているレアアイテム(３Ｄ)を教えてください。
「希少であることと、そのもの自体に価値があるかどうかは等価ではありませんよ。どれほど現在の所有者が少なく、いかに今後も増える見込みが極少であろうとも、たかだか過去の3Dデータに特筆すべき価値があるとは思えませんね。付加価値というものは……いや、そうですね……（←と、もったいぶって視線を逸らす）。一つ、あなた方がお望みのような『もの』に心当たりがあります。のちほど、御紹介致しましょう（←そして意味あり気な笑み）」
７．（親御さんに対する）悩みはありますか？
（恥ずかしいポーズ談などを聞かせてください。証拠画像があればLINKしてください）
「悩みを抱えるほど私にとって関心を払うべき人物ではありませんね（仮にあったところで、ここでそれを漏らすことに何か利点でも？）。どうやら、雇用者との確執といったゴシップ要素を期待されているようですが……（←なんか馬鹿にした目つき）。オファーを頂ければ戒律に背かない範囲で検討させて頂きますよ。ええ、もちろん報酬の話はそれからになりますがね。今までに請け負った仕事でしたら、クライアントの意向で非公開となっているものを除き、可能な限り公開されています。ご覧頂ければおわかりになるでしょう」
８．お好きな衣装と苦手な衣装は？
「好悪の感情で衣服に注文をつけるような真似はしませんよ。実際、選り好みするほど選択肢があるわけじゃありませんしね（←皮肉な笑み）。私が他キャラの流用品にクレームを出すのは、それを着用することが看板キャラの、またサイト自体のプロモーションに支障をもたらさないかと作者に再考を促しているからです（←と言いつつ微妙にプライドに抵触している模様）。真紅の法衣の品質が向上し、戦装備が完成するなら、それ以上言うことはありません」
９．３Ｄアイテムは主にどこで仕入れますか？
（お買い物、フリーモノなど、差し支えなければサイト名を教えてください…）
「これは私に向けての質問ではありませんね？ まあ、いいでしょう。背景類は主にDAZかRenderosityからの購入です。逆に小道具類はフリー物をその都度調達する姿勢のようです。Shade WEBのフリーパック（割引セール時に購入）で『落としまくった』Shadeの森シリーズのコンバート品も有用ですね。フリーの紳士服は皆無に等しいので言及するまでもないでしょう。仕入れ先は主にDAZ、Renderosity、RDNA。購入に踏み切るかどうかは、需要より好みに左右されることが多いようです。またイメージに合うものがない場合は自作もしています」
１０．貴方が保存されているライブラリへ２言
「複数のランタイムで重複する階層やファイルが散見されますねぇ。移行途中と釈明しているようですが、さて、いつまでかかるやら。作者の管理能力の限界が知れるというものです」
＊
えー……。ごめんなさいごめんなさいごめんなさい（土下座）
こんな奴です、すみません。基本的に他人に喧嘩を売らせる術には事欠かない奴です。むかついてしまったらＡさんの思う壷です。ここはお一つ、どうかご寛恕を……。バトンを回して下さった方には非常に申し訳ないと言うかなんというか。答えない方が良かったような……（冷汗）
それはさておき。兎にも角にもバトンの送付先である。
Ａさんが後ほど紹介すると言い、自分が所有する3Dデータの中で、ほとんど唯一とも言える希少かつ価値のある「もの」……いや、「者」。Ａさん自身とも因縁浅からぬ仲であり、そんな因縁ができてしまった事自体が非常に貴重だと思われる、彼にこそ次のバトンを渡したいと思う。
雷華女史宅の愛に殉ずる侍・小曽根健太郎さん（爆）
こんな奴からのバトンですが、どうか広ーい御心で受け取って下さいますよう……。
Winter JacketのG2/M3版 / 2007年02月03日
UPしました。サーバの容量とか転送量とかの都合上、テクスチャは同梱しておりません。お手数ですがJames/Koji版をダウンロードしてインストールして下さい。
James/Koji版とG2/M3版を全部ひっくるめたバージョンを後ほどぽざくらにUPする予定です。ファイルが一杯あってややこしい、という方はそちらをインストールしていただければ分かりやすいかと思われます。
いじょう。
James/Koji版とG2/M3版を全部ひっくるめたバージョンを後ほどぽざくらにUPする予定です。ファイルが一杯あってややこしい、という方はそちらをインストールしていただければ分かりやすいかと思われます。
いじょう。
うわー、そういうことか。 / 2007年02月01日
Winter Jacket for James/Kojiをダウンロードされた方にお知らせです。
CR2ファイルを改善した修正版を2007年2月1日19時ごろにUPしています。それまでにファイルをダウンロードされていた方は、お手数ですが再ダウンロードをお願い致します。
＊
不備があったというか、まあ認識しつつリリースしていたわけだけども。元々のジャケットは、FBMを適用しつつ裾部分を軸回転させると、関節の繋ぎ部分が分離してしまう。
テスト段階で気がついていたのだけど、どのパートのどのJPを何度調整しても改善が見られないので、そういうものなんだろうと諦めてしまったのだ。無知の無恥とはかくも恐ろしいものである（他人事みたいに）。というか、売り物で似たようなものがあったので、それで納得してしまったというか……（←言い訳）。
ところが、M3用にリサイズしてFBMを仕込みつつJP調整していたら、ちゃんとなだらかに変化していることに気がついたのだ。
だったら何か違いがあるんだろうと思って、あちこちいじってみるものの上手く行かない。
まずはFBMを使っていない状態での軸回転。回転の開始点がギリギリchestパートにかかるようにしてある。
ところが、これがモーフを適用するとchestとtrunkで動き方が違ってしまう。
そこでとりあえず、胴体が回転しないように影響範囲をずらしてみる。すると、胴体は影響範囲外であるにもかかわらず、モーフによる変形がかかるとやっぱり回転してしまうんである。
とりあえず屈伸・横屈伸・軸回転すべてこんな感じなので、JPがおかしいんだろーなー、とCR2を眺めても、M3のCR2とは値が少し異なるだけでチャンネル内の中身は変わらない。
そしたらふと、James/Koji版はモーフチャンネルが一番後ろに並んでいることに気がついた。
普通に「モーフターゲットの追加」で追加されたモーフチャンネルは、チャンネルの冒頭に加えられるはずなのだが、マグネットで生成したからか、とにかくFBMモーフはJPチャンネルより後ろに並んでいる。以前、JPをコピー＆ペーストで別のパートに適用させた時に、親に対するJPは他のJPより後ろに記述しないといけなかったことを思い出して、モーフチャンネルを先頭に移動させてみた。
……そうか、そういうことか。
つまり、targetGeomもjointもrotateもOffsetAもtaperも、操作内容が違うだけでやってることはみんな同じなんだ。どのチャンネルも、「そのパートの頂点に対して変位をかける」という役割は変わらない。ただtargetGeomとかjointとかいう冒頭のキーワードによって、直線移動したりある地点から回転させたり、フレームごとにモーフターゲットの内容を変化させたり、そういう変位の内容が変わるだけなんだ。そしてPoserは、その「パートに対する変形」の操作を、チャンネルが並んだ順番に機械的に処理していく。
rotateのxyzの順番で回転順序が決定するのも、その順番でPoserが特殊な判別をしているとかそういうことではなくて、ただ単にその順番でパートを回転させる計算をしているだけなのだ。だから、JPチャンネルが一番後ろにないと上手く変形しないのも、Scaleなどの変形がかかるとモーフが狙った変形をしないのも、様々な現象が「その順番で頂点の変位を計算しているから」と考えれば、すべて一本の線に繋がっていく……ような気がする（爆）。まだなんも検証してないから仮説だけど。
うわー、やっとほんのちょっぴり理解できた。だとしたらものすごく、PoserのCR2は明解だ。清々しいと言ってもいい。キーワードごとの動作を細かく理解しないと、結局今までと何も変わらないことなんか気にならないぐらい爽快だ（笑）
……いやまあだから。その。
そういうわけでJames/Koji版、手直ししたのですみませんがもう一度ダウンロードして下さい。
ついでにM3版はJP調整終了、G2版はこれからです。
すみませんすみませんすみません（低頭）
CR2ファイルを改善した修正版を2007年2月1日19時ごろにUPしています。それまでにファイルをダウンロードされていた方は、お手数ですが再ダウンロードをお願い致します。
＊
不備があったというか、まあ認識しつつリリースしていたわけだけども。元々のジャケットは、FBMを適用しつつ裾部分を軸回転させると、関節の繋ぎ部分が分離してしまう。
テスト段階で気がついていたのだけど、どのパートのどのJPを何度調整しても改善が見られないので、そういうものなんだろうと諦めてしまったのだ。無知の無恥とはかくも恐ろしいものである（他人事みたいに）。というか、売り物で似たようなものがあったので、それで納得してしまったというか……（←言い訳）。
ところが、M3用にリサイズしてFBMを仕込みつつJP調整していたら、ちゃんとなだらかに変化していることに気がついたのだ。
だったら何か違いがあるんだろうと思って、あちこちいじってみるものの上手く行かない。
まずはFBMを使っていない状態での軸回転。回転の開始点がギリギリchestパートにかかるようにしてある。
ところが、これがモーフを適用するとchestとtrunkで動き方が違ってしまう。
そこでとりあえず、胴体が回転しないように影響範囲をずらしてみる。すると、胴体は影響範囲外であるにもかかわらず、モーフによる変形がかかるとやっぱり回転してしまうんである。
とりあえず屈伸・横屈伸・軸回転すべてこんな感じなので、JPがおかしいんだろーなー、とCR2を眺めても、M3のCR2とは値が少し異なるだけでチャンネル内の中身は変わらない。
そしたらふと、James/Koji版はモーフチャンネルが一番後ろに並んでいることに気がついた。
普通に「モーフターゲットの追加」で追加されたモーフチャンネルは、チャンネルの冒頭に加えられるはずなのだが、マグネットで生成したからか、とにかくFBMモーフはJPチャンネルより後ろに並んでいる。以前、JPをコピー＆ペーストで別のパートに適用させた時に、親に対するJPは他のJPより後ろに記述しないといけなかったことを思い出して、モーフチャンネルを先頭に移動させてみた。
……そうか、そういうことか。
つまり、targetGeomもjointもrotateもOffsetAもtaperも、操作内容が違うだけでやってることはみんな同じなんだ。どのチャンネルも、「そのパートの頂点に対して変位をかける」という役割は変わらない。ただtargetGeomとかjointとかいう冒頭のキーワードによって、直線移動したりある地点から回転させたり、フレームごとにモーフターゲットの内容を変化させたり、そういう変位の内容が変わるだけなんだ。そしてPoserは、その「パートに対する変形」の操作を、チャンネルが並んだ順番に機械的に処理していく。
rotateのxyzの順番で回転順序が決定するのも、その順番でPoserが特殊な判別をしているとかそういうことではなくて、ただ単にその順番でパートを回転させる計算をしているだけなのだ。だから、JPチャンネルが一番後ろにないと上手く変形しないのも、Scaleなどの変形がかかるとモーフが狙った変形をしないのも、様々な現象が「その順番で頂点の変位を計算しているから」と考えれば、すべて一本の線に繋がっていく……ような気がする（爆）。まだなんも検証してないから仮説だけど。
うわー、やっとほんのちょっぴり理解できた。だとしたらものすごく、PoserのCR2は明解だ。清々しいと言ってもいい。キーワードごとの動作を細かく理解しないと、結局今までと何も変わらないことなんか気にならないぐらい爽快だ（笑）
……いやまあだから。その。
そういうわけでJames/Koji版、手直ししたのですみませんがもう一度ダウンロードして下さい。
ついでにM3版はJP調整終了、G2版はこれからです。
すみませんすみませんすみません（低頭）
