little things of mine

自分はambient occlusionがあまり好きではありません． 理由は絵が汚くなりやすい上に不自然な影が出来てしまうからです．特に物と物が接している部分が不自然に暗くなってしまい，光の当たっている領域にこの影が出来ていると非常にわざとらしく見えます．逆に汚れた感じの絵には向いていると思いますが． ambient occlusionはその名の通り，環境光(ambient)からの遮蔽度(occlusion)であって，決して天空光の模倣では無いのですが，結果として近い絵が得られるためにVFXでも良く使われます．そしてこのパスにsurfaceの色(通常はtextureの色)のパスをコンポジット上で掛け算して，indirect diffuseのような絵を作ります． 元々，この手法はGIがまだ一般的ではなかった頃，PRManや既存のray tracerを使ってindirect diffuseのような柔らかい感じの絵を作るために使われてきました．当時はambient occlusionをレンダリングするだけで相当な時間がかかっていて，GIなどはとてもじゃなく制作に使える速度じゃなかった筈ですが，最近ではもう当たり前のように使われています． そこで前から思っているのは，ambient occlusionの代わりに，ホンモノのindirect diffuseパスをレンダリングした方がいいんじゃないか？って事です．ambient occlsionパスがこれだけ短い時間でレンダリング出来るんだから，出来る限りシンプルにした別のシェーダを用意して，BRDFはLambert，反射回数は一回だけにしてしまえば，許容できる時間(一枚1-2時間くらい？)でレンダリング出来るんじゃないでしょうか． あまり物理的に正確な結果ではありませんが，ambient occlusionに比べたら格段に良い結果が得られると思います．color bleedingも表現出来ますし，コンポジット後の最終的な影はかなり自然な感じになるはずですから，説得力が上がるでしょう． パイプラインを整備する必要がありますが，試してみる価値はありますね．

昨日の記事にコメントを戴きましたので，更に考察してみたいと思います． Beeさんのコメントより： NVIDIAのGelatoがSorbettoというシステムで似たようなことを実現しようとしているらしいです． おお，スバラシイ！ここの”Sorbetto Relighting Technology”というPDFファイルですね．情報有難う御座います． NVIDIA Digital Film – Gelato 早速読んでみました．見たところ，これはレンダラ自身にかなり深く統合されるシステムなようですね．影の位置まで変えられると書いてあります． 実は，昨日の記事で影に関して非常に重要な事を書き忘れました．カメラからサンプルした情報だけだと，影の位置は恐らく変更できません．例えば光源の位置が物体の前から後ろに変わった場合など，オブジェクトの裏側の情報はサンプル情報として含まれていませんから，光がどのように遮蔽されるかは分からないと思います．これを可能にするには，元になった三次元のシーンデータを参照する必要があり，Gelato搭載のSorbettoはまさにこれではないでしょうか． 個人的には，これをやり始めるとかなりレンダラ依存になりますし，システムも複雑になるのでちょっとどうかなと感じます．経験上，様々なシステムは出来るだけシンプルでお互いの依存性が低い方が良いと思っています． あとオブジェクトが動かないという前提であれば，GIも含めたシーンであっても，PRTの枠組みで変更できると思います． そうですね，動かないのであればそれも可能かもしれません．ただ，制作においてGIの嬉しいところはenvironmentからキャラクターへの反射だったりするので，これが扱えないのであればそれほど無理してGIを扱えるようにしなくても良いかもと思います． reflectionについては反射後の位置を持てば問題ないはずです． refractionもレイヤーを複数持てば，十分に可能だと思いますが，屈折率の変更は難しそうですね． 完全反射面であればそれで良いと思いますが，そういうマテリアルはまず使われなくて，普通はprimary surfaceのシェーダの上にreflectionを加えますから，どちらの情報も必要になります．ガラスのような材質の場合，更にrefractionも必要ですし，やはり仰るようにレイ1本に付き一つのデータセットを持って，反射屈折はそれぞれリストにして行くしかないですね． 環境整備の努力さえすれば，現状でも技術的な問題はほとんど無いと思っています． その通りだと思います．その努力が凄い量になりそうなのですが(笑)． 恐らく，機能をデモするだけのツール開発なら思う程大変では無いと思います．ただし，それを制作のパイプラインに入れて，誰でも使えるような状態にしようとすると，デモる努力の数十倍は必要になりそうな感じです．何しろlighting toolとcompositing toolの両方を整備しなければなりません．既存のツールをベースにするにしても，これは相当なリソースが必要です．必要になる機能の洗い出しだけでもかなりかかるでしょう． データ量の問題も，例えば自然言語解析やバイオなどの領域では大規模データの取り扱いについて圧縮等の研究が進んでますし， なるほど，そういう方面に活路を見出す事もできるんですね．データ量に関しては楽観視できるかな？   Kinuさんのコメントより： 時間軸コヒーレントのGIアルゴリズムをやる時には頻繁にそういった余分な情報を持たせたりするので(時間軸で情報を使い回すため)双方向から何らかの関係を持たせながら描画することが出来ないかなあ、、、と思ったりしたからです。 面白い発想だと思います．現在我々の制作レベルで時間軸を考慮する物と言えばmotion blurくらいだと思いますが，レンダラ自身が時間軸に関する情報をそれ以外の事にも使うような物であれば，そう言った情報を持っておく事は意味があるでしょうね． 例えば，時間軸を考慮したview dependent displacementとか，antialiasingとか，DOFとか，他にも色々ありそうです．こう言った物も後処理で出来るようになるかもしれません．   うーむ，しかし考えれば考えるほど，やらなければならない事が沢山ある… みんなが簡単に作らないのも分かる気がしたりして．

コンピュータが速くなったとは言え，レンダリングはやっぱり時間がかかります． 目的の最終成果物は画像ファイルなので，できる事ならcompositingで直したい．でも，それが可能な要素と不可能な要素があります．色やintensityの調整はある程度可能ですが，例えばspecularのshinynessや光源の移動はレンダリング後に変更できません． まあ，人間同じ事を考える人は大勢居て，その中には頭の良い人も居ます．そういう人達による一つの回答は，三次元情報をファイルに保存しておき，compositing時にその情報を使ってshaderを再計算すると言う方法です．一番良く使われるのはnormal情報でしょうか．normal情報があれば，diffuseやspecularの計算を2Dで行えます． しかし，この時に非常に大切な事があります．それはantialiasingです．normal情報をレンダリングした画像には，antialiasをかけてはいけません．なぜなら，normal情報をantialiasするというのは意味が分からないからです． では，normalをantialias offでレンダリングして，それでOKかと言うと，そうすると今度はantialiasした画像とpixelが合わなくなる場合が出てきてしまい，オブジェクトの縁にゴミのような物が出来てしまう場合があります．特に非常に小さいオブジェクトや尖った先端部分など，1 pixelの中にオブジェクトの境界があるケースで顕著になるはずです． 実は，このantialiasの問題は一般的に行われているZ合成やz depthを使ったDOF blurにも同じ事が言えます．antialiasされたz depthというのは意味が分かりません．自分は3Dパッケージのレンダラをあまり使った事が無いのですが，z depthを出力するとどうなるんでしょうか． さて，じゃあどうすれば良いか． それは，3次元情報と通常のレンダリングの両方を，antialiasする前の状態でファイルに保存する事です．つまり，サンプルされたsub pixelの情報を全て持っておくという事です． こうしておけば，サンプルされた点の3次元情報と色の情報が完全に一致し，正確な計算を行う事ができます．そして，lightingの再計算後，レンダラと同じフィルタを使って画像を再サンプルすれば，再レンダリングした物と全く同じ絵が得られるはずです． 更に調子に乗ってサンプリングされた3次元情報を全部保存しておけば，かなりの事が後処理で行えます．procedural shaderの調整まで可能なはずです．GIはちょっと難しいかも知れませんが． このアイディアは自分の中で前からあったのですが，実現するには相当な環境整備が必要で，今の所ここまでやっているスタジオを自分は知りません．PDI辺りならやってそうな気もしますが，まだきちんと聞いた事が無いです． 自分が以前勤めていたESCでは，Z合成とz depth DOFに関してはインハウスツールで実現していました．例の100人Smithのシーンなんかですね．あれを一度にレンダするのは到底不可能だったし，カメラがグルグル回るせいでそれぞれの奥行きが変わりまくりだったので，完璧なZ合成をする必要があったのです． ただ，これには欠点もあります．まず前述したようにGIを含めた変更は難しい事，reflectionやrefractionをどうするかと言う問題，それに何より保存されるファイルサイズの問題です．これは巨大になる事が想像に難しくありません．社内のI/Oに大打撃を与える事は間違いない．何しろ4×4の16サンプルなら最低でも通常の16倍，保存する情報が増えれば更にそれに掛け算ですからね． それでも，いつかはやれたらいいなと思っています．

一昨日書いたスペクトルレンダリングについてですが，ちょっと気付いた事があります． もしかして，現在のデジカメやフィルムスキャナ/レコーダに使われているデバイスはRGBを基準に作られているのではないでしょうか？もしそうだとしたら，これをある決まったスペクトルデータに準拠するように作り変える事は簡単なのでしょうか？ どちらにしても，現在のままでは意味のあるデータが取得できるとは思えません．となると，spectrum basedにして意味があるのはやっぱりCGレンダリングくらいかなあと思ってしまいました． コンポジットは光学系エフェクトの類が楽で正確になるかと思ったのですが，この恩恵に与れるのはspectrum basedなレンダラでレンダリングされた絵だけになってしまいます． ただし，今ままでコンポジットで加えていた実写との「馴染み」みたいな物はある程度楽になるかもしれません．これはMaxwellでレンダリングされた画像などを見ても感じられると思います．ではなぜなのかを考えてみましょう． 光は波長毎に屈折率や反射の特性が違います．プリズムの分光や薄い膜に生じる虹模様はこれが理由で起こる事は良く知られていますね．そして，この現象や光の干渉/回折は実は至る所で起こっており，物体に当たった光が跳ね返る時にも発生しています． しかし，現在ある殆どのレンダラはシェーディングや影のトレース時に物体表面の周波数における特性は考慮されていません．つまり，白い物体に白い光を当てれば，画像内の全ての位置で必ずRGBの各チャンネルが同じ値になると言う事です． しかしながら，現実の世界ではそうではありません．物体表面や影の輪郭では僅かながら色のズレが起こっているはずなのです．(これはデジカメやフィルムで発生する色ムラのノイズとは違う点に注意して下さい) MaxwellやWinOSiに代表されるspectrum basedなレンダラは，これらを考慮してレンダリングしているので，例えばシェーディングも単純な一様ではなく，非常にphotorealに感じられます． 現在までの所，これらを補うのはcompositorの役目です．CGレンダリングされた画像は上記のような理由からどうしても実写との馴染みが悪いですから，あの手この手を使って素材に馴染ませる作業が必要になります． 現実にはCGの馴染みが悪いのはこれだけが原因ではないのですが，それでもこれが解消されるとコンポジットが随分楽になるのではないかと思います．

syoyoさんがスルドイ事を書かれています． lucille 開発日記: スペクトルレンダリング(Spectral Rendering) spectrum basedなレンダラにおける色の指定方法に関しては，我々の間でも時々話題になります．現在はマテリアル，ライト，テクスチャ，全てRGBを基礎にしていますから，これはアートディレクションというよりはもっと基礎的な問題であると思います． syoyoさんの記事ではRGBからスペクトルを求める論文も紹介されていますが，これは一つの答えでしょう．こういった変換手法が安定してかつrobustに動くようであれば，パイプラインに組み込んで変換を自動化してしまえばユーザは今までと変わらない制作環境で仕事ができますね． 理想的には，デジタルカメラやフィルムスキャナ，ペイントツールからコンポジットツールまで一貫してスペクトルを保持するファイル形式でデータの受け渡しをし，スペクトルをベースにした色の演算をする事ですが，これには時間がかかるでしょう． 移行で一番の障害になるのは恐らくコンポジットです．コンポジットはRGBをベースにしたトリックがそれこそ星の数ほど存在するので，これらを捨て去るのは相当勇気の要る事だと思います． 逆に，スペクトルでのコンポジットが出来るようになると，レンズで起こる光学系エフェクトのトリックがもっと正確かつ楽にできるようになるかも知れませんから，移行は悪い事ばかりではありませんし，今後に期待したい所です． っていうか，とりあえずMaxwellの開発元Next Limitはspectrum basedなペイントソフトを開発すべきだな．