良くライティング計算結果がNaNになってポストエフェクトでバグるというのが頻発していて困っていたのですが，
ようやく最近回避方法を知りました。
StackOverflowとかみていたら，
step(value, value) * value;
みたいにすると，NaNである場合には0になり，NaN以外の場合にはvalueで返すことが出来るらしい…。
と書いてあったのですが，よくよく考えてみるとstep(value, value)のところは確かにゼロとなるので問題ないなさそうに思えるのですが，NaNとの四則演算結果はNaNになるような気がします。実際に試してみたのですが，やっぱり駄目でした。
あとは，Googleのfilamentに
#define MEDIUMP_FLT_MAX 65504.0 #define saturateMediump(x) min(x, MEDIUMP_FLT_MAX)
みたいなのが書いてあったので，下記のような実装を試してみました。
static const float HALF_MAX = 65504.0; clamp(value, 0.0f, HALF_MAX);
結果として，NaNが発生しなくなりバグが解消されるようになりました。
自分なりになぜNaNが発生しなくなるのかを考えてみたのですが，NaNの性質として !=以外の演算は常にfalse, !=演算は常にtrueという性質があるようです。よって，clamp()メソッドを使うと比較演算が実行されるので，この結果としてNaNをはじいて指定範囲内に収まると考えれば非常に納得がいきます。ここではclamp()を試しましたが，同様の理屈が通るのであればmax()などでも代用できるはずです。
さて，特に物理ベースレンダリングに移行する際に，GGXモデルなどを使うことが多いと思うのですが，定式化されているものが除算を含む形で定義されているので，実装する際に除算をしなくてはならないということが発生します。
GGXの計算する際に，分母がゼロになることにより，ゼロ除算が発生し，計算結果がNaNになる可能性があります。
また，pow()関数を使用している場合は，MSDNのドキュメント にも書いてあるように第1引数が0未満の場合はNaNになり，第1引数・第2引数がともにゼロの場合はハードウェア依存によりNaNが発生する可能性があります。
昔からよくある方法としてゼロ除算を発生させないために，例えば1e-7fなどのような小さな値を分母側に足しておき，ゼロにならないようにオフセットを掛けるという回避方法もあるのですが，この方法は除算には適用できるのだけれども，pow()関数には適用できません。
GGXを用いたライティング計算の場合は，ゼロ除算が発生する可能性があるため最初はこのオフセットを足し込むというやり方を取っていたのですが，これをやってしまうと計算結果が変わってしまい，ハイライトが鈍くなるなど見た目上に影響を及ぼすことが分かりました。
PBRやっているはずなのに，何故かなまった感じの画が出る場合には，下駄をはかせてハイライトを潰してしまっていないかどうか確認するのを強くお勧めします。
下駄をはかせている箇所を下駄を取って普通に除算し，最後に上記のようなNaNをはじく処理をいれることで，ハイライトがなまったり，ライティング以降のレンダリングパスでバグるという問題を解決することが出来ます。また，pow()関数を用いる場合にも適用でき，NaNをなくすることができるので，NaNで困っている方はぜひ試してみてください。
※もっとより良い方法ご存知であれば，是非教えてください！
