ZDefocus #3

続き

 

前回、

ちなみに、"差"が極端に狭いところであったとしても、ほぼほぼ画面一面、等しい値だけど、とても小さいエリアで値の変化があったとしてら?しかも、そこのアルファチャンネルの値が0でくり抜かれている部分だったとしたら?
残念ながら、これでも遅いままです。差が最終的なボケのサイズ換算で、30%ぐらいまでの差であれば、まだ若干はマシなのですが、50%ぐらいの差が出てしまうと極端に遅くなります。 

 

って文章で終えてますが、これは、一部正しくて、一部間違えています。

ちょっと例を見てみましょう。

depthの一部に、1ピクセルだけ変化を加えます。

 

 

というexpressionを用いて、

 

f:id:masahiroteraoka:20170115113717p:plain

 

一見何も変化ありませんが、左下隅(x,y座標で 0,0)のところに、1ピクセルだけ黒ができてます。

 

f:id:masahiroteraoka:20170115113921p:plain

 

これで、zdefocus処理を確認してみたところ、このexpression有無で速度は特に変わりません。

 

ピクセルエリアを増やしてみます。20x20にしてみましたが、それでも、特に速度は変わりません。ストレス無く処理を終えれます。

さらに、depthにblurを掛けてみます。blurの値5で掛けてみました。

 

f:id:masahiroteraoka:20170115115042p:plain

 

こんな感じ。そうすると、zdefocusの速度に変化が現れます。

 

 

後半が、depthにblurを適応したものです。前半はblurがdisableになってます。

このように、アルファでくり抜かれている部分で、一見zdefocus処理が行われていないエリアのように思いがちなところでも、速度低下が起こっているの確認出来ます。

しかもscanlineの動き方を見ていると、どうも、そういうエリアがscanlineに当たる部分で遅くなっているように見受けられます。 

 

もう一つテストをしてみます。

前回、同一のdepthの値をアルファでくり抜いただけで遅くなりましたが、今回のblurの有無テストから、それは、くり抜いたエッジ部分にアンチエイリアス処理がはいり、”段階”が出来ているためではないかと推測ができます。

なので、くり抜きに"段階”が出来ないようにくり抜くアルファのエッジを0か1の値にしてみます。

expressionを用いて、

 

をmask用のrotoの直下に入れました。

 

f:id:masahiroteraoka:20170115121024p:plain

 

結果のキャプチャーは下のムービーです。前半がrint(a)処理なし、後半がありです。

 

 

アンチエイリアス処理を無くして、二値化した後半の方が断然速いのが分かると思います。

ココまでことでも、考察されるように、zdefocusはdepthの値の差があると遅くなり、それは、その差の大きさに依存するわけではなく、その値のバリエーションに依存することが推測できます。

 

では値の差をバリエーションを減らすとどうなるのか?をもう少し検証してみます。

前回用いた、rampで画面一面でdepth値が変化するようにしたモノを用います。

 

gradeノードとexpressionを用いて、rampで生成した0-1のグラデーションのをガタガタにします。

 

f:id:masahiroteraoka:20170115122740p:plain

 

expressionに入っている式は、

 

 

 

一つ上のgradeノードと連動するにようになっています。例えば、上のgradeので0-1の値を5倍して、0-5にして、それをrint(r)で、すべて整数値にして段階を減らし、それを5で割って0-1にfitさせてます。

depthはこんな感じになります。

 

f:id:masahiroteraoka:20170115123326p:plain

 

左がオリジナル、右が処理したモノです。

結果は下のキャプチャー動画です。前半がガタガタ処理なし、後半がありです。

 

 

後半の方が速いということが確認出来ます。

結果としても割と同様のように思えるのですが、これはやはり違いが生じています。

一部によって確認してみると、

 

f:id:masahiroteraoka:20170115124449p:plain

 

左がオリジナル、右がガタガタ処理を加えたものです。

当然ながら、このような違いが発生します。クオリティー的に問題があります。

ともあれ、処理としては、かなり高速化が図れます。作業中だけでも、これを利用するっていうのは、アリかもしれません。

 

で、実はこの機能、zdefocusのデフォルトの機能として存在します。

 

f:id:masahiroteraoka:20170115124847p:plain

 

この”layer”の部分です。

ココの"automatic layer spacing"のチェックを外して、"depth layers"の値を4とかに落としてみると、かなり結果が表示されるのが速くなります。
先ほどのdepthにガタガタ処理を加えたモノと結果もにかよっています。

 

zdefocusがどうしても遅くて作業にならないとかの場合、この"depth layers"の値を落として、"automatic layer spacing"に 

 

 

とかを入れても良いかもです。こうしておけば、ネットワークレンダリングでこのnukescriptが走る際は、自動的にこの"automatic layer spacing"がオン、作業中はオフというふうにできます。
※ただし、ネットワークレンダリング、つまりnuke_rライセンスでnukeが動いている場合のみ"automatic layer spacing"がオンになります。ローカルレンダリングには利きません。

 

と、zdefocusが遅くなる原因が、これでだいたい理解できるのでは、と思います。

 

zdefocusの特徴はもう少し説明しないと、細かくコントロールできない部分があるので、それはまた次回。

※まとめ
depthの値にバリエーションが多いと遅くなる。また、個々の値の差が大きいとそれも速度低下につながる。