独り言日記（2007/12）

独り言日記

ソフト音源（2007/12/31）

実家に帰ってきてますので、ひたすら趣味に打ち込んでいます。

昔のDTMの場合はSC-55とかSC-88Proとかのハード音源が必須（現在持ってるのはSC-55mk2とSC-8820です。もうほこりかぶってますが(^_^;;）で、ソフトのエミュレートでは質が悪いってのが定番だったのですが今は逆転しているようで。質のいい「ソフト音源」が各社から出ていますね。逆にハード音源は市場から消えてしまってます。

それと、音源もVST規格などでプラグイン化されており（音源の場合はVSTiという。他にエフェクタ類もVSTであります）、相性はありますがいろんなツールでプラグインを使いまわせるのが魅力です。

で、DTMマガジンに載っていた2GBくらいの「independence free」を試してました（DTMマガジン1月号に付属してます）。これは大きいうえに重い・・・。うちの1GHzのノートPCではつらいもんがあります。音はかなりいいですねぇ。ただ、フリーだけあっておいしいところを割愛しているというか、クラシックピアノ（グランドピアノ、アップライトピアノなど）が音源として入ってません。

で、フリーのピアノ音源を探してました。フリーで登録不要のもの（すぐにダウンロードできる）のみ列挙。

mda Piano

http://www.pluginspot.com/documents/30.html

polyphony(和音の発音)が最大32ですので、指を多く使う曲では足りませんでした。このpolyphonyって単語、DTMマガジンでも出てきてましたが、そのときに同時に発音できる最大数というわけではないようですね（残響などの場合も影響する？ということは、ピアノのペダルを踏んだ状態だとあっという間に32は超えてしまいますねぇ）。

4Front Piano Module

http://www.yohng.com/piano.html

特にパラメータをいじる設定はなし。

Prova

http://smatni.tripod.com/safwanmatnivstplugins/

ここのサイトの画像をクリックするとディレクトリが出てきますので「Prova.rar」をダウンロードして解凍します。これも特にパラメータをいじる設定はなし。

素人なんで感想書くのははばかられますが、4Front Piano Moduleの場合は音が明るい感じ、Provaの場合は4Front Piano Moduleと比べるとわずかにアタックが強い感じがします。が、どっちもいい音してますね。midiでの音の強弱（Velocity）をきっちり調整すれば結構リアルになる気が。Windows標準のMS-GSやRolandのVSC(Virtual sound canvas)とはぜんぜん音質が違います（＜私はここまでの時代しか知らなかったりする(^_^;;。10年以上前かな）。

それぞれで、インストーラがあるものがありますが「Windowsインストールドライブ/Program files/Steinberg/VSTPlugins」のディレクトリに解凍するのがデフォルトになってます。このディレクトリは、すべてのDAWで共有するVSTプラグインを配置するとよさげです。VOCALOIDのVSTプラグインもここにインストールされます。「Steinberg（スタインバーグ）」ってなんじゃい？と思ったのですが、スタインバーグ社というのがVST規格を考えた会社とのこと。

後、いまや各トラックごとに別々のソフト音源を割り当てる、しかもその音自体に独自のエフェクトをかける、なんてのが当たり前にできるんですね。PC内ですべて完結できるんだ、となんか時代の流れを感じてしまいました。シーケンサだけじゃなくてエフェクタもミキサーも音源もすべて内包された統合環境がある(DAW)、ってのは古い自分にはなかなかの目からウロコです。

趣味は細く長く続けるとして、今年ももう終わりですね。

来年はいろいろとやることは決めてまして、勉強・研究は延々と続くのですが自分自身の集大成ができればいいなぁと思ってます（趣味は無関係です。あくまでも仕事で、なんですが結局延長線上では趣味も入るのかな）。ほんとは今年は準備期間だったはずですが準備すらできなかったなぁという反省があります。来年も準備期間になるとは思いますが、ちょくちょく情報も公開していければと考えています。

それでは来年もよろしくお願いします。

64ビットの開発（2007/12/28）

間が空いてしまいましたが、最近64ビットマシンを触ってましたのでそれについて。Vista 64ビットのもの。

開発ツールですが、VisualStudio 2005 Expressでは64ビットコードを出力できませんので、Standard版を購入しました、いまさらですが(^_^;;。インストールするだけで半日はかかるという（SP1も当てないといけませんので）過去のいやな経験があったのですが、今回もやっぱりそれくらいかかりました。

ビルドはうまくいったのですが、OpenGLまわりがやたらと不安定。nVIDIAのQuadroなんですが、標準に入っているドライバではボロボロのようでドライバを最新にすると今までの不安定さがウソのように解決しました。これがうわさに聞くVista不安定の根源の１つか。しかし、Vistaは発売から1年は経過しただろうに、ドライバが未だに不安定なものを入れたままなのはどうかと(^_^;;。＞DELL

急いで確認しないといけなかったので駆け足だったのですが、速度はあんまり体感できないですね。64ビットって何が魅力なんなのだろう（プログラムの内部的な動きとしては重々理解できますが）、というのが第一印象。せっかくのDualCoreですので加えて64ビットプログラムも掘っていかねばと思ってます。3DCGやDTMでは利用価値あるでしょうけど、Office（Word/Excel/PPTなどを含む普通のビジネス分野）とかで64ビットなんぞ使わんよなぁ・・・。普及率はどんなもんなんでしょうね。

関係ないですが、DTMマガジン別冊（the VOCALOID CV01 初音ミク）が出たので買ってきました。初音ミクの使い方が詳しく乗ってますね。後、DTMマガジンも購入。現状まじめに遊べてないので、正月中にいじっておこうかな。

後、メタセコに慣れるための習作モデリングが途中で止まってるのをやるのと、Maxwellを掘るのが結局今年中にはできてなかったので消化したいところ。

どうにか（2007/12/18）

振動の問題は解決。これで、今まで貯まっていた作業を一気に消化できそうです。気になる問題があってそれに取り組むとなかなか先に進めないんですよね。

オフィスの暖房ですが、電源入れてないだけでした(^_^;;。一晩中気づかなかった・・・。ただ、暖房入れるとなんかほこりくさくなったため結局厚着して作業することに。

徹夜（2007/12/17）

バグとれない・・・。理論通りに行くと振動しないんだけどなぁ。何かが抜けているに違いないということで泊まり込みで追ってみることに。もうちょっとな気がするんですが、、、。いやはや、一日は24時間では足りません。集中できているのかというと疑問ではありますが(^_^;;。

仕事場の引っ越しを先日日曜に行いました。今は新オフィスです（前のオフィスから数メートルな場所なんです。歩いても数歩もかからない場所）。なんか暖房が壊れているのか効いてないような・・・。息抜きにピアノ練習入れてます。というか、ピアノ練習したいがために泊まり込んでるってのもあります。忙しくなると、なかなか手をつける余裕がないんですよ、でも毎日練習はしてます。

さて、本日30時くらいまでにはバグを解決したいところ。がんばれ、自分。

再び振動と格闘中（2007/12/14）

仕事にて。物理処理のプログラムなんですが、欲を出して独自理論で接触判定などしていたら振動（ダンピング）がなかなか収まらない・・・。一般的なばね計算と減衰（ダンパー）では対応できるのかなぁと思って実装を試みてみたのですが、まじめにやると計算時間がかかるなぁと。というよりもなかなか思い通りには行かなかったです（計算間違いしてるのかな）。Featherstoneという手法で鎖の表現が割と楽にできるのは分かったのですが、それよりも砕けた（計算量の少ない）やり方で実装することに。厳密な物理シミュをやるわけではないので、いいかなと。

でも、接触に関してはばねとは別処理で、どうもここのめり込みの押し返し処理にて振動が起こっている模様。結局今週いっぱい悩んでました（まだ解決できてない）。この接触・衝突判定についても独自理論を実装してみました。結構速いかもしれない。物理計算なのに部分的にレイトレーシングしてます（笑）。空間分割は前処理で一回だけしてるので、たぶん制限をかけるとリアルタイムに使えそう（というか使ってます）。実は仕事で過去に納品したプログラムでひそかにリアルタイムレイトレしてるものって何個かあったりします（レンダラじゃないです。なんでやねん、ってところで実はレイトレしてたり）。今回はさらにこれを改良して使ってます。

球や平面との衝突判定は楽なんですが、衝突物体がポリゴンメッシュとなればODEも速度的に厳しいですね（跳ねまくるし）。まだまだ物理計算に関しては中途半端な知識しかないですが、極めればODEの速度を超えるのは意外とできるのかもしれない。

けど、わき道でばねやら鎖やら勉強したおかげで別の知識が身についた感じです。

続・光の単位（2007/12/09）

教えていただいたサイトです。

http://www.anfoworld.com/

ここの「光と光の記録 - 光編」のページの「輝度を測ってその輝度を持つ面光源の面積をかけると光度が導きだされるのではないかと考えがちですが、それは間違いです。」が私が間違ってる部分すね。ずばり、輝度（cd/m^2）に面積かけて「あれ？」ってなってました（汗）。

このページにそれぞれの単位の相関図がありますので勉強勉強。

教室の資料（2007/12/09）

撮っておきました。教室の前の黒板（向かって左側の太陽光のみが光源）。

黒板消し拡大（同じく向かって左側の太陽光のみが光源）。

教室の後ろの黒板（右の窓からの太陽光＋蛍光灯）。

前レンダリングしたのが寸法がめちゃくちゃだったので、もうちょっと現実のデータを元にモデリング＆レンダリングしてみようかなと。元中学校の施設の写真なのですが、一部昔の設備が残ってたりします。実は今のオフィスとその隣の会議室の写真です。

光の単位（2007/12/09）

Maxwellでの光で「Luminous power（lumen）」「Illuminance（lux）」「Luminous intensity（candela）」「Luminance nit」の４つとワットがあるのですが、これの相互関係はどうなってるのだろうか、と計算してみました。

Maxwellは直接照明だけにもできるんですね。こっちのほうが分かりやすいので、光の単位を変えつつ、レンダリング結果を目分で確認。

MaxwellのマニュアルとWikipediaから総合して判断すると以下のような表になりそう。

http://sunlight.k.u-tokyo.ac.jp/light.html

も参考にしました。

Maxwellでの表記	単位	意味
Luminous power（lumen）	lm	ルーメン 。点光源が1ステラジアン( = 1/4π)の立体角内に1カンデラ放出するときの光束(luminous flux)。国際単位（SI）で扱う。半径1メートルの球の表面積（4π）あたりの光量とも言えそうです。
Illuminance（lux）	lum/m^2	ルクス。照度をあらわす。1平方メートルあたり1ルーメン。ルーメン(lm)を面積で割ればよい。
Luminous intensity（candela）	cd	カンデラ。光度（luminous intensity）。点光源からの立体角あたりの光束。国際単位（SI）で扱う。
Luminance nit	cd/m^2	輝度 (luminance)。単位面積（1平方メートル）あたりのカンデラ。カンデラ(cd)を面積で割ればよい。

例えば、0.25 x 0.25メートルの面積を持つ面光源があり、単位面積（1平方メートル）あたり50000カンデラの光を放出しているとします。

この場合は、「50000 cd/m^2」（nit）は確定。ルーメンの計算は

1カンデラ = 4πルーメン

より、「50000 / (4 x π）= 3978.9 lm」でルーメンは求まりました。「4π」というのは半径1メートルの球の表面積(1.0/ステラジアン)ですね。1カンデラと書くと単位面積での式か分からないので、

1 (cd/m^2) = 4π(lm)

と単位を付けた方が理解しやすそう。

カンデラ(cd)は単位より全面積での光の量っぽいのですが、50000 x (0.25 x 0.25)じゃないのね。「50000 / (0.25 x 0.25) = 800000 cd」でレンダリング結果は一致した模様。あれ？計算と合わない・・・。

後、上記計算でも明るさが完全一致ではないようでした（微妙に異なる、、なんでだろう）。

CG MAGIC（2007/12/09）

秋葉原行って買ってきました。数ヶ月に一回くらいしか秋葉原には行かないのですが、みっくみくな曲がかかりまくってました。初音ミク発売後くらいに行ったときは、ソフマップとかでも音楽関連のものはあまり置いてなかったんですが一気にDTM関連の棚が拡大してますね。第二弾のリン・レンの予約も受け付けてました。

さて「CG MAGIC」ですが、これはいい！！先月くらいから勉強していた光や波長について（XYZ CIEとか）詳しく説明されてます。CG WORLDの記事のまとめかと思ってたのですが、もっと詳しくかつ初心者にも分かりやすく解説されてますね。

英語があいかわらずダメな自分としては、ナイス書籍です。Jensen氏のフォトンマップ本（日本語訳のもの、英語のも持ってます）/PBR本（英語）で再度勉強しているのですが、これに加えてCG MAGICも熟読することにします。

フォトンマップとパストレーシング（2007/12/07）

Shadeのフォトンマップにて、先日から試しているシーンを実験してみました。

光の明るさは2000。粗いのは時間がかかるので設定を低めにしているためです。これで、全体的な照度の明るさはMaxwellに近づいたのかも。ということで、カンデラは「2000x2000」（Shadeでの明るさに二乗）で正解？まだちょっとShadeのほうが暗いっすね、、、、。もうちょっと掘ってみよう。

で、思ったのですがShadeは「パストレーシング」のレンダリングでは、単純な視点からのパストレでフォトンは使ってないみたいですね。逆にフォトンマップの場合は直接照明はレイトレで間接照明はフォトンを集めてファイナルギャザリングしてるっていう単純な方法っぽい。

ということで、なぜShadeのパストレはこのようなシーンにて暗いのかというのは理解できそうです（それを想定済みで閉じたシーンにしてるんですけどね(^_^;;）。

単純なパストレは、視点からレイを飛ばして光源にぶつかるか、反射回数の制限を超えるか、ぶつかった面に吸収されるかするまで反射を繰り返します。ところが、この図のように光源になかなかヒットしないと打ち切りが起こってしまい（途中で反射回数を超えるか吸収されてしまう）、直接照明のみの暗いまま（間接照明が届かない）になってしまいます。

では、フォトンマップの場合にこのシーンではうまくいっているように見えるのは

フォトン（光子）を光源からランダムに飛ばしているから、ですね。飛ばされたフォトンは何回かオブジェクトにぶつかって光の明るさが面に染み付いていきます。最終的に視点からレイを飛ばしてその交点部分の光量を回収します。これが「ファイナルギャザリング」と呼ばれる工程です。一般的にはフォトンを直接照明の計算に含めずに、間接照明だけフォトンを使用します。これでもフォトンのモヤモヤが消えないので、パストレと組み合わせて間接照明の２段階目でフォトンを集めるファイナルギャザリングを行ってよりそれっぽく持っていくのが妥協案としてありますね。

でも、まだまだこのシーンでもGIとしては優しいほうです（苦笑）。では、もっと小さな隙間から光が入るようなシーンではどうなるでしょうか？視点からレイを飛ばしても、逆に光からフォトンを飛ばしても、視点からのレイはなかなか室内から出ない、光源からのフォトンは室内に入らない、結果的に真っ暗となります。

ということで、双方向パストレ的な考え方やMLTといった理論に突入するのですが、実は私はそのへんは不勉強です。廃墟をまっとうにレンダリングできれば一人前のレンダラだ、という独自目標があるので、それを目指していきたいですねぇ。いつになるんだろうねぇ(^_^;;。

でも、上記の単純パストレや、フォトンを加えたパストレあたりはすでに実装済みなので（あくまでも実験用）、いずれネタとしては出していくようにします。今度は光の定義を厳密に、できればスペクトルまで入りたいもんです。今月はMaxwell月間ですので、そっちで遊ぶことにします。Maxwellのサイトのマテリアルライブラリにて、ファーみたいな表現がかなりリアルにありますね。すげ〜〜。

http://mxmgallery.maxwellrender.com/

1.6で付いた（らしい）、ディスプレイスメントマップの恩恵なのかなぁ。

光に関して勉強になるサイト（2007/12/07）

いろいろマニアックなサイトがありますね。

Flashlight Fan 懐中電灯/フラッシュライト/LEDライトのファンサイト

http://www.flashlight-fan.com/

ここの豆知識にて「1カンデラ＝４πルーメンのπについて」の記述があります。

http://www.flashlight-fan.com/flame_page/frame_mametisiki.htm

Shadeでの光源の明るさとルーメンの関係（2007/12/07）

間違ってるかもしれませんのであくまでもメモ落書きということで。

Shadeの場合は、点光源・スポットライト・面光源などの「明るさ(intensity)」により光の強さを表現しています。

面光源の場合は、以下のように対応してます（点光源・スポットライトでは異なる）。

この明るさを「i」という変数で表しましょう。また、光源から対象となる位置（レイトレなどでは三角形と交差した交点位置）までの距離を「t」とします。単位はメートルでもミリメートルでも、どちらでもかまいません。

この場合の減衰Aは

のようにあらわすことができます（二次減衰）。光は距離の二乗で減衰していく、というのはこの表現です。デフューズ・スペキュラを求めた後に、この減衰Aをかけることで、光源の影響で減衰したときの色合いが求まります。

これは3DCGプログラムではよく使う数値なんですが、あくまでもレンダラにて使うって感じで、実際は単位があいまいではあります。で、もうひとつの「ルーメン」です。Wikipediaによると「光束の単位」とのこと。

http://www2u.biglobe.ne.jp/~katana/akari.htm

より、「放射束を標準視感度（見え方）によって換算したもの」とあります。フォトンマップ本に詳しく解説はありましたね。ウソ書いてもいけませんので、これはすっ飛ばして「じゃあ、Shadeでの明るさからルーメン変換はどうしているの？」っていう結論から書きます。

lmがルーメンに変換したもの、piは円周率（3.1415926535...）です。上のテーブルの数値を当てはめると、ルーメンの値が一致するかと。ただし面光源の場合のみ。点光源・スポットライトの場合は、求めたルーメンを4倍したものが近いのかな（微妙に差があるのでウソ書いてるかも）。

で、Maxwellはルーメンを放り込めますので、これで同じように光の明るさを指定できそうですね。Maxwellでは、これのほかにワット指定（これはエネルギー量。明るさじゃないです）、lux（ルクス。単位面積（m^2）あたりのルーメン）、cd（カンデラ）、cd/m2（輝度。単位面積(m^2)あたりのカンデラ）、を行うことができます。

単位のあるものに変換できたら、後は相互変換はできそうです。

そもそも誤解ありそうな文でした。

http://www.mskojima.co.jp/web/marinecatalog/onc7-2.html

より、ルクスは「照度」なので照らされたときのものみたいですね。「距離の二乗に反比例」という文章が上記サイトにありますので、カンデラが明るさ（Shadeで言うintensity。Shadeではミリメートル換算なので0.001倍してメートルにする）なのかな？

もうちょっと勉強してみよう・・・かなり自分の理解に誤解ある模様・・・。前にGIレンダラ作ったときはあんまり単位を考えずにやってたからなぁ（忘れてるのもあるし）、いい機会かもしれません。

http://www.pluto.dti.ne.jp/~colombai/lamp/unit.html

にてカンデラからルーメンに変換する記載があるので理解が深まりそう。このサイトを拝見すると、カンデラがLuminous Intensityで、Shadeで言う明るさに近いですね。

光源からの距離を l(m) として、
E = I / (l^2)

の記述があるので、Iがカンデラ・Eがルクス。ということは、Shadeでの明るさ＝カンデラではなくて、カンデラは「Shadeでの明るさの二乗」ってことになるのかも。

Shadeにて面光源の明るさを2000と指定したものを、Maxwellに持っていったときにカンデラ(cd)を2000 x 2000 = 4000000 と入れてみたときのレンダリング画像。

これで先日のWinOSiの画像に近づいたかな。

密封されたシーンにて光が入るとどうなるか（2007/12/06）

画像入れ替え、文章などを一部更新です（2007/12/07）。

いずれは実際のリアル世界にて確認したいですが、密封されたシーンに光が入った場合のレンダリングを行ってみました。光量はそれぞれ似せてますので厳密じゃないです。比較対象としてはあんまりよくないのですが・・・。しかし、ソフトによって光量の定義は違いますね。

天井に光の入る隙間があり、その上から面光源にて光を入れています。カメラの後ろも壁です（直方体の天井の一部だけ空いている状態）。拡散反射色（＝物体の色）は RGB(0.7, 0.7, 0.7)の少し灰色の壁やオブジェクトで構成しています。

Shade

パストレでレンダリングです。ただし、デフォルトのパラメータでは粗いですので以下のように調整入れてます。

レンダリング設定のパストレーシングのパラメータ
   ノイズ現象 0.0
   イラディアンスキャッシュ Off
   キャッシュトレランス 0.0
   反射係数 1.0

視線追跡レベル 20
レイトレーシングの画質 80

WinOSi

emissionを1.0にしました。

Maxwell

カメラは移行できなかったため、アングルが違いますが同じオブジェクトを使ってます。光が弱すぎた・・・。レンダリングやり直してみました。光は10000Wを指定。もうちと、エネルギー単位について勉強しないといけないすね＜自分

比較してみて、間接照明っぷりがなんとなく性格が出ているように思います。Shadeの場合は途中で打ち切られているからか、天井にほとんど光が届いてません。WinOSiの場合はなんとなくそれっぽいけどやっぱり青い(^_^;;。Maxwellはその中間くらいですかね。

WinOSiとMaxwellの上記シーンにて、球に水平方向の境目がうっすらと出ているのが興味深いです。ポリゴンメッシュのスムージングでカバーしきれてないのかな（両方ともに法線がスムージングするようにしています）。Shadeの場合は球なので滑らかではあります。

でも、光の挙動は実際にこのようなシーンをリアルに構築してみないと本当かどうか分からないですね。

ちなみに上記シーンのレンダリング時間は、Shade 24分、WinOSi 4時間強、Maxwell 17分、です。Shadeではより品質高く出そうとすると時間がかかり、Maxwellは遅いと言われてますが言うほど遅くはないと思ったりもしました。

しかし、WinOSiはなんで空気感が出てるように感じるんだろう？上記のような単純なシーンでも、WinOSiのほうがリアルに感じます。若干青っぽくなるからかスペクトル入ってるからなのかなぁ？Maxwellは少しは調整しないとCGくささが出るような気もするので（カメラ専門のパラメータが多くて素人にはちょっと敷居が高いっす）、、、、やっぱりどれがよりフォトリアルなのか分かんないです(^_^;;。

続・Maxwell（2007/12/02）

先月テストしたものと同じシーンをMaxwellにて。Celeron 1GHz/Mem512MBのノートPCにて、一時間でレンダリング。

WinOSiで12時間以上かかったシーンが1時間以内（実際は40分くらいでもうノイズはほとんどなくなってました）で、速いっすね。WinOSiっぽさを出そうとすると、とりあえず白を強くしたら近づきそう。

これはますますほしくなったなぁ。MaxwellStudioで形状放り込んで配置、マテリアルを割り当てる、カメラの調整、その後レンダリング。これでデモ版でも（ウォーターマークとレンダリングサイズ制限はあるけど）製品とほぼ同じことができるので、別段プラグインとかはなくてもしばらくは遊べそうです。

ちなみにShadeからはobj形式で出すとUVもついてくるので（Vは上下逆転させておくこと）、Maxwellでも割と楽に読み込めます。ただし、マテリアルはセコセコとMaxwellStudioで指定しないといけませんが。カメラもMaxwellStudioで作成できます。後、当たり前ですが日本語の形状名などは化けますので英語で。

Maxwell（2007/12/01）

先月はWinOSiでしたが今月はMaxwellです。Maxwell体験版の1.6が出ていたため、テスト。

Shadeで作ったシーンをobjで出力し、これをMaxwellStudioに食わせました（dxfだとMaxwellで保存できなかった）。マテリアルはやっぱり移行できなかったので、MaxwellStudioで指定していきました。

同じシーンをレンダリングしたらMaxwellではどうなるかな？emissionに関してはMaxwellでは思い通り（複数光源を配置しても暗くなることはない）ですねぇ。やっぱりWinOSiでは複数光源の場合に不正になるのですかね。Maxwellのレンダリングは初ですので、少しレンダリングして性能を見てみよう。

Maxwellでは、光源はオブジェクトの発光（emitter）として割り当てるんですね。点光源や平行光源などのパラメータはないようでした。マテリアルのパラメータが多いので、マテリアルのライブラリが必要なのは納得です。質感が同じになるかなぁ、レンダリング中のを見ていますが、ぜんぜん違う色合いになりそう。

レンダリング結果。2時間です（Celeron 1GHz/Mem 512MB）。

WinOSiよりも速いですねぇ。WinOSiの場合は、光により白くとんだ感じになる（光沢の影響じゃないやつ）のが本物っぽさを出しているのだろうか、Maxwellのこのシーンの場合はCGくささが出てしまってます（もちろん、私の調整がなってないからですが(^_^;;）。指定した表面色がほぼそのまま表現されていますね。Maxwellでの光沢の表現はまだ理解してないので、それを入れるともう少しリアリティが出るかな。何がリアルさというものを出しているのだろうか、というのはWinOSi/Maxwellをいじってみて、ヒントは掴めないかなぁと。今のところ、マテリアルをいじらない状態での本物っぽさはWinOSiのほうがいいような。

光源は、窓から２つ、手前の廊下から１つのエリアライト（面へのemitter割り当て）です。もちろん、調整すれば本物っぽさは出るとは思います。ということで、このシーンはまたリベンジせねば。

後、PhysicalSkyにて国と時間を指定することでそのときの太陽の影響を表現が出来るのがナイス。いろいろ遊べそうです。GMT指定しないと、JAPANの昼ごろを指定したのですが真っ暗になってしまいました。日本の場合は、GMTは+09:00:00っすね。ほか、光の回り込みと透過・反射の挙動など確認せねば。