流転四界ぶろぐ

自分は一応理系をうたってはいるが、512円とか1024メートルなどという数字を見たら「半端だなあ」と思う程度には凡人である。しかし、これが512バイトとか1024ピクセルという単位に変わると、「お、キリがいいね」と思う程度にはアレである。

コンピュータは今のところ「スイッチがONになっている」と「スイッチがOFFになっている」のどちらかしか判断できない。有るか無いかの二者択一だ。その組み合わせを繋げていくことによって、膨大な数を表現している。二進数というやつだ。この数は2の乗数で表される。人間が概ね10進数を使い、100とか1000といった数をキリがいいと感じるように、コンピュータは8とか256とか1024といった数をキリがいいと感じる。いや、感じているかはわからないけど、無駄なくスマートに扱うことができる。Poserのレンダリング設定のバケツサイズが32だったり64だったりするのは、その単位で計算した方がコンピュータにとって無駄がないからだ。

すると、テクスチャも1024ピクセルや4096ピクセルといった大きさで作成した方がいい、ということになる。もちろんその方がメモリを効率よく使えるだろう。では、レンダリング速度に関しては影響するのだろうか。キリのいい画素数の方が、早くレンダリングできるのだろうか。

というわけで実験。あ、Fireflyでは誰かがやってた気がするので、Superflyだけ。

使用するのはDante78さんの中世ビール醸造所。この人の作品はどれもプロモ画のそっけないミニチュア感が、なんというか仄淡い郷愁を誘ってくるのでとっても好みなんである。しかし、どうもいつもレンダがもっさりする。作りもマテリアル構成もシンプルなのにである。

そこで使用されているテクスチャを確認し、なるべくキリのいい画素数にリサイズして、レンダリング時間を比較してみる。

表1: Medieval Breweryのテクスチャと画素数

File Name	Original Size	Resize
Medieval_Brewery_Ground_A_Txt	2700×2700	2816×2816
Medieval_Brewery_Ground_A_Bump	2700×2700	2816×2816
Medieval_Brewery_Ground_B_Txt	2800×2800	2816×2816
Medieval_Brewery_Ground_B_Bump	2800×2800	2816×2816
Medieval_Brewery_Objects_Txt	3500×3500	3584×3584
Medieval_Brewery_Objects_Spec	3500×3500	3584×3584
Medieval_Brewery_Objects_Bump	3500×3500	3584×3584
Medieval_Brewery_Roof_Txt	2700×2700	2816×2816
Medieval_Brewery_Roof_Spec	2700×2700	2816×2816
Medieval_Brewery_Roof_Opa	2700×2700	2816×2816
Medieval_Brewery_Roof_Bump	2700×2700	2816×2816
Medieval_Brewery_Structure_Txt	3500×3500	3584×3584
Medieval_Brewery_Structure_Bump	3500×3500	3584×3584
Medieval_Brewery_Wall_Ext_Txt	3500×3500	3584×3584
Medieval_Brewery_Wall_Ext_Bump	3500×3500	3584×3584
Medieval_Brewery_Wall_Int_Txt	3000×3000	3072×3072
Medieval_Brewery_Wall_Int_Bump	3000×3000	3072×3072
Medieval_Brewery_Wood_Roof_Txt	2300×2300	2304×2304
Medieval_Brewery_Wood_Roof_Spec	2300×2300	2304×2304
Medieval_Brewery_Wood_Roof_Bump	2300×2300	2304×2304

ただし、Jpegは再保存するたびに情報が劣化するし、圧縮率などの設定項目もある。元の設定がわからないので、とりあえず画質100%のプログレッシブ形式で上書き保存した。普段なら絶対やらないことだけど。さらにPNG形式で、同様にオリジナルサイズとリサイズしたファイルの二種を用意する。シーンファイルはコピーして、エディタで拡張子のjpgをpngに書き換えた。パスなどには影響されないよう、拡張子以外のファイル名は同名とし、差し替える時はランタイムのフォルダごと差し替える。

表2: テクスチャファイルの形式とファイルサイズ

-	Jpeg		PNG
	Original	Resize	Original	Resize
Total file size	177.3 MB	137.6 MB	244.4 MB	247.3 MB

リサイズする画素数は256で割り切れる数字で、元より大きくなるようにする。Jpegでは再保存したことでファイルサイズが小さくなっているが、PNG形式では大きくなっていることがわかる。

シーンにはアイテム以外なにもロードせず地面も非表示、無限光1灯に拡散IBL1灯。レンダリング設定はデフォルトのまま。Poserを起動してシーンファイルをロードし、レンダリングボタンを4回押して、ログウィンドウを確認するだけの作業だ。

毎回、レンダリング自体はものすごく早い。最初のブロックが現れてからたぶん2秒ぐらいしかかかってない。しかしその前、レンダリングボタンをクリックしてから最初のブロックが現れるまでに顕著な差がある。

この時。なのでやっぱり、テクスチャまわりで時間がかかっているんだろうな、とは思う。

というわけで実際にレンダリングを繰り返した結果がこちら。

表3: ログによるレンダリング時間の比較

-	Jpeg		PNG
	Original	Riseze	Original	Resize
Rendering Memory (MB)	645	675	645	675
1st Render (sec)	45.15	39.76	11.93	7.28
2nd Render (sec)	29.55	26.51	5.93	6.19
3rd Render (sec)	29.98	28.32	5.87	6.15
4th Render (sec)	30.86	26.88	5.89	6.18
Average 2nd-4th (sec)	30.13	27.24	5.90	6.17

まず最初に、レンダリングメモリはJpeg・PNGともにリサイズした方が増えている。このことから、レンダリングメモリはファイルサイズや形式ではなく、テクスチャの総画素数に依存することがわかる。

次に、初回と2回目以降のレンダリングでは、2回目以降のレンダリングの方がどのケースも早い。初回はテクスチャを読み込む時間自体が含まれるからだ。2回目以降のレンダリング時間にはほとんど差がないので、その平均も並記している。

そして初回のレンダリング。オリジナルサイズよりも、リサイズした方がJpegもPNGも早くなっている。Poserはテクスチャをメモリに読み込む際、キリのいいサイズの方がすんなり行く、と考えていいだろう。もしかしたらメモリに展開するときに、内部でキリのいいサイズにリサイズしているのかもしれない。

しかし、問題は2回目以降のレンダリングである。こちらはJpegでは早くなっているが、PNGでは逆に少しだけ遅くなっている。レンダリング速度は画素数ではなくファイルサイズに関係しているのだろうか。

そして、Jpeg自体がPNGに比べて圧倒的に遅いのも気になる。

Jpegにリサイズする時は、Photoshop CC 2017で画像解像度を変更して上書き保存した。いつものように書き出しメニューを使うと、ファイルサイズが極端に減ってしまって、検証に影響がでるかもしれないと思ったからだ。しかし書き出しメニューを使わない場合、Photoshopはファイル自体にいろんな情報を埋め込んでしまう。ひょっとして、それらが何か悪さをしていないだろうか。

というわけで、元の画素数のまま書き出しメニューを使用したJpegのファイル群も用意してみた。画質は100%のまま、プロファイルやメタデータの埋め込みは行わない。

で、結果がこれ。

表4: ログによるレンダリング時間の比較（再出力含む）

-	Jpeg		PNG		Export Jpeg
	Original	Riseze	Original	Resize	Original	Resize
Total file size (MB)	177.3	137.6	244.4	247.3	157.1	75.5
Rendering Memory (MB)	645	675	645	675	645	646
1st Render (sec)	45.15	39.76	11.93	7.28	7.52	7.56
2nd Render (sec)	29.55	26.51	5.93	6.19	6.12	6.10
3rd Render (sec)	29.98	28.32	5.87	6.15	6.04	5.79
4th Render (sec)	30.86	26.88	5.89	6.18	6.12	5.80
Average 2nd-4th (sec)	30.13	27.24	5.90	6.17	6.09	5.90

めっちゃ早くなった。

このことから、一番のボトルネックになっていたのは画素数でもファイル形式でもファイルサイズでもなく、画像の保存方法だったことがわかった。その上で、初回のレンダリングにはキリのいい画素数であるかどうかが関係し、2回目以降のレンダリングでは、ファイルサイズ自体が小さい方が早くなることがわかった。しかし、今回のようなアイテム単体のシーンでは、差はまだそれほど大きくないことも読み取れる。

というわけでまとめ。

1. まず、ファイルパス正しく保たれるように、画像はRuntimeフォルダの中に保存する。読み込み時に検索がかかっては元も子もない。
2. ファイルを保存する時は書き出しメニューを使用し、余分なデータを含まないようにする。あと、画質も無駄に高くしない。80%もあれば十分である。
3. 画像はなるべくコンピュータにとってキリのいい数字、256の倍数で作成する。あと正方形だともっといいかも（未検証）。
4. マテリアルやマップによっては、解像度がそこまで必要ないものもある。そういうものは縮小してファイルサイズ自体を小さくしてしまおう。

レンダリング中、テクスチャ読み込みでもっさりするような時は、元テクスチャを再書き出ししてみるのもアリかもしれない、ということだ。おかげでずいぶん軽快になった。

内側から見てもいい感じ。

ところでライトというものは、二次減衰するものである。

いきなりなんだと思われたかもしれないが、日頃ウダウダと考えていることの取りかかりとして、少し確認しておきたいことができたので。

光というものは電磁波であり、揺らぐ場そのものであり、その伝播そのものが時空……すなわち距離と時間を定義する。

確かそんなだったと思う（逃）。

この電磁波というやつは、別のものにエネルギーを持っていかれない限り、どこまでも進む。いつまでも進む。なにせ宇宙の始まりからいまだに進んでいる。

いやでも、実際離れたら弱くなるよね？　と思ってしまうのが、いわゆる逆二乗の法則というやつである。だいぶ昔にも書いたかもしれないけども、図にするとこんな感じ。

光源から離れると、離れたぶんだけ光は広がっていく。同じ光の量が、より広い面積に照射されるから、一区画だけを見れば光の当たる量は少なくなるのだ。

距離が倍になれば面積は4倍になる。一区画あたりの光の量は1/4。距離が3倍になれば面積は9倍。最初の地点での明るさの1/9になってしまう。だけど、いつまで経っても0になることはない。

だから本来、Poserのポイントライトやスポットライトに終点距離が存在するのは、物理的におかしいんである。旧来のPoserのライトは減衰の始まる地点と完全に0になる地点を設定し、中間の明るさを均等割りしていく。それは直感的にはわかりやすいかもしれないが、物理的に素直な計算をしようと思うと、どうしても障害になる。

そういうわけで、PoserではIDLが実装されたバージョン8で、ようやく二次減衰を扱うことができるようになった。

距離が倍になれば明るさが1/4になるライトである。しかしこれは実際に使ってみるとなかなか調整が難しく、妥協の産物のように明るさが距離の反比例になる反比例ライトというのも同時に追加されている。

さて、それでは「距離が倍」というのはどういう意味だろう。もちろん基準というのはなんでもよくて、例えば1メートルの距離で明るさが1なら、2メートルの距離では0.25になる。それはわかっている。知りたいのは、Poserのライトは強度が100%のとき、いったい「どの基準で100%になるのか」という点だ。

じゃあ測ってみよう。

シーンの中央にポイントライトを一つだけ設置する。色は白、強度は100%。で、それに照らされる真っ白な板を用意する。鏡面反射その他のパラメータはちゃんと0にしておく。この板をライトから離していけば、どんどん暗くなっていく。その色つまり輝度で、何パーセントの光が板に当たっているのかを測定する。

簡単のために、背後に別の板を配置する。こちらは拡散反射も鏡面反射も0、環境色と環境値だけが設定された「発光する板」だ。この板はライトの影響を受けず、どの距離どの向きにあっても同じ明るさに見える。環境色を白にして、環境値を0.25にする。この発光する板と照らされる板の明るさが同じになったとき、照らされる板はちょうど「基準の倍の距離」に位置することになる。

なんで100%の明るさでやらないのかというと、白飛びしてしまってわかりにくいからである。あと、ガンマコレクション機能を使うとレンダ結果に「人間の目の明るい歪み」をかけてしまうので、FireflyのガンマコレクションOFFの状態で確認する。

表1: 表面輝度とスポットライトの照射距離の変化

表面輝度 [%]	66.7	50.0	25.0	20.0	11.1
ライトからの距離[PU]	1.23	1.42	2.00	2.25	3.00

結論から言うと、「たぶんそうだろう」と思ってPoser単位で測ったら、そのまんまだった。

つまりポイントライトやスポットライトは、1Poser単位の距離にあるとき設定された強度そのままの明るさで対象を照らすライトである、ということだ。

ところで1Poser単位は8.6フィートである（ちっ）。8.6フィートは2.62メートル。つまり二次減衰する100%のライトは、2.62メートルより近い距離にあると、とんでもなく色飛びする強烈なライトということになる。近いと目茶苦茶明るいくせに、離れると一転、急激に暗くなる。

最近はガンマコレクションを使う人が多いだろうし、Superflyではオフにするという選択肢がないので、この曲線にガンマ補正をかけてだいたいこんな感じ。

暗い部分が持ち上がるから、減衰がゆるやかになっている。

で、明るすぎる部分を調整するには、もちろんライトの強度を落とすわけだけども。具体的にどれぐらい変化するのか、ガンマ補正2.2、距離をメートルに直してプロットしてみた。

明るさが10%でも、1メートルの距離ではまだまだ明るいようだ。逆に、5メートルを超えるあたりからは変化がなだらかになる。つまり補助ライトを当てるときは、対象から5メートルぐらいは離してやらないと、ちょっとの変化で明るさがやたらと変わってしまうというわけだ。逆に十分に距離をとってやれば、その値はだいたい見当がつく、ということになる。

はたして。

理論に裏打ちされた妄想癖、っていう。

引き続いて、コメントなどで頂いてたツッコミをネタにしてみる。

「Fireflyだと建物の角が削れてるように見える」

なるほど確かに面取りされたように陰影のつき方が二段階になっている。実際のところはどうなんだろう、というわけで近づいてみた。

Fireflyだけ小石が見えているのはこの際気にしないでほしい。で、実際には形状は面取りされてないことがわかる。つまり影のつき方がおかしいわけだ。これはFireflyでレイトレースシャドウを使用した場合に、Shadow Min Bias（影の偏り）によって自分自身の影、いわゆるセルフシャドウの位置が現実の位置より大きくずれてしまったために起こる。細かな解説は昔書いた気がする。記事自体が古いので、現状と一致しない部分もあるけど、まあ参考程度に。より正確に影を描画するには、シャドウバイアスの値を小さくする。

そういえば、非平面ポリゴンの描画はいつの間にか改善されてたみたい。あの不気味な斑点が出ないようになっている。ちゃんと進歩してるんだなー。

「ドーム型GROUNDをSuperflyでレンダするとIDLが効かない」

sannziさんからコメントで頂いた件。色々検証して頂いたおかげで原因がはっきりしたのでまとめておく。まず、基本小道具を組み合わせて、こんな感じのシーンを作ってみる。で、IBLライト1灯だけでレンダする。

拡散IBLライトはPoser 6で実装された時、面の向きとそれに対応する画像の色によって色が決まるライトだった。障害物があってもなくても同じように色付けされてしまうので、強度を上げすぎないようにしたり、AOノードで陰影をそれっぽく追加してやる必要があった。

Poser 8でIDLが実装されると、この拡散IBLの仕様は一部変更になった。IDLが使用されているときだけ、拡散IBLは無限遠からシーンを球のように包み込むライトとなったんである。したがって、無限遠とシーンとの間に遮蔽物があれば、拡散IBLは遮られることになる。

箱の中はほぼ前面のマゼンダ色だけに影響を受けている。あと開口部付近に上面の赤や左面の黄色が出ているのがわかる。

つまりこれはSuperflyの問題ではなく、FireflyでもIDLを使用する場合には起こりうる現象だったわけだ。もちろん考え方としては、遮蔽物があれば光はそこで遮られる方が現実的である。シーンがドームに覆われていれば、中のものが外の光を受けることはない。

とは言ってもFireflyには抜け道がある。遮蔽物オブジェクトの特性パレットで、Light emitter（発光体）をオフにすればいい。

これはもともと「カメラには映らない発光体」のようなものを扱うための設定だけど、これをオフにしているとき、二次反射光の計算はそのオブジェクトを無視するようになる。つまり遮蔽物オブジェクトを素通りするわけだ。

ではSuperflyではどうなんだろう、と試してみると、どうもSuperflyではこのLight emitterが効いてないみたい。Visible in Raytracingのチェックを外せば同じようにIDLの計算から外すことはできるけど、その場合は反射とかその辺の計算からも外されてしまうので、映り込みの可能性のあるレンダでは要注意だ。

そういうわけで、IDL使用下で拡散IBLを使用する場合は遮蔽物の有無に気をつけなければいけない。Superflyでドームを使うなら上半球、空のマテリアルの環境値を全開にして、ドーム自体を発光させてしまえばいいかな。

「P11のFIrefly、バンプがきつくなってる気がする」

P7（なんとか動いた！）で簡単なシーンを作って、カメラ・ライト・小道具をライブラリに登録。バージョンの違うPoserでそれぞれロードして、同じFirefly設定でレンダリングしてみた。

基本的に違いはないみたい。

ただし、Poser Pro2010からガンマコレクション機能が追加されている。バンプマップのガンマコレクションを特に弄ってなかった場合、2010ではイメージマップノードはデフォルトの「レンダ設定の値」で読み込まれる。なのでそのままガンマコレクション機能を使うと補正されてしまい、バンプの効きは弱くなる。

床面の凹凸がちょっと弱くなってるのがわかるかな。

Poser 11はバンプマップに接続されたイメージマップノードはデフォルトで「個別に設定→1.0」のガンマ設定になっている。なので両者をデフォルトのまま使うと、単純に効きは強くなっているかもしれない。動作的には1.0になっているのがあるべき姿なので、バンプが効きすぎていると感じたら自分好みに値を調整するのがいいかもしれない。

以上。まあこういうの、ちゃんと書いておかないと自分で忘れちゃうしー。

さて、そういうわけで宿題になっていたPoserの小ネタを拾い上げていこうかなと思う。

前々回のSuperflyで被写界深度を試してみた話。で気づいたAOノードの最下欄、いつの間にか追加されてたEvaluate in IDLという項目。どうも2014にはあったっぽい。

また、AOはノードだけでなくライトでも別枠で設定できるけど（たぶんそっちを使ってる方が多いと思う）、ライトの特性パレットにも項目が増えている。

Evaluate in light ……なんで名称が違うのかツッコミたいところだけど、たぶん同じものを指しているんだと思う。

というわけでさくっと基本小道具を並べてみる。

拡散IBLライト1灯＋無限光1灯。Fireflyでガンマコレクションを使用せずにレンダリング。無限光の影になっている部分が、均一な暗さになっていることがわかる。

AOが実装されたとき、それは細かな影の計算が行き届かず、不必要に明るくなってしまう細部を黒く塗りつぶすというシェーダだった。

で、Poser 8でIDLが実装されたとき、このAOによる塗りつぶしは機能しなかった。

確かにライトの当たっている立方体の側面は暗くなってない。というか逆に照り返しを受けて明るくなっている。しかし影になっている部分でも、きちんと陰影が現れていることがわかる。

もともとIDLは二次反射光を丁寧に計算しますよ、というものだ。直接光が当たっていなくても、近くにある物体から拡散反射したわずかな光を計算し、明るいところは明るく描画する。どんな光も当たってないところは暗いまま。そういう計算をちゃんとしていたから、「狭そうだから塗りつぶしてしまえ」という、AOの擬似的な陰影描写はそもそも不必要だった。

とはいうものの、IDLを使いつつAOのオオザッパーな陰影付けはそれはそれで欲しいとか、陰影付け以外の用途で使ってた（自分のことだ）から使えるようにして欲しい……みたいな要望はやっぱりあったんだろう。

では拡散IBLと無限光、別々に効果を確認してみる。まずはライトの設定のEvaluate in lightから。

無限光では立方体の明るい部分がなくなり、ドーナツの下などにぼんやりした影が現れている。一方の拡散IBLライトでは変化は見られない。このことから、Evaluate in Lightは無限光（など）のAOを描画する機能だとわかる。

実際、無限光のIDLを計算中、赤い点の中に見慣れない黒い点が現れている。

じゃあ、ノードによるAOはどうなんだろう。

なんとこちらは、チェックを外した状態でIDLでも陰影が描画されているので、どちらも変わらないという結果になった。計算中は確かにチェックを入れた状態だと黒い点々が現れるんだけども、レンダが始まると結果はまったく同じなんである。じゃあ追加した欄の意味ないじゃん！　とツッコミそうになったけど、もしかしたら自分の何かしらの設定ミスとかあるのかもしれない。なんか自信なくなってきた。

ええっと。

Fireflyでの効果はわかったけど、じゃあSuperflyでの効果はどうなんだろう。といいつつ、これはもう結果がわかっている。SuperflyではAOノードを接続してはいけないと怒られた。だからノードによるAOはそもそも描画できない。代替拡散に乗算で繋いで……というようなことも試してみたけど、どうやらAOの計算自体が行われなくなるみたいだ。で、ライトのAOもFireflyのIDLと同じく無効になる。

Superflyは基本、物理的に正直な計算を行うレンダラだから、二次反射光の計算はもちろん行われているし、むしろ計算しないという選択肢がない。したがって陰影はちゃんとついている。擬似的な陰影付けのAOは不要なのだ。というか、今のところSuperflyで従来の「嘘をつく系」シェーダは使わない方がいい、ということなんだろう。トゥーンにしろベルベットにしろ、AOにしろ。どうしても今使いたいという人は、Cyclesグループの中にBrender版のシェーダがちゃんとあるから、ぜひトライして詳細を教えて欲しい（笑）。

こちらは比較のためにFireflyでガンマコレクションを2.2にしてレンダリングしたものとSuperflyレンダ。多少の差はあるものの、だいたい同じような結果になっているのがわかる。狭い部分の描画はやっぱりSuperflyの方が正確だ。

ちなみに、Superflyでの拡散IBLライトはどうも強度にガンマコレクションがかかってるっぽい。

IBLに接続するべきhdr画像はガンマコレクションを必要としないし、そもそも本来的に「色」に補正をかけることはあっても「強度」に補正をかける必要はないはずなんだけど……。先ほどの比較画像で明るさがほぼ同じになっているのは、右側の色を調整したライトである。ややこしいから、もう諦めて強度の値を変化させた方がいいと思うけど（笑）。

まあこういう怪しい動作のところは、そのうちサイレント修正入るかもしれないけどねー。

流転閑語、お話の続きをアップしております。

次で完結予定。週末には上げられたらいいな～。

---

さてPoser。

あるとき眠れなかったので、そうだSuperflyでの被写界深度の表現はどんなもんだろうと思い立ち、さくっと背景セットをロード。さくさくっとライトを配置してf値を設定、SuperflyのレンダリングボタンをポッチリしてMacを放置した。寝る準備をしてから戻ってきたらレンダリングが終了していたので、そのままFireflyでほぼ同じ設定になるようにして、またレンダリングボタンをポッチリとやってからMacから離れた。おやすみなさい。

で、起きてからレンダリング結果を確認。どんなもんかな～。

ぼかしの品質がどうこう言う前に、なんかSuperflyのレンダ結果が暗いのが気になった。

ライトはほぼ白の200%無限光とHDR画像を繋いだ100%の拡散IBL1灯。どこに影響が出てるんだろうと思って、とりあえず無限光を100%にしてライトごとにレンダしてみた。

うーん、どっちもSuperflyの方が暗いなあ。

以前の検証で比較したように、単純な形状、単純なライティング、単純なマテリアルの下では二つのレンダラも結果にほとんど差が出ない。Superflyはデフォルトでガンマコレクションが効いているので、Fireflyもガンマコレクションのチェックを入れている。じゃあ差が出るのはどこだろう。複雑な形状、複雑なライティング、複雑なマテリアル、そのどれか。

……などと思いながら二つのレンダラを行き来しつつテストを繰り返してる内に、ふとレンダリング時間も確認しようかなと思ってiPhoneでストップウォッチを起動した。

あ、そういえば今のPoserってログを吐くようになったんだっけ。

ログというのはプログラムが裏でゴチャゴチャと頑張っているところの記録みたいなものである。確かそこにレンダリングの秒数が出てたような気がする。Poserのログウィンドウは右上の吹き出しアイコンで表示する。

オレンジ色になったら新しいログを吐いたよ、みたいな。

ふむふむ。Fireflyは6分33秒。Superflyは7分58秒。Superflyの方が1分半ほど時間がかかっている。なるほどなー。

と、ちょっと待て。Superflyレンダの方、なんか警告を吐いてる。

（意訳）警告：マテリアル○○を解釈してるときにエラーが発生したよ。SuperflyはPoserサーフェイスノードの拡散値と鏡面値にアンビエントオクルージョンノードは接続できないにょ。

なんだとぅ。

アンビエントオクルージョン（AO）はP6のころ散々お世話になった環境閉塞なあれである。

つまりこれがSuperflyだとエラーになるらしい。もともとAOというのは「狭くて光が入り込まなさそうなところに上から影を塗る」というシェーダである。だから初めから光の回り込みをちゃんと計算するIDLでは必要ないし、描画もされなかった。

そういえばAOノードの一番下に、知らない項目が増えてるな。Evaluate in IDL……「IDLで値を計算する」みたいなことだろうか。

……うん、君の事はまた今度確認するから。（←と書いておかないと忘れる）

物理的な光の経路をちゃんと計算するというSuperflyレンダラでは、AOノードはそもそもがエラーになるという事なんだろうか。どのみちFireflyでもIDLでレンダしてるシーンなので、全部のマテリアルからAOノードを切断していく。

ひええええ。

あ、明るくなった！　やったあ。

とりあえず、SuperflyではAOノードは繋がない方がいいってことかな。マニュアルにライトのAOは使用できないとか書いてあったけど、マテリアルの方も影響するということらしい。

ええと、何をやろうとしていたんだっけ。ああ、被写界深度だ。

というわけで無限光ライトを200%に戻してレンダレンダ。

部分を拡大するとこんな感じ。

ザラっと感が出るSuperflyの宿命で、もっとピクセルサンプリングを上げないと気になる感じかな。Fireflyの方が綺麗にボケてる。

ちなみにここで使ったFireflyのレンダ設定。

あとSuperflyのレンダ設定。

まあ、既知のネタかもしれないけど。気にせずこれからも体当たりしていこうっと。