background

うろうろ。

2016年07月10日(Sun)

お話の続きをちょろっとアップしています。

RutenKango

外は暑いからエアコンの効いた部屋でゆっくりしたいというアナタ、読書などはいかがでせう。


Poserの方はなんか簡単なことばかり載せてる気がするけども、まあ今の所ひたすら丸や四角ばかりレンダリングしているからで。コレとまとめられるほど、体系化された知識にはまだなっていないというか。せっかく新しいソフトにイチから体当たりする、というシチュエーションになったんだから、できればしっかりまとめていきたいなあ、放置になっていたサイトをちゃんと整理したいなあ、とか。まあそれは以前から考えていたことなんだけども。

そんなわけで成果物とかはあまりない。

160710-01(クリックで倍サイズ)

さすがに球体だとSSSは効果が現れにくいから、他の基本小道具でテストしてたりもする。真ん中のポットだけ適用されてるんだけど、わかるかな。SuperFlyレンダラで、PhysicalSurface(物理サーフェイスとかかな?)ルートにSSSだけ適用したもの。他は両脇のポットと同じ。効果を確かめたい時は、面倒でも比較対象を並べていっぺんにレンダした方が後で客観的に見やすいと思う。

マテリアルはこれだけ。

160710-02

PhysicalSurfaceのSSS用のノード値は、アップデートがリリースされた時に追加されたということなんだけどどうだろう。11のリリース当初は所有していなかったのでわからない。SRでノードの設定が増えるなんて、Poser 6の「ノーマル_前」みたいで懐かしい記憶が蘇ったり。ていうか屈折率はどこいった。

レンダリング設定はこんな。

160710-03

レンダ設定で品質を上げていく時は、関係するパラメータだけをちょっとずつ上げながらテストして、これ以上数値を大きくしてもあんまり変わらないな、というところまで来てからピクセルサンプルを上げると無駄がない感じ。じゃあ関連するパラメータってどれよ、となるんだけど、そのへんはまたいずれ。

Poser 11のレンダラはSuperFly、FireFly、スケッチ、プレビューの4種類になった。いつの間にかP4レンダラが無くなってSuperFlyが増えたのかな? で、マテリアルなんかも新機能がちょこちょこ増えたわけだけども、その全てが全てのレンダラで使えるわけではない、というか。プレビューレンダ用の機能だったり、SuperFly用の機能だったり。それらが別々に整理されているわけではなく、旧来の機能と同じところに混在しているから、話がややこしく映るのかもしれない。

で、さて何から始めようか、みたいな気持ちになって、うろうろしてる。

160710-04

マテリアルはぽちぽち調整中。



地に足。

2016年07月08日(Fri)

流転閑語、つづきをこっそりUPしています。

RutenKango

例によって本文はできてるから、整形でき次第UPしていこうかな、という感じです。果たしてどこの誰に需要があるのかもわかりませんが、少なくともやってる本人はそれなりに楽しんでいるので、まあ、いいかなと。


さて、Poser。

画面表示を整えたので、次は起動状態を設定しようかなと。おなじみ「Poserおじさんを消す作業」である。

インストール直後のPoserは、起動するたびに男性フィギュアを表示する。最近はマネキンのアンディ君になったから、Poserおじさんとは言わないんだろうけど。で、このデフォルトで読み込むフィギュアというのは、自分で設定することができる。というか、正確には「起動またはシーンを新規作成した時に、ロードされるシーンファイル」を指定することができる。起動するとおじさんが出てくるのは、「おじさんが一人ロードされている」というシーンを読み込んでいるからだ。

つまり、自分のお気に入りフィギュアやよく使う小道具・ライトセットなどを配置したシーンファイルを指定すれば、新規作成のたびにそれらをロード済みの新規書類を作ることができる。

とはいうものの、大抵の場合は「消すのがめんどくさい」「フィギュア番号が変わっちゃうし」という理由で、何もないシーンファイルを使用することになる。

まずフィギュアを消して、

160707-01

General Preference(環境設定)で「Document(ドキュメント)」タブを表示、「Launch Behavior(起動ビヘイビア)」欄で「Launch to proffered scene(現在のシーンで起動)」を選択し、その下の「Set Preferred Scene(現在の状態を設定)」ボタンをぽっちり押す。

160707-02

すると、Poserはその時点のシーンの状態を専用のファイルに記録する。で、起動のたびにそのファイルを参照しにいくわけだ。

自分はもしもの時の為に、この状態のシーンファイルをP*Boot.pz3という名前をつけて別に保存している。なのでハードディスクには歴代のブートファイルが残っている。

160707-03

さて、ついでだから背景セットも消してしまおうかな(ここからが本題)。

いつからか知らないけど、背景にドームを読み込むのがデフォルトになったらしい。このドームは確かIDL実装された頃に基本小道具に追加された、Hemisphereって名前のやつだった気がする。これはこれで便利なんだけど、必要になったら小道具から読み込んだらいいしー。

ところが、削除しようとして気づく。シーンファイル上に小道具が存在しない。

160707-04

なんでだろう、とよくよく触ってみるとこのドーム、GROUND(地面)という扱いになっている。今まで地面といえばシャドウキャッチャーが設定された四角い平面だったんだけど、その形状そのものが変更されたらしい。なのでこのドームはCommand+G(Ctrl+G)で表示/非表示を切り替えられたりする。なるほどなるほど、GROUNDのジオメトリ自体に別の任意の形状を指定することができるんだな。相変わらず自由度高いな~……って。

ちょっと待って。今までの地面はどこにいったの!

これまで自分はテストレンダや検証時、面倒を省くためにGROUNDのマテリアルに直接タイル模様を貼り付けたりしていた。それに、フィギュアだけレンダしたい時には、影だけ描画して背景を抜くシャドウキャッチな床はそれなりに手軽だったのだ。

普段から使うかと言われたら微妙だけど、まったく無くなってもらっては困るのである。

まあ、形状自体は簡単なものだから、そういう機能を持った地面小道具を作って、必要になったらドームを非表示にして小道具を読み込めばいいと言えばそれまでではある。しかし、うーん、なんか手間がかかる気がする。

ということで、まず以前のバージョンのシーンファイルから読み込んでこようかな、と保存してたブートファイルをP11で開いてみた。こういう時のための別名保存である。……っと、

ない! 床がない! 右も左もわからない! (><)

シーンファイルをエディタで開いてみると、そもそも以前のバージョンのPoserではGROUNDはジオメトリを読み込んでいるのではなかった。

160707-05

そういえばそうだった。おそらくはGROUND自体が予約語で、システム内部でそういう形状を読み込んでいたのだろう。それが、今回(?)のバージョンからは他のオブジェクトと同じように、ジオメトリを外部ファイルから読み込む形になった。ということなんじゃないかな。

仕方ないので、どこかに元の地面が存在しないか探してみた。

ライブラリにあるSquare Groundplane HRは違う。なんか大きいし目が細いし。自分はもうあの見慣れた地面に着陸することはできないんだろうか……などと思っていたら、Geometriesフォルダにあった(ちなみに、Macで何も考えずにフルインストールした場合、Runtimeの中身はVolume/Users/Sharedフォルダ下のPoser 11 Contentの中に配置される)。

160707-06

propsフォルダの中にground.obzとground20x20Lines.obzを発見する。Poserで拡張子の末尾がzのファイルはzipで圧縮したファイルなので、拡張子zipを追加して普通の解凍ソフトで解凍すればテキストファイルになる。objにしてテキストで中身を確認、何が違うのかと思ったら、20Linesの方はどうもY位置が低い。じゃあ使うのはgroud.objの方がいいかな。

160707-07

というわけでここからは自己責任。

まずVolume/Users/(ユーザ名)/Library/Application Support/Poser Pro(またはPoser)/11/preferredState.pz3を複製する(Windowsの場合の所在地はわからないけど、そんな感じの名前で検索したら見つかると思う)。

複製したシーンファイルをエディタで開き、最初の「prop GROUND」の括弧の中身、読み込むジオメトリの記述部分を書き換える。

160707-08

このままではパラメータやマテリアルなどの設定が元のドームのままなので、そのへんの情報を二番目の「prop GROUND」を検索して括弧内を書き換える。内容は過去に保存していたBoot.pz3の該当部分をコピー。

160707-09

この改変したシーンファイルを元のprefferredState.pz3と差し替える。まあPoser上で開いて設定してもよし。で、シーンを新規作成してみよう。

160707-10

よしよし、ちゃんと差し替わっている。

で、何気にレンダしてみたら……

160707-11

そもそもSuperflyレンダはシャドウキャッチャーに対応してなかったという(それでかー)。

ここまでやって、「じゃあポーズファイルで両方に切り替えられるようにしたらいいんじゃ?」と思いついたので、折角だからPoseファイルにしてみた。

160707-12

エレメントの指定がpropだとうまく動かないから、actorに書き換える。さらに、こういうPoseファイルはフィギュアが1体以上シーンに読み込まれていないとうまく機能しないから、適当なフィギュアを読み込んでから適用してみる。そういえばマテリアルコレクションファイル(拡張子: mc6)にすれば確かフィギュアが存在しなくても適用できた気がする。

160707-13

動くには動いたけど、一度追加されたモーフチャンネルやマテリアルグループは削除されないし、まあ無理にやる必要はないかな、という感じ。

今更かもしれないネタでも、キニシナイ。



フロート・おあ・ドッキング。

2016年07月03日(Sun)

流転閑語、お話の続きをちょろっと更新しました。

RutenKango

心とお時間に余裕のある方、よろしければお楽しみくださいませ。


Poser 11は新機能を全部試すとか無理だから、普段使うものの中から気になったところをポチポチと調べていこうかなと。英語だし。相変わらず苦手だし。で、とりあえず環境設定とか画面の配置から~。

今の所ポーズ部屋、

160703-01

と色部屋(マテリアルルーム)

160703-02

と布部屋(クロスルーム)

160703-03

だけパレットを並び変えたり。

自分はカメラを動かす時はレンダリングウィンドウの上部のカメラコントロールを使ってるし、視点を切り替える時は画面を右クリックしてる。

160703-04

ので、そもそもカメラパレットが不要。なので消す。

ライトも基本パラメータパレットで選択してるから、ライトコントロールパレットは要らないっちゃ要らないんだけど。

160703-05

他人様のライトファイルとかを適用した時なんかは、どれがどのライトか把握できてないので、そういう時に選択するのには使うかな……あと大量のライトを消去する時とか。というわけで残し。

ライブラリは下の階層のサムネをフォルダに表示する機能とパンくずリストが良さげな気がしたので、ツリー表示と2列にして使ってみる。

色部屋はとにかくノードが広く使えるように、他のものは極力絞る。布部屋は最初に覚えた頃の左にパレットがある配置に慣れてしまっているので、レンダリングウィンドウを右に。あと調整中にポーズとか動かす場合もあるので、パラメータパレットを表示しておく。

で、あらかた配置が決まったら、「ドラッグドッキング有効」のチェックを外しておく。

160703-06

これをやらないとうっかりパレットの端っこを掴んだ時に変な場所に動かしてしまうことがある。というか、今回数年ぶりにやらかして「ちっ」となることが二回ほどあった(笑)。

「ドラッグドッキング有効」にチェックが入っている時、パレットの周辺でマウスカーソルが手の形になると、パレットを掴む。

160703-07

いかにも誤操作しそうな位置で有効になるんだな、これが。

うっかり変な場所にドッキングしてしまった場合、もう一度ゆっくりドラッグしてやるとパレットが浮かび上がって、入れそうな位置に近づくと色を変えて教えてくれる。

160703-08

だけどだいたい「そっちじゃない! レンダウィンドウの下じゃなくて左に入って欲しいんだよ!」みたいに狙ったところに移動してくれなかったりするので、そういう時はいったん周辺のパレットを全部浮かせて、イチから配置するとちょっとはマシかもしれない。かもしれない。

そんなわけでよろしいでしょうか、隊長殿(私信)。

で、ちょろっとレンダ。

160703-09

なんというか、こういう感じのお話です。



Christmas Advent 2012 Angelic Gift

2012年12月15日(Sat)

angericgift_bunner


UV情報とバンプ、検証について

2012年03月02日(Fri)

まず告知。第六回和風展が開催されています。投稿期間は11日いっぱいまで。年に一度の本気展、ぜひ奮ってご参加ください。

第六回和風展バナー中

じ、自分は鋭意作成中……(小声)。


さて、今回のエントリはろるふぃさんのブログ「POSERとHexagon中心に3DCGを楽しもう」の記事POSERのテキスタイル(バンプ)が保存できない不具合と解決法と、thattori43さんのブログ「TH Free Style」の記事ミレ犬お散歩グッズを受けての内容となる。お二人とも精力的にPoser活動なさっている方で、いつもブログを拝見しているのだけど、一点だけ勘違されていらっしゃると思しき箇所があるので訂正させていただくことにした。

ホントは自分はフォーラムに持ち込まれない限り、他の方のサイトの疑問などには応えないようにしてるんだけど。読んだ方が他にもいらっしゃるかもしれないので、ここは老婆心ということで容赦してほしい。コメント欄への書き込みでは説明し辛いし、メール等では他の読んだ方の目に触れなくなってしまうので。

問題の箇所は「UV情報が無いとバンプ関係のマテリアル設定がライブラリ登録時に消えてしまう」というもの。これが事実でないということ、なぜそんな誤解が起こったのかということを書いていこうと思う。

まず、UV情報を持たないオブジェクトを作成する。Shadeでプリミティブをポリゴン変換すると自動的にUVが設定されるので、WavefrontOBJのエクスポート時にUV値のチェックを外す。

120302-01

これをPoserでオプションを全部外して読み込む。最初は小道具の状態だ。適当にマテリアルを設定しておく。

120302-02

次に、セットアップルームで適当にフィギュア化。ライブラリに登録して、そのままロード。

120302-03

このように、フィギュア化してもバンプが失われることはない。ちなみに、ここで使用しているのは3Dテクスチャの乱気流(Turbulence)ノードである。

では、何が問題なのだろうか。

問題を正確に把握してみよう。ろるふぃさんのブログでは「バンプ情報が消える」「バンプ関係のマテリアル設定が消えてしまう」と書かれているけれど、マテリアルのキャプチャを拝見する限り、バンプにノードは接続されている。ということは、Poser内部でも保存されたファイルの中でも「バンプにテキスタイルノードを設定するという情報」はちゃんと保持されているということである。だから、「情報が消える」という書き方は正しくない。「バンプにマテリアルは設定されているけれど、レンダリングすると描画されない」もっと正確を期すと、本当に描画されていないのか今の段階では断言できないので「マテリアルは設定されているけれど、レンダリングすると描画されていないように見える」と表現しないといけない。

揚げ足取りみたいに思えるかもしれないけど、正確に表現することはとても大事だ。物事を正しく表現するには、現象を正しく把握する必要がある。表現が正確でないということは、現象を把握できていないということである。それでは正しい判断はできないし、物事を正確に伝えることもできない。

というわけで、問題の現象は「UV情報を持たないジオメトリをフィギュア化して再ロードすると、バンプに接続したテキスタイルノードが描画されなくなったように見える」ということになる。

ここで、「ん?」「2Dテクスチャのノードって、UVがないと使えないんじゃなかったっけ?」と思ったあなたは正しい。(UVに関しての説明は過去記事のこの辺の中盤あたりにある)

2Dテクスチャに分類されているノードは、平面(2D)方向に変化する情報を描画する。平面といっても、イメージマップノード以外はXY平面やXZ平面やYZ平面を指定することはできない。ではどの平面に対して描画を行うのかというと、UV平面しかない。つまり、2DテクスチャはUV平面に対して描画を行うノード群である。まあイメージマップノードは除外されるけど、イメージマップでUV以外を指定したことのある人はかなりレアだろう。

というわけで、UV情報を持たないオブジェクトには、そもそもUVを参照する2Dテクスチャノードが描画できるわけがないのである。

ではなぜ「小道具では正常に描画できてたのに、フィギュア化でバンプが消えた」と誤解されるような現象が起こったのか。

結論から言うと、この文章に間違いが三つある。

一つ、そもそも小道具の時に正常に描画されていたわけではない。
一つ、フィギュア化しても消えたわけではない。
一つ、バンプ以外でも同じことが起こる。

以下実証。UVを持たない小道具に対してテキスタイル(Weave)ノードを接続する。

120302-04

普通のアイテムに対してテキスタイルノードを使ったことがある人なら、これが正常な描画だとは思わないだろう。Poserの基本小道具(Primitives)内にあるボールを使って比較してみる。もちろんボールにはUVが設定されている。

110302-05

UV情報を持たない小道具では、パラメータを変更しても内容が反映されているようには見えない。ではバンプ以外、テキスタイル以外ではどうだろうか。拡散色(Diffuse_Color)に接続してみる。

120302-06

まったく同じ設定のノードを接続しても、UV情報を持たない小道具では異様な描画がされている。そもそも「その画素がUV上のどの位置に存在するか」が定義されていないのだから、いくら変位させるかも、何色で塗りつぶすのかもPoserが判断できるわけがないのだ。UV情報がないということは、「定義されていないから、不定」ということである。それを無理矢理描画させるものだから、イレギュラーな(不正な)描画になっている。

さて、フィギュア化したオブジェクトに対して2Dテクスチャノードを適用してみる。

120302-07

たしかに2Dテクスチャのノードが反映されなくなった……と、判断するのは誤りだ。本当にノードの情報が反映されていないのなら、イメージマップノードの「テクスチャの黄緑色」が描画されているはずがないからである。

では、フィギュア化によって一体何が変わったのだろうか。

Poserのインポートで作成されたオブジェクトは、その内部にジオメトリ情報を保持している。小道具としてライブラリに登録しても、ジオメトリ情報は小道具ファイルの中のgeomCustomという部分に保存されている。それに対し、セットアップルームでフィギュア化したフィギュアは、ライブラリに登録するとジオメトリファイルを別に出力する。つまり、フィギュア化したオブジェクトは、参照しているジオメトリが小道具であった時と異なるのである。

短いジオメトリ(8頂点の立方体)で試してみよう。左はインポート後そのままライブラリに小道具として登録したもの。右はフィギュア化してから、ライブラリに登録したときに生成されたもの。

120302-08

頭に「v」とついているのが頂点座標、「f」が一つ一つの面が参照している頂点番号/UV頂点だ。そして、頭に「vt」とついている行がUV値である。

フィギュア化したジオメトリには、UV値が一つだけ作成されている。そして、すべての面のUV頂点が同じUV座標 (0, 0) 、すなわち左下のただ一点を参照している。マップの同じ位置を参照しているのだから、凹凸や色の濃淡が生じるわけがないのだ。

フィギュア化したときにUVが生成されるのは、無用なトラブルを避けるためだろう。その結果、今まで不正な描画がされていたものが、正常な描画を行うようになったのだ。たまたま不正な描画の方が意図した結果に近く、正常な描画の方が意図した結果ではなかったために、それを不正な結果だと誤解してしまったのだろう。

以上のことをまとめると、

  • UV情報を持たないオブジェクトに対して、UV情報を参照する2Dテクスチャのノード群を適用すると、不正な描画が発生する。
  • フィギュア化でライブラリに登録したときに作成されるジオメトリは、元のジオメトリがUV値を持たない場合、自動的に (0, 0) のUV値を生成する。

ということになる。

UV値を持たないオブジェクトに凹凸や濃淡などつけたい場合は、2Dテクスチャではなく3Dテクスチャを使用すればいい。2Dテクスチャが(UV)平面方向に変化する情報を描画するノードだとすれば、3Dテクスチャは文字通り三次元方向に変化する情報を描画するノードである。つまりUVではなくジオメトリのXYZ座標によって内容が変化するのだ。縫い目やタイルのような2Dテクスチャと同じ描画はできないが、表面の粗さを表現するだけなら十分である。

作成したジオメトリにUV情報を付加するかどうかは、作者の任意による。ただ、もし配布するつもりがあるなら、一言「UV展開はしてません」程度に書き添えておいた方が親切だろう。巷のアイテムはUV展開されているものが大半だからだ。気に入ったアイテムのオリジナルテクスチャを作ろうとして、いざUVMapperを開いてみたら真っ白、となると「もう二度とDLしねえよ ヽ(`Д´)ノ」という気分になりかねない(実際に聞いた話・笑)。

なお、どうしてもフィギュアにUV情報を持たせたくない、という時はフィギュア化前のジオメトリを使用すればいい。PoserのWavefrontOBJエクスポートは法線情報は自動的に生成するが、UV値は生成しない。

120302-09

ちなみに自分は、フィギュア化で作成されるジオメトリは使用しないことにしている。以前のバージョンのPoserで、ポリゴンが欠落したり別のグループに割り当てられてしまうバグが発生するものがあったからだ。あと、フィギュア化するとジオメトリがパーツごとに分割されてしまう。これが個人的に不便なので、いつもPoser上でグループを整理したあと、フィギュア化直前に出力したものを使用している。


間違えること、失敗することは悪いことじゃないと思う。大切なのは疑ってかかること、何よりもまず自分自身を疑うことだ。他人の言っていることは正しくないかもしれない。悪意はなくとも正確ではないかもしれない。そして、自分の考えや行動はもっと間違っているかもしれない。もっと他にうまいやり方があるかもしれない。常にそう考え続けることはしんどいけれど、そうでなければ人間はすぐに自分の判断が正しいという考えに溺れてしまう。

考えて疑って、注意深く観察して、誰がどうやっても動かしようのない事実だけを積み上げていく。自分が正しいことを証明するのではなく、自分が間違っていることを証明するのだ。その結果間違いであることが証明できなかったなら、今のところはそれが「暫定正解」になる。そしていつか間違いであることが証明されたなら、新しい暫定正解に取って代わられる。古い間違いは決して無駄ではなく、新しい暫定正解をより正解に近いところに押し上げるのだ。

検証というのは、そういうものだと思う。





Menu

Profile

Kyotaro

確定名:Kyotaro
ネタを探しているらしい。

Categories

Calendar

10 | 2023/11 | 12
- - - 1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 - -

Comments

Archives

Track back

RSS feed

Links

Search

※2011年4月6日のサーバ障害の為、エントリのアドレスが以前のものからズレています。当Blogのエントリにリンクを張っておられた方は、お手数ですがアドレスのご確認をお願い致します。

※Internet Explorer非推奨。