Vue

2009年02月21日

Vueを5手以内で楽しむ Vue7 xStream

Vue添付のデータとテンプレートを使って5手以内で作ったお手軽画像を公開。

eagle.fly

arrival.

いや、ちょっと手数オーバーしたかな・・・



take_z_ultima at 13:46|この記事のURLComments(0)TrackBack(0)

2009年02月13日

VueのHDR画像の太陽 Vue6

VueからIBL用にHDRで空を書き出せると素材集買わなくて済むのでお得感あるなぁって事で試してみてるんだけど、どうもよくわからない。例えば新規に晴れたアリゾナV2でシーンを作って、

fig01

太陽が画面に入るようにしてレンダリングしてみたのがこれ。

fig02

画像ファイルをHDR形式で保存することが出来るので、太陽光の強い光が焼きついていれば、この画像がそのままライトがわりになるわけだ。

そこでこれを意外とHDR画像を扱う時に頼りになるmodoに読み込んで計測してみた。modoではテクスチャに対してCTRLを押しながらブラシでクリックすると、その地点のカラー情報が読み取れる便利な機能があって、それはRGB値がそれぞれ飽和する1.0という値を超えるHDR画像のピックアップも出来る。

fig03

で、実際測ってみたら、太陽の中心付近でようやくRGB(1.12,1.26,1.52)で、確かにHDRイメージである事は確かだけど、お日様としての光の強度としては足りない結果になってしまった。もっとビジュアル的に確認するにはこの画像をディスプレイスメントマップとして貼り付けてみるのも手だ。下の画像はこの画像をディフューズの色+ディスプレイスメントマップとしてポリゴンに貼り付けたものだ。

fig04

周りの雲の高さと見比べて、お日様の高さが大差ない事がわかる。

試しにmodo付属のHDR画像であるprobe_parkSun_FINAL.hdrで同様の実験をしてみたのがこれだ。

fig05

光源の位置でディスプレイスメントマップがとんでもない盛り上がり方をしているのがわかる。これこそ光源となるハイダイナミックイメージだよね。ブラシでピックして実測してみると、RGB(660.0,636.0,652.0)というかなり大きな数値が出てきた。

fig06

これに比べると1.5という数値は光源をレンダリングしたものとしてはおとなし過ぎる。どうも天空に見えているのはレンズフレアの効果であって、光そのものでは無いような感じだ。それならばと思ってフレア強度を上げてみたりしてみたけどストリークが広がり過ぎて難しいものがあった。

次に思いついたのがPhotoShopを使ってHDR画像を作る事だ。自分のPhotoShopはCS2なんだけど、複数の画像からHDR画像を生成する仕組みが付いている。仕組みとしては同じ画角で撮影した複数の露出の異なる画像によって失われたダイナミックレンジを補完してHDR画像に再構成するものだ。Vueはカメラの露出設定によってレンダリングのレンジを変えられるのでこれで行けるかなと思ったんだけど露出を−2にした結果はこうなった。

fig07

フレアもやっぱり暗くなるのか・・・。期待していたのがこんな感じで太陽だけ残るような画像だったんだけど、空と一緒に明度が落ちてしまってはHDR画像生成出来そうに無い。

fig08

これはダメかと思ったんだけど空の種類を変えてみたら状況が一変した。スペクトラル大気を使ったクラシック・デーでやってみたら、

fig09

こうなった。

これが露出0の時。

fig10

そしてこれが露出−2の時。期待通り太陽だけ残った。

fig11

これは期待が持てそうwww。そこで露出を+2〜−6まで変えて9枚の画像をパノラマビューで作ってみた。

露出+2

fig12

露出+1

fig13

露出±0

fig14

露出−1

fig15

露出−2

fig16

露出−3

fig17

露出−4

fig18

露出−5

fig19

露出−6

fig20

さて、画像が用意できたらファイル→自動処理→HDRに統合でツールを起動する。そして作った画像ファイルをすべて選択する。

fig22

OKを押すと各画像の撮影条件を設定する画面になるので、下の画像のように設定した(実際には1枚のパネルだけどスペースをとるから3X3に並べてのせた)。Vueの露出については日本語マニュアルに絞りを数値にしたとか書いてあるのでおそらく1段階変えれば露光量は倍になって行くような感じなんだろうと判断して設定することにした。

fig23

露光設定が終わってOKを出すと今度は白レベルを決める画面になる。ここで感覚的に白レベルを決めたのはちょっとまずかったかな・・・(なにがまずかったかは後ほど)。右のスライダを動かして白レベルを適当に決めてOKした。

fig24

これでHDR画像が出来上がった。これをHDR形式で書き出してmodoに読み込ませてみたら、なんかおかしな事になった。下の画像がそうなんだけど、なんか暗い。

fig25

変だなとおもってPhotoShopに読み込みなおしたらもっと変な事に・・・。

fig26

ファイルヘッダかなぁ?原因は特定してないけどexr形式で書き出したら今度はうまく読み込めた。下の画像はこの画像をディフューズカラーとディスプレイスメントマップでマッピングしてレンダリングしたもの。

fig21

太陽の部分で突出した輝度になっているのがわかる。実測してみたらRGB(902.5,843.0,688.0)とかなり大きな値になっていた。

fig27

さて、苦労してダイナミックレンジを広げた背景画像だけど、これを背景画像にしてライト無しでレンダリングしてもまだ光としては足りない感じだ。そこで思い切って加算モードで太陽を塗って、数値を跳ね上げちゃって、それを背景画像にしてレンダリングしてみたのが下の画像だ。ちょっとレンダリングの状態はおかしくなってるけど、シーンには1つもライトは入れていないにも係わらず、ちゃんと影が出た。

fig28

HDRもVueもまだまだ研究が必要だな・・・。

それではまた来週。

カテゴリー別ページ



take_z_ultima at 11:30|この記事のURLComments(0)TrackBack(0)

2009年02月04日

Vue 6 xStream 使ってみた Vue 6 3ds max 2008

Vue5InfiniteからVue6xStreamにサイドグレードしたので、さっそく使ってみた。xStreamは単体で動作させたり、他の3Dアプリケーションに組み込んで動作させたり出来るエディションだ。例えば下のGIFアニメは3dsmaxに組み込んで使った例で、おなじみのBipedがVueで生成した草に影を落としているし、草の陰でBipedが隠れたりしている(core2quad6600で320x240ピクセル271フレームを1時間2分でレンダリング)。

fig01

Vueの凄いところはこのシーンのVue側のセットアップが僅か7ステップくらいで出来ちゃうところで、向こうに見えている山は自動生成した地形にプリセットのテクスチャを設定しただけのものだし、手前の草むらも向こうの山と作成手順はほぼ同じだ。Vueにはecoシステムと言う環境によって植生をコントロールする仕組みが付いていて、それを地形に適用してやると、勝手に草とかが生えてくる。しかも風にそよいだりといったアニメーションまでしてくれる。そんな便利な機能が3dsmaxをはじめ、主要なCGアプリケーションに組み込める(もちろん単独でも動く)のがxStreamエディションで、上の作業をしている時の3dsmaxの画面は下のようになる。

fig02

max側で用意したのはBipedだけで、草も地形もVue側で生成したものだ。それがこんな感じであたかもmaxの一機能のように見える。

ところで3dsmaxに組み込む時にはちょっとした注意が必要なのでここに書いておきたい(実はそのことで初っ端からつまづいた・・・orz)。

まずはマニュアルに書いてある通り、Vueをインストールし、その際に連携するアプリケーションのインストールフォルダーとレンダラーを設定する。1度連携するアプリケーションを決めちゃうと、他のアプリとの連携は出来なくなるそうなので、インストール前によーく考えておいた方がいいようだ。もちろん追加ライセンスで複数アプリとの連携は可能らしいけどね。自分はLightWave3Dも持っていたんだけど、気付いた時は既にレジストレーションした後だった・・・orz

余談はともかくとして、これで連携に必要なファイルは3dsmax側にもインストールされ、maxを起動すると自動的に認識される。それを簡単に起動出来るようにするために、マニュアルにはユーティリティーパネルにVueのロールアウトを作る方法が示されている。下の画像をクリックするとその手順がGIFアニメで見られるよ。

fig03

さて、これで晴れてmax側からVueを使えるようになったと思ってさっそくやってみた結果がこれだ。

fig04

見ての通り全然Vueのオブジェクトがmax側で表示されない。何でだろう?マニュアルにはVueの平面が表示されると書いてあるけど、そんなものはどこにも見えない。で、よーくマニュアルを読むとmax9のOpenGLはVueのOpenGLと一緒に使うと不具合が出る事があり、それを回避するためのオプションが一応あるけど万全じゃないって書いてあった。

んっ?

OpenGL?

ここでmaxがDirectXで描画を行っていることに気付いた。maxはデフォルトの状態でDirectXを使って描画している。Vueがオブジェクトを表示するために使っているのがOpenGLならmax側もこれにあわせないとダメなのかな?

というわけで以下のGIFアニメの通りmaxの描画をOpenGLに切り替えてみたらうまくいった。

fig05

このくらいのことは書いといてくれよ・・・orz

ちなみにVue6はmax2009には対応していないのでプラグイン読み込みのところでエラーが出たし、max9はecoシステムの表示がうまく行かない事があるそうだ。max2008では問題なくうまくいってる(落ちる事多少・・・)。

それではまた次回。

maxまとめページ



take_z_ultima at 11:30|この記事のURLComments(0)TrackBack(0)

2008年10月22日

Vueのカメラをmodoのカメラに同期させてみた その4 modo 302 Vue5 Infinite

Vueとmodoの焦点長を前回求めたパラメータで調整して、ついでにペアレントとアイテムの回転順序にも対応出来るようにスクリプトを修正したよ。

アイテムの回転については「query sceneservice item.worldMatrixInvrs ?」というクエリを使ってワールド座標系での回転行列が得られるので、これと先に作ったスクリプトで算出したパラメータを比較したら、正負の符号を修正するだけでなんとかなりそうだったので、採用する事にした。ただしこの行列は3×3なので回転しか対応してなくて、移動の方のワールド座標が取得できないので、以前に書いた記事「ワールド<=>ローカル座標変換」からルーチンを持って来て、ローカルのアイテム座標をワールドのアイテム座標に変換して対応した。何でも書いておくと、後で助かるねwww。ただしアイテムのスケールには対応してないし、カメラターゲットを設定してカメラを回転させてもスクリプトから回転角度が読み取れないのでそれにも対応してないので気をつけてね。

これでカメラの同期が取れるようになったので、シーン設計に入ろうかな。

Ogreが花を見て感動するためには花なんか一本も咲いていないような環境がいいよね。それと花を踏みつけに来る車両を当初は自動車で考えていたけど、工事用のローラーとかそんな感じの車両の方がいいね。そのあたりの資料を集めてモデリングしないとね。

ちなみに下のムービーはロケータを2つペアレントして、その中にカメラを入れてアニメーションさせたものをVueに書き出してシンクロさせた例。modo上のモデルのOgreとVue上の背景が同期しているのが確認できた。

fig02

それではまた次回。

カテゴリー別ページ



take_z_ultima at 11:30|この記事のURLComments(0)TrackBack(0)

2008年10月20日

Vueのカメラをmodoのカメラに同期させてみた その3 modo 302 Vue5 Infinite

ようやくポニョを見に行ったよ。あれが全部手描きなんだからやんなっちゃうね。

さて、Vueとの同期についていろいろと検証してみたんだけど、いろいろと問題が発覚した。まず倍率なんだけど、LightWave3Dからの出力が50倍だったのでそれに倣って50倍にしたんだけど、意味無かった。1倍でいいじゃん、これ。読み込んだあとでも尺度は手でも直せるけど、プログラムの中では

 array('f',[50.0]).tofile(f)

ってところを1行だけ

 array('f',[1.0]).tofile(f)

に修正すればOK。

そしてアイテムの回転順序なんだけど、今のところまっとうそうなのはXZY回転だけだな。他のやつは微妙に角度がヘンになる。変換マトリクスで回転を与えているのでオブジェクトの回転にそのまま利用されているなら、問題なく回転できそうな感じナンだけど、Vueのアイテムパラメータを確認すると角度が微妙にヘンな値になる。これはもしかして回転マトリクスから回転角度を逆算する時に生じるものなのかもしれないけど、まだ検証は出来ていない。カメラを水平に保つオプションなんかも影響している可能性があるな。だからとりあえずXZYの回転のみで使うのがいいよ。

次にレンズの焦点長なんだけど、数値上はmodoとVueで同じ値になってるんだけど、よく考えたらレンズの焦点長≠視野角なんだよね。両者の焦点長が何を言い表しているのかを良く調べてみないとあわせようが無いみたいだ。ちなみに今回やってみた感じだと、Vue側で50mmの焦点長だと、modo側で45mm程度で合致する感じだった(アスペクト比1、640×480ピクセル)。この微妙な数値はナンなんだろう・・・。それからまだカメラのペアレントに対応していないし、カメラターゲットに至っては解決しようが無いかもしれない(まあそんな時にはコンストレイントスクリプトを使えばOKだけどね)。

それからライトのデータを太陽光で使おうとするとおかしな事になる。元々太陽光は中心点からの位置で方向が拘束されちゃうようになっているのでライトの角度より位置が問題になっちゃうみたいだな。

とまあ、まだまだ完成には程遠いんだけど、それでも使い方次第では何とかなる事も確かだよ。下の画像をクリックすると、今回検証のために作ったWMV形式の映像が見られるよ(あまり眺めていると目眩がしてくるかもしれないので気をつけてね)。

fig02

以前にボックスステップさせた奴の完成版がどっかいっちゃったので、途中で落ちて自動保存でひっかかってたファイルを取り出してきてMDDExportでMDDファイルに変換して、modoに読み込んだOgreにMDDデフォーマを適用してアニメーションさせたものを用意しておいて、それに対してVueの画像を適用したものだ。

実はこのシーンはOgre以外は影を落とす地面用の1枚のポリゴンしか使っていない。良くわかるようにポリゴンを小さくしてみたのが下の画像。こんだけポリゴンがあれば用が足りちゃうよ。

fig01

まずはカメラのアニメーションを設定してVueSync.pyスクリプトでVueにカメラアニメーションを出力してVue上で背景画像をレンダリングし、それを連番画像にしてmodoに連番画像として読み込ませる。これをシェーダーツリーのEnvironmentの中に環境の色のマップ画像として割り付ける。下がその例。そしてその画像のテクスチャロケータで、プロジェクションタイプを「フロントプロジェクション」とし、プロジェクションカメラをレンダリングする時に使うカメラに設定する。

fig02

これでカメラがどんなに動いても、連番画像が画面からずれることなく追従して背景画像になる。下の画像がその様子。地面用のポリゴンとOgreの周りには何もないにも係わらず、Vueがレンダリングした画像が貼られて、それがカメラと同期して動くアニメーションになっているので、背景がが立体的に感じられる。この時カメラの焦点長を50mmでVueに出したのなら、レンダリング前にその値を45mmに修正する。これでプロジェクションマップされた床の画像と足がほぼずれることなくレンダリングできる。

fig03

次に地面用のポリゴンのマテリアル名を「ground」として、そのマテリアルのカラーマップ画像として背景と同じ連番画像をフロントプロジェクションマップ画像として貼り付ける。

fig04

これでポリゴンにマップされた画像も背景画像も同じカメラから投影された同一の画像になるので下の画像のようにシームレスに繋がって、境がわかりにくくなり、まるで地面が遠くまであるように見える。

fig05

でもF8を押してプレビューをしてみると下の画像のように背景と地面ポリゴンの明るさの差がはっきり出てしまっているのが確認できる。

fig06

そこで、ポリゴンに貼り付けたgroundマテリアルのディフューズ量を調節して、背景画像とポリゴンの画像の明るさを馴染ませる。

fig07

そうするとこんな感じで境目が全然わからなくなるよ。ディフューズ量がどのくらいになるかはGI使ったりライトの明るさなんかでも変わってくるからね。

fig08

この例では平らなポリゴンでやってるけど、Vueから地形データを出力させて、それを地面として使う事も出来るよ。もちろんVueからUVマップに貼り付ける形のカラーマップやバンプマップなんかも出力出来るけど、誤魔化せるところはなるべく今回やったフロントプロジェクションマップを使った方がレンダリングも軽いしオススメだよ。最近は3Dを取り入れた2Dアニメの世界でも多用されているテクニックらしいよ。

いまのところまだ不便極まりないけど、背景を作る手間が省ければ、おつりが来るかもね。とにかくペアレント問題だけでも何とかしないとね。

それではまた次回。

カテゴリー別ページ



take_z_ultima at 11:30|この記事のURLComments(0)TrackBack(0)
Archives