レンダリング時のtexture filteringを意識した事のある方はどのくらいいらっしゃるでしょうか．
偉そうに書いている自分もこちらで働き始めてから学んだ事なのですが，ペイントしたテクスチャ，proceduralなテクスチャを問わず，テクスチャを常に綺麗に見せるのは至難の業です．（これは先日書いた記事にも関係する事なので，リンクを）
今回はペイントしたテクスチャについて考えます．
これは本質的には，レンダリングされる画像の解像度とテクスチャの解像度が一致しない事が原因です．これを常に一致させる事ができれば，ほぼ確実なアンチエイリアスが可能になり，アニメーションやカメラ位置に関わらず美しいレンダリング結果が得られるでしょう．
しかしながら，テクスチャの一部しか画面に出ていなかったり，カメラとオブジェクトの距離が変化したり，オブジェクトの面積がdeformによって広がったりする限り，これらを一致させる事は不可能です．この解像度の不一致によるaliasingをある程度防ぐ為に，mipmappingやanisotropic filtering等が考案されてきました．
これらの手法は基本的にフィルタによってaliasingを防ぐ事が目的であり，下手をすればディティールが死んでしまいます．そして，殆どの場合，これらの調整はユーザパラメータになっており，その場面に応じて調整する必要があります．レイトレーシングの場合は反射や屈折が起こり，更に問題が複雑になります．
この調整がなかなか大変で，自分は以前，綺麗に見せるためにパラメータをアニメーションさせた事さえあります．
最近（と言っても’99ですが）になり，”ray differentials“と言う，現在の所最も有効と思われる手法が考案されました．
これは大まかに言うと，あるサンプルレイと画面上でdx（若しくはdy）だけ異なるサンプルレイとの三次元空間上のdifferential（変化量）を計算し，それをフィルタ幅の指標に用いるという手法です．x方向y方向それぞれのdifferentialがあるのでdifferentialsと複数形になっています．
ray differentialはレイが反射や屈折をしても計算可能であり，上記リンク先の論文中にあるテストレンダリングでもかなり良好な結果が得られている事が分かると思います．また，これは画面上での変化量を知る大変便利な指標となり，他にも色々と応用が利きそうです．
こんなに素晴らしいray differentialですが，商用のレンダラで実装している物はまだ殆ど見かけません．（注：自分が知らないだけの可能性もあります）
ところが，このtexture filteringの問題をもうずーっと前から解決している手法があります．それはPRManに代表される，Reyesです．
Reyesではあるsplitされたprimitiveが画面上でどのくらいの解像度を持つか，シェーダを評価する前に知る事ができます．また，2のべき乗に整形されたテクスチャは，そのprimitiveにほぼ一致するテクスチャを探し出す事を可能にします．また，Reyesはレイトレーシングをしない事を仮定しているので，いつでもこの規則に従ってテクスチャの解像度を選ぶ事ができます．
最近のReyesレンダラはPRManを含め，こぞってレイトレーシングを実装していますが，恐らくレイトレーシングした先の解像度はかなり荒っぽい方法で求められており，一次レイの画像程美しくは無いでしょう．
Reyesは間違いなく映画をレンダリングする為のレンダリング手法として編み出されており，全てのバランスを考えると，とても良く考えられた素晴らしいアーキテクチュアだと思います．これが二十年以上も前に考案された事にはただただ驚くばかりです．
なんだか本題からずれてしまいましたが，フィルタの話はサンプリングの話と関わりが深く，基本的にpoint sampingなレイトレーシングでは色々と問題になる事が多いため，現在の所，人間が頑張って綺麗に見せていると言うのが実情です．
3 Comments
はじめまして。shi3zさんの所から来ました。
前回のお話もそうですが、aliasingは本当に問題が残っていますね。
恥ずかしながら、僕も映像関係の会社にバイトに来るまでは
このような問題が残っている事を知りませんでした。
特に研究レベルでは色々と解決策が出ている事でも、
たぶん安定性やら既存のシステムへの組み込みの難しさなどから
商用レベルでは実装が全くされていない事が多いのに気がつきました。
そういう意味では、ray differentialsもその一例だと思います。
今回のお話は、mip-mappingのようなsurface上の
local filteringの指標があまりに適当に決められているせいで
発生している問題だと認識しています。個人的には、現在のレンダラーには
設定べきパラメータが多すぎるように思うので、今回の物も含めて
妙なパラメータがユーザーに一任されている現状は何とかしたいところです。
（まあこの問題と下のadaptive anti-aliasingについては単純に
沢山rayを飛ばせるようになればいいわけですが…）
aliasingであと気になるのは、adaptive anti-aliasingの問題と、
最近普及してきたHDRでの出力とのanti-aliasingの共存です。
adaptive anti-aliasingはどうも分割の指標があいまいなので、
これがレンダラの個性としてモロに出てしまっている場合が多々見受けられます。
もちろん、必要無いと思う個性ですので、何か決定的な手法が出て欲しいと思っています。
あと、HDRでの出力とのanti-aliasingの共存については、例えば高輝度の面光源の
エッジが通常の方法ではanti-aliasingされないといった問題です。
「表示の時は」すべてピクセルの最高輝度にクリッピングされるので、
この状態ではanti-aliasingをした意味が全く無くなります。
何度か色々な人と話したのですけど、特にコレといったconsistentな解決策は
まだ無いような気がします。何かあったら教えていただけると幸いです。
Beeさん，こんにちは．
ウェブサイト時々拝見しています．Parthenon，素晴らしいですね．
私はレンダリング画像をHDR形式で出力した事がないのですが(floating point形式ならあります)，
恐らく仰っているのは，非常に高輝度なサンプルポイントと，
その隣のそれほど明るくないサンプルポイントでのaliasingの事ではないかと思います．
この話はいつか記事として書きたいと思っていますが，現在のところ，
レンダラ側ではカバーできない問題(少なくとも実務では)で，専らcompositorの腕に頼っている状態です．
自然界の凄さを思い知りますね．:-)
ウェブサイト見ていただいてありがとうございます：>
仰るとおりの問題です。HDR形式というより、
High Dynamic Rangeな「計算」をしている場合でも
（出力はLDRでも）生じる問題ですね。
確かに現時点ではcompositeの段階で処理するのが多いでしょうね。
特に、現実にはこのような高輝度のものにはglareが生じるので、
aliasingが単なるblurによって消されていたとしても
それほど違和感は無いのではないかと思います。
もしかしたら現実でも（写真や裸眼）glareを取り除くと
aliasingが見えるのかもしれません。