独り言日記（2010/12）

独り言日記

帰省中（2010/12/30）

新幹線は満員でした。年末から元旦は雪との予報なので、年末年始はやっぱりプログラムで年越ししそうです、、、。そういえば、行きしなに秋葉原付近でゲームっぽい紙袋を持った方々が乗ってきてました。この時期、コミケでしたね。こちらはほとぼりが冷めたころに秋葉原で同人ゲームやCDなど見に行ったりしてる程度ではあります。いずれはコミケ御本家を見に行ってみたいけど、いつもニュースでの人数みてしり込みしてしまいます(^_^;;。大阪時代は関西で行われていたのに見に行ったことがありますが、その際でも結構待ち行列があったからなぁ。

で、少し面白いプログラム実験をやってまして、また何かの機会に披露できるかなと。とりあえず、以前続けてたray_intersectionの説明はまだ途中ですので再開するのが年初めのネタになるかな。

覚えきらないことは書いてみる（2010/12/29）

某デバッグ中。とりあえず、なんだか深い部分を掘らないといけないのもあり、あれもこれも、、、と課題がいろいろと(^_^;;。

試行錯誤するのに、私の場合はとにかく書き出すようにしています。その間はプログラムは手を休めて理論をまとめたりしてます。自分の机がホームポジションではあるので、PCの場合だとWikiに書いたり、一応ホワイトボードがあるのでそれで書きながら悩んでみたり。毎日、1日での小さいマイルストーンを設けて、自分のやったことのログは蓄えるようにしてます。

しかし、数学（といっても高校数学レベル）が絡むとややこしいですね。また、たいていは一度寝るとすんなりまとまることもあるので睡眠も大事。集中が続かなければいくら粘っても無駄な時間をすごしてしまいますので、あきらめて休むもしくは寝る。集中するときはとことんで、できれば時間など制限せずに。が、私のスタイルとして合ってるのかなぁと。

で、ここの日記は息抜きです（苦笑）。

ところで、私の場合はよく文末に「(^_^;;」「（笑）」とかをつけるのですが、人によっては「w」のほうが「（笑）」よりもやわらかい表現と感じるようで。「（笑）」たど嘲笑っぽく感じるんだと。これも時代の流れなのかねぇ。もちろん、仕事では顔文字などは一切使いませんが(^_^;;

私は極力「w」を使わないようにしているのですが（この日記では一切使ってないはず、一応ポリシーです）、他の方のツイッターとか見ると結構使ってるのを見るんですよね。

まぁ、私は頑固にWikiで日記というスタイルですのでこのまま貫きますわ。あえて、流れについていかないのもいいかもしれない（負け惜しみ）。日記は、自分の「文章を書く」ということの練習でもあるのですが、顔文字とかは個人的には表現の逃げなのかな、という後ろめたい気持ちもあります。本当は、そんなのを使わずに感情などを表現すべきなのですが、、、・まだまだ文章については勉強せねば。

でも、日記を書く人と書かない人では圧倒的に文章力というか表現力が違うようになるのかなと思ったりしてます。かれこれ10年以上日記を書いていて（気づいたら学生からずっと）おかげさまで続いてますが、人に伝えようという訓練にはなるかと。

続・GIレンダリング検証 Shade 12.0.1（2010/12/26）

引き続き、「レイトレ＋パストレ」と「パストレ＋パストレ」の速度と品質についてですが、仮に同一のノイズの散らばり具合にそろえることができたとすると「レイトレ＋パストレ」のほうがレンダリング速度はトータルで速いかもしれないです。

まだ推測の域なので検証で確認できてから書きますが、レンダリングの仕組みを知った上で改めて調整すると見えてくるものがありそうではあります。このへん、内部的には整合性取れてるのでしょうけど、どっちといえばパラメータとかユーザインターフェースとかが技術者寄り（生データをいじるような）になってるのかなぁと。GIレンダラはほかでもそういうのが多いですが、、、知識なくてもそれなりの絵は作ることができる、は幻想なのかなぁ。難しいところではありますね。

ところで、Maxwellレンダラ2も試してるのですが、、、なんだかすぐ落ちる(^_^;;。3Dソフトはそんなのばっかりか〜〜(^_^;;後、なにげにタブレット操作に対応してないソフトも多かったりしますね。ShadeはOKだったのですが、CINEMA4D（体験版）とかメタセコもちょっと不都合があったりします。CINEMA4Dの場合はタブレットではトップメニューが選択できない、メタセコの場合は右上のズームやパンをタブレットでドラッグしながらだとクリックした際に動きが変、というのを発見してます。メタセコの操作は私の場合はほとんどショートカットで行ってるため問題ないのですけども。

かれこれマウスを使わないようになって数年、すっかりタブレットがないと操作に戸惑ってしまうようになりました。3ボタンマウス/ホイールスクロール、なにそれ？です(^_^;;。おかげで一部のソフトが使いづらいこと(Mayaだとタブレットだけでは難しいでしょうね)。

私の会った人のなかでタブレット+キーボードで全部操作する人は今までいなかったりするのでおそらく少数派だと思いますが、意外とオペレーションには向いてると思ったりしてます、慣れかもしれませんが。

GIレンダリング検証 Shade 12.0.1（2010/12/25）

今月は画像が多くなってしまって、ページが重い、、、。

ray_intersection解説はちょっと待ってね。早速ですが、Shadeのレンダリング設定を指定する箇所は「手法」と「大域照明」の選択と大きく2種類があります。これを検証してみました。

結論から言って、私としては「パストレ＋パストレ」をお勧め。

前回レンダリングしたシーンを時間がかかるので、

パストレーシングのイラディアンスキャッシュ  Off
視線追跡レベル          100
レイトレーシングの画質  500
ガンマ値                1.0
光源は背景HDRのみ

でレンダリングしました。露出調整とガンマはHDRViewにて調整してます。露出+3、ガンマ 2.2です。

↓レイトレーシング + パストレーシング（レンダリング時間 3時間35分40秒）

↓パストレーシング + パストレーシング（レンダリング時間 47分29秒）

ノイズに関しては、レイトレ＋パストレのほうが細かく見えるのですが単にサンプリング数が上がってるだけ？また、レンダリング時間が大幅増加してます。

パストレ＋パストレの場合は、それなりか。以前の計測時は画質1500だったので、12/11での推測計算時間に当てはめて比較すると、レンダリング時間は12.0.0から12.0.1では速度アップしていると想像できます。

後、品質ですが、レイトレ＋パストレの場合でアンチエイリアスの画質を自動にしている場合は、細かい部分にてアンチエイリアスが汚くなってしまってます。

アンチエイリアス 4x4で細かい部分の精度は改善できました。

実際は、単純なシーンじゃなくてもっと細かい形状なり面が多いシーンで作品作りには利用すると思われますので、そのへん意識しないで済むパストレ＋パストレのほうが個人的にはいいかなと。野外シーンだと違うのかもしれない。また、アップデータによっては差が出てしまうのかもしれませんので、上記はShade 12.0.1の私の試したシーンではこうだった、と受け取っていただければ。

追記

なんとなくですが、「レイトレーシングの画質」の意味合いが、レイトレ＋パストレと、パストレ＋パストレ、にて異なるような気もしてます。パストレ＋パストレはアンチエイリアス的なオーバーサンプリングをしない代わりに、画質で代用しているとか。

パストレのレンダリングの場合は、一般的には（Shadeに限らず）1ピクセル内で細かくランダムにレイを飛ばしそれらの反射計算・輝度計算を行います。それがn回繰り返され、それを平均することで1ピクセルでの色（輝度）が求まるわけです。

このnをサンプリング数として与えるのが多いです。4x4アンチエイリアスだと16サンプリングと同じ意味合いです（もちろん、最適化での はしょり方やサンプリングの指針の違いによってはソフトにより差はあるかと思います）。ただ、1ピクセル内のサンプリングがランダムだと汚いので 層化サンプリングやQMCなどの理論が出てくるわけです。これらは大雑把過ぎる表現で言うと、ランダムなんですが一部規則を持たせることで、ノイズが見えにくくなるというもの。ここでのノイズは、スクリーンの各ピクセル間でのノイズね。GIレンダリング時のよくある高周波ノイズ/低周波ノイズとは別です（こっちになると重点的サンプリングとかMLTとか、そっちです。ややこしいですね(^_^;;）。

Shadeの場合は、アンチエイリアスが生きたままサンプリング数相当の画質というパラメータがあるので、レイトレ＋パストレの場合はとたんに概念が難しくなりそうではあります。ちなみに、パストレ＋パストレの場合は、アンチエイリアス指定は無効になります。このほうが自然だと思う。

レイトレ＋パストレでのアンチエイリアス検証

「レイトレーシングの画質」を変えずに、レイトレ＋パストレでのアンチエイリアシングの選択のみを変えた場合の速度とノイズ減少比較。上記画像のシーンにて、部分レンダリングで検証です。

アンチ自動適応 :  72 秒
アンチ 4x4     : 729 秒

となることから、どうも視点からの1レイを飛ばしたときの計算は個々に「レイトレーシングの画質」でのサンプリング数で処理するのかも。これだと、アンチエイリアシングのはしょり方によってレンダリング時間が変わりそう（要はレンダリング時間の推測がしにくい）。

また、アンチ4x4だと実質は「画質 x 16」相当の品質（レンダリング時間も同じくかかる）になる予感。つまりは、アンチエイリアスの指定によってサンプリング数が大きく変わってしまう結果となるのかもしれません。う〜ん、レンダリング時間と品質見積もりがレイトレ＋パストレだと難しいかも。

個人的には、ノイズの散らばり具合はどのアンチエイリアス指定であっても、レイトレ＋パストレ/パストレ+パストレでも変わらずに、1レイでのサンプリング数を割り算で与えてほしいかなぁと思ったりも。そうすると、レンダリング時間とノイズは、どのレンダリング画像を見てもほぼ同じになると思われるので検証しやすいのですが、、。

Shade 12.0.1 アップデータ（2010/12/24）

Shade 12.0.1アップデータが公開されてます。変更点は以下。

http://shade.e-frontier.co.jp/12/download/1201fixed.html

恒例の初期ロットてんこ盛り不都合がいろいろ直ってますので、Shade12をお持ちの方はぜひバージョンアップを。ここの日記で話題にしていた、パストレーシングレンダリングのガンマ問題も修正されています。速度面/メモリ面も改善されてるようですので、またGIレンダリングは検証せねば。

後、私は立体視が青赤メガネであまりよく浮き出て見えなかったのですが、どうも視差がでかすぎると自分の目にはマッチしないようではあります。わずかにずれている感じだと立体的に見ることができました。GIのシーンではどうなんでしょうね。

そういえば、最近裸眼立体視のTVが出たとのニュース記事がありました。どのメーカーだったか忘れた、、、。スマートフォンでも裸眼立体視のが出始めてるようで。こっちの技術も期待ですねぇ。店頭で見ることができるのかな、また見にいこう。

任天堂の3DSが来年の2/26予定みたいですので、私が手に入れるとするとまずはこれかなぁ。

http://www.nintendo.co.jp/n10/conference2010/3ds/index.html

パルテナの鏡はなつかしい。昔ディスクシステムのをクリアしましたが、自分で言うのもなんですがよくクリアしたなぁと(^_^;;。でも、攻略本見てたなたしか(汗）。

続・ray_intersection（2010/12/24）

ray_intersectionを使用するには常駐プラグインである必要があります。グローバル関数にて

extern "C" bool STDCALL is_resident (const IID &iid, int i, void *) {
   return true;
}

のようにtrueを返すのが必須になります。

ray_intersetionの割り当てはshape_classを介して行うのですが、これは以下のようにして対象の形状のstreamに教え込むことで ray_intersectionの処理を有効にできるようになります。

R-Billboardプラグインのソースで言えば「StreamCtrl.cpp」のWriteAttribute関数にて。

割り当てを行いたい形状をpShapeとした場合、

compointer<stream_interface> stream(pShape->create_attribute_stream_interface_with_uuid(
    BILLBOARD_ATTRIBUTE_ID,  // 属性用
    sx::uuid_class(0),      // ワイヤーフレーム用
    ray_intersection_uuid,  // ray_intersection用
    sx::uuid_class(0)));    // rendering object用

として、第三引数の「ray_intersection_uuid」にて、attribute_interface派生クラスでのget_uuid関数で返しているUUIDと同じものを指定します。

ここでは、図形ウィンドウにて独自ワイヤーフレームを描画したい場合は第二引数に対象UUIDを入れる。第三引数はray_intersectionキック用、第四引数はレンダリングオブジェクト用、のようになってます。レンダリングオブジェクトに関してはまた後々解説予定。ここを「sx::uuid_class(0)」とするとそれぞれの機能は無効化されます。

create_attribute_stream_interface_with_uuidの第三引数を明示的に指定すれば、ray_intersectionは認識するとだけ覚えていただければ。streamの中身はなんでもいいです。記述しなくてもおそらくいけるはず。

では、次にattribute_interface派生クラスでのオーバライド関数について。R-BillboardプラグインのBillboardAttributeInterface.hが対象箇所です。

説明に必要な部分だけ抜き出してます。

class CBillboardAttributeInterface : public attribute_interface
{
private:
   ...
   
   virtual int get_shade_version () const { return SHADE_BUILD_NUMBER; }
   
   // ここでstreamの第三引数で記載したUUIDを返す
   virtual sx::uuid_class get_uuid (void * = 0) { return BILLBOARD_ATTRIBUTE_ID; }

   ...

   //--------------------------------------------------//
   //  ray_intersection用                              //
   //--------------------------------------------------//
   /**
    * 一本のレイと交差する可能性のある点の最大数を返す
    * @param[in] shape   対象となる形状クラス
    * @param[in] i       要素番号（get_number_of_elementsで設定した値 - 1まで）
    * @return 一本のレイでの交差点の数
    */
   virtual int get_max_intersections (shape_class &shape, int i, void *);

   /**
    * 融合する可能性のある形状の最大数を返す
    * @param[in] shape   対象となる形状クラス
    * @param[in] i       要素番号（get_number_of_elementsで設定した値 - 1まで）
    * @return 融合する可能性のある形状の最大数
    */
   virtual int get_max_shapes (shape_class &shape, int i, void *);

   /**
    * 交点計算に必要な独自の情報を生成
    * @param[in] shape   対象となる形状クラス
    * @param[in] lw      shapeでのローカルからワールド座標への変換行列
    * @param[in] wl      shapeでのワールドからローカル座標への変換行列
    * @param[in] i       要素番号（get_number_of_elementsで設定した値 - 1まで）
    * @return 形状のカスタム情報のポインタを返す
    */
   virtual custom_element_info_base_class *new_custom_element_info (shape_class &shape,
      const mat4 &lw, const mat4 &wl, int i);

   /**
    * スレッド単位で交点計算に必要な独自の情報を生成
    * @param[in] shape   対象となる形状クラス
    * @param[in] i       要素番号（get_number_of_elementsで設定した値 - 1まで）
    * @param[in] j       スレッド番号
    * @return スレッド単位での交点計算に必要な独自の情報を格納したクラスのポインタを返す
    */
   virtual custom_element_info_base_class *new_per_thread_info (shape_class &shape, int i, int j);

   /**
    * バウンディングボックスを返す
    * @param[in] info           new_custom_element_infoで生成したカスタム情報
    * @param[in] shape          対象と???る形状クラス
    * @param[in] lw             shapeでのローカルからワールド座標への変換行列
    * @param[in] wl             shapeでのワールドからローカル座標への変換行列
    * @param[in] i              要素番号（get_number_of_elementsで設定した値 - 1まで）
    * @return ワールド座標でのバウンディングボックスを返す
    */
   virtual box3_class get_bounding_box (const custom_element_info_base_class *info,
     shape_class &shape, const mat4 &lw, const mat4 &wl, int i, void *);

   /**
    * 交点計算を行うときに呼ばれる
    * @param[in] info              new_custom_element_infoで生成したカスタム情報
    * @param[in] shape             対象となる形状クラス
    * @param[in] lw                shapeでのローカルからワールド座標への変換行列
    * @param[in] wl                shapeでのワールドからローカル座標への変換行列
    * @param[in] i                 要素番号（get_number_of_elementsで設定した値 - 1まで）
    * @param[in] o                 レイの始点位置
    * @param[in] d                 レイの方向ベクトル（正規化済み）
    * @param[out] intersections    交点情報を返す
    * @param[out] per_thread_info  スレッド情報
    * @return 交点の数
    */
   virtual int ray_intersection (const custom_element_info_base_class *info, shape_class &shape, 
           const mat4 &lw, const mat4 &wl, int i,
           const vec3 &o, const vec3 &d, intersection_class intersections[],
           custom_element_info_base_class *per_thread_info, void *);

   /**
    * ray_intersectionがスレッドセーフである場合はtrueを返す
    */
   virtual bool thread_safe (void *aux=0) { return true; }

attribute_interfaceは形状に対するカスタム属性を割り当てるためのインターフェースで、このクラスからray_intersectionの情報をやりとりすることになります。get_uuid関数で返しているのが識別UUIDになります。属性やray_intersectionキックのためにstreamなどで渡すことで使用します。

virtual関数として以下のものがあり、これらはレンダリングの際にShadeから呼ばれます。頻繁に呼ばれる部分ですので、速度面を意識した実装が必要となります。

get_max_intersections

一本のレイと交差する可能性のある点の最大数を返します。たとえば球と交差する場合はIn/Outの2つが交差点数の最大になります。今回みたいなビルボードの場合は板と交差するのは必ず1つなので、1を返してます。

get_max_shapes

融合する可能性のある形状の最大数を返します。

融合に関しては今回は使用しないのでスルー（というか、使い方がうろ覚えですので（汗）交差がある場合は1を返す、としてください。

new_custom_element_info

交点計算に必要な独自の情報をnewして返します。R-BillboardではCRayIntersectionInfoというクラスに情報をまとめるようにして、これを返しています。今回は未使用な情報ではあるのですが、これを指定しないと不安定になるのでダミーで入れてます。

new_per_thread_info

スレッド単位で交点計算に必要な独自の情報をnewして返します。スレッド数分この関数が呼ばれます。R-BillboardではCRayIntersectionThreadInfoというクラスに情報をまとめるようにして、これを返しています。ビルボードと交差した位置での色はshader_interfaceをかます必要がありますので、ここのスレッド用の情報を経由してやりとりすることになります。

get_bounding_box

対象のshapeを中心としたバウンディングボックス情報を返します。ここで指定したバウンディングボックスとレイが交差した場合に、独自のレイシューティング（ray_intersection処理）に突入となります。

ray_intersection

交点計算を行うときにその都度呼ばれます。ここでは、レイの開始位置とレイの向きや対象スレッド情報などが引数にて渡ってきますので、それを元に独自のトラバース＋交差判定を行った結果を返すことになります。

thread_safe

ray_intersectionでの処理がスレッドセーフである場合はtrueを返します。trueを返すと、スレッドを意識して記述する必要がありますが（new_per_thread_info関数で返したスレッド情報が個々に独立しているのを保障する必要がある）、速度的に結構速くなります。ですので、ここは極力trueとなるようなソースを心がけましょう。

長い説明になりそうなので少し一休み。次は、実際のコード部とその概念をもうちょっと分かりやすく説明予定です。文章だけだと分かりにくいですね(^_^;;

ray_intersection（2010/12/23）

「RBillboard」プラグインにて使用していたray_intersectionについて。これは、Shadeのシーンにおいてレンダリング時に独自に作成した「何か」を配置できる機能になります。「何か」というのはブラックボックスでよくて、それをプラグインで提供できる仕組みになってます。レンダラ的に言うと、レイトレーシングのトラバース処理にて独自の交差判定を紛れ込ませることができます。そのため、パストレーシングでも使用可能です。ただし、ワイヤーフレームやトゥーンレンダラでは使用できません。

これは、結構実装自身は複雑化しますので入念に解説します。

ray_intersection内部特徴

• レンダリング時にて独自の交差判定を紛れ込ませることができる
• 交差位置の情報として、レイの開始点から交点までの距離・位置・法線・色（これはshader_interface経由）を与えることができる
• 元の形状との融合処理
• スレッドセーフ実装により、マルチコア環境でも最適化できる

ray_intersectionの概要

のようなシーンがあったとして、ここに以下のようなバウンディングボックスで囲まれた領域を設けます。

赤い直方体がray_intersectionで自由にできる範囲です。ここに、レンダリング対象の他の形状が入りこんでいていても問題なしです。ray_intersectionでのレイからの交差距離と、Shade本体でのレイから見て一番近い交差距離とで比較して、距離が近いほうがレイシューティングの最終的な交点候補として採用されます。

では、そのray_intersectionの交差のみで見てみると、、、

のように、レイの開始点からレイの方向に向けて直線を飛ばし、バウンディングボックスとの交差がIn/Outで存在することになります。このIn〜Out内にて独自形状の交差計算をすればよいわけです。交差位置で返す情報は

• レイからの距離
• 交差位置（ワールド座標）
• 交差位置での法線

です。色などの材質情報はスレッドをかませてshader_interfaceで与えることになります。これらはまた後で説明します。

ここで注意点。ray_intersectionは「形状（shape_class）に対して1つ割り当てる」という仕様になっています。ダミーでも何か形状が必要です。それに属性を与えてattribute_interface派生クラスのコールバック関数から制御することになります。

説明が前後してしまってますが、ray_intersectionを行うにあたってShade本体に教えなければならない情報は以下のようになります。

• 対象のshape_class
• 判定に使用するバウンディングボックス（XYZ軸に沿ったAABBである必要があります）
• 1本のレイが交差する際の最大の交点数
• スレッドの保護をスキップするかどうか（スキップすると独自でスレッド管理が必要になるが速度に貢献）

ということで概要の説明でした。ここで一区切りします、続きは次回。

Shade12での自作プラグイン動作（2010/12/23）

自作プラグインの「太陽光計算」が、Shade12に持って行くとレンダリングする際にクラッシュするようです。無限遠光源の向きをレンダリング時に変更するのがトリガーになってるみたいです。

お手数をおかけしますが、しばらくお待ちくださいませ。回避策を模索してみます。トリッキーなことをしていたのですが、そういうのは危険ではありますねぇ。そういえば、Shade12では「平行光源」が追加されてました。無限遠光源は発生位置を持たない方向だけのものですが、平行光源は位置や半径を持っています。また、オブジェクト化されているのでこっちを使うようにということでしょうかね。

The Tower for iPad（2010/12/22）

ビルをひたすら高くしていくシミュレーションゲーム「The Tower」のiPad版を発見したので購入。

シミュレーションがあまり好きではなかったのですが、これは好きだったなぁ。えらいはまった記憶があります。iPad版でも色あせてませんね、うん、楽しめます。経営シミュレーションでもあるので、社会人になったほうがより面白さが分かるというか。

これって、エレベータのアルゴリズムが結構凝ったゲームでしたね。また、エレベータって単純なようで実はすごいんだ、というのを気づかせてくれたゲームでもあります。昔テレビでそれについて開発者が語ってたような。開発者の方は、Wikipediaを読むと日本のMac界の草分け的な方なんですね。

Shadeでのガンマ補正（2010/12/22）

CASPAR003さんのところのブログを読むと、どうもShadeの場合はパストレ＋パストレが問題があり、レイトレ＋パストレだとうまくいってるらしいです。

http://www.caspar003.info/delta/archive/2010/12/20/0011

また、レイトレ＋パストレのほうが速くなるとのこと。これは盲点になってるなぁと。普通にGIやるとすると、まずパストレースにして大域照明というタブも同じパストレースにしてしまえ、心理しかない私みたいなのは気づかないというか。固定概念が邪魔してたわけか。

いずれにせよ、ガンマ補正をうまくやるとGI好きにはきれいな絵が出せるということでノウハウとして覚えておいて損はないですね。でも、露出調整を考えるとやっぱりガンマ1.0でHDRで保存して、となりそう(^_^;;

電子書籍端末（2010/12/22）

先週に秋葉原に行ったときに電子書籍端末の棚があったので、いろいろ触ってきまして。ガラパゴスとreader、どんなもんかと思っていじくってました。ガラパゴスはiPadよりも小さいサイズのがありました。持ち運びは便利そう。Readerは白黒のみでしたが、眼には優しい感じ。iPadやガラパゴスは液晶が眩しいですからねぇ。これも小型で軽かったです。

個人的には端末が何であれ、電子書籍が流行ってくれるとなんかうれしいなぁと。その手の回し者でもなんでもないのですが、今度こそは来る予感がしてます。

そういえば、電車で電子書籍、はまだあまり見ないのですが、ゲームしてるのはしょっちゅう見るようになりましたねぇ。最近はモンハンしてるのをよく見ます。と、私よりもはるかに年上の方もゲームしてたりして、いつ卒業するんだ、と思ったり。人のこと言えないですがf^_^;)。噂でしかないのですが、ゲーム会社がバイト使って携帯ゲームを持って電車で流行ってるように演出、というのがもし本当だとすると、戦略的にも成功したと言えるのかな。電子書籍もそうするのもありかもですね。今は自分自身、電車では恥ずかしいですし(^_^;

後、日記に書くと言ってたShadeプラグインSDKのray_intersectionの解説そろそろ始めようかと。

ベーマガ世代（2010/12/19）

電子書籍としてのゲーム製作雑誌「がまぐ！」というのが創刊されたという記事。

http://gamez.itmedia.co.jp/games/articles/1012/15/news111.html

私もまっさきにベーマガを思い出して、つい懐かしくて検索してみました。

ベーマガとは「マイコンBASICマガジン」（電波新聞社が出版）という、今から10年よりもはるか前に存在していたプログラム投稿や技術系記事などを掲載していた雑誌です。調べると1982年創刊とのこと。で、2003年に休刊。

以下に、影響を受けた方のインタビューとか。

http://rikunabi-next.yahoo.co.jp/tech/docs/ct_s03600.jsp?p=000882

私もばっちりこの世代で、もちろん影響受けた人間の1人でもあります。私は別雑誌ではありますが、学生時代にI/Oという雑誌のほうに投稿したりしてました。何回か載ってるよ。その当時に活躍されていた投稿者は、今も多方面で活躍されてますね。ニコニコの中の人とか、某P2Pの人とか（たしか投稿記事があったと思う）。で、おそらくゲーム業界でも多数ベーマガ世代やI/O世代の方がおられるかと。

今はプログラム雑誌ってないに等しいです。OSが進化して複雑化してしまったので覚える知識が多くなって雑誌ではなかなか伝えきれない、というのもあるかもしれませんが、私が思うにネットが進化して情報がインターネットという形で公開できるようになったため、必要性が薄くなったのかなと思ったりもしてます。

しかし、今の時代にプログラムをこれから始める方って、どのような手段で興味を持つようになるのでしょうね。BASICなのに16進数命令をPEEK/POKEする、6809のYAMAUCHIコマンドとか、今はさすがに使うことはないですが(^_^;;、全部雑誌から情報を仕入れたりで、だけど当時は新鮮で、昔からプログラムをしていた身としてはそういう知識への興味がプログラマを目指すきっかけにはなってたのかもしれません（純粋にそれが楽しかった）。が、今は何がきっかけになりうるのかなぁ。

今は、インターネットでの情報のほうがはるかにいろいろ知識は詰まってるでしょうけど、「情報を探す」からはじめないといけないので大変なのかも。とらえ方の問題かと思いますが、遊びとしてのプログラムは昔から変わらずずっと楽しいものであるという視点を持ってほしいかなと（できれば仕事などとは別ものとして考えてほしい）。私のほうもそんな情報をちょくちょく出していければと思ってます。

しかし、「がまぐ！」のPDFを見るとツボを分かってらっしゃる（笑）。ただ、紙面でも書かれてましたが、3Dバリバリのゲームが当たり前な世代が果たして興味を持つきっかけになりうるか、難しいところではありそうですね。根っこは同じはずですが、段階を踏むのであれば 3Dの知識理解はもっともっと後になるのかも。

そういや、私が聖典にしてた「こんにちはマイコン」がeBookJapanで販売されてました。

http://www.ebookjapan.jp/ebj/book/60027697.html

これ、スカッシュが最終課題ですので当時はかなり勉強に役立ちましたねぇ（小学生時代っす）。今、漫画のプログラム本ってあったっけ？昔はこの他にPOPCOMとかの漫画のプログラミング本がありましたね。

畳のサイズ（2010/12/19）

1畳は910mm×1920mmとして覚えていたのですが、いざ計測してみると差がありますね。Wikipedia様様ですが、いろいろ種類が（以前からよく拝見してたページなんですが、あんまり気にしてなかった(^_^;;）。

http://ja.wikipedia.org/wiki/%E7%95%B3

私の住家は賃貸なので、団地間の850mm×1700mmで測ってみるとこれと一致。6畳でも関西の一軒屋の和室とは微妙に差があるのか〜〜、といまさら気づく（汗）。昔の関東の旧家の場合は江戸間で880mm×1760mmになるとのこと。

京間（関西間）が955mm×1910mmとのことなので、6畳部屋だと

になりますね。団地だと関西の一軒屋と比べると42cm x 31.5cmもコンパクトなのか、、。結構差が出るね。

では、廊下はどうなるのだろう。1畳の小さい幅（江戸間だと880mm？）ほどだと認識してたのですが、また計りにいくか、、、。

旧家でのお勉強（2010/12/18）

先週行った資料館に再びお邪魔させていただいて、管理人さんの許可をいただいて室内を拝見させていただきました。明治20年の建物です。

見ることができた部分だけでマッピングすると以下な感じかなぁ。頭に記憶してから 後でShadeドリームハウスで配置したのですが、、、うろ覚えだ(^_^;;物置がないはずはないので、たぶん見落としがありそう。トイレの位置もたぶんここじゃない(^_^;;

ShadeドリームハウスのiPad版を作ってくれないかなぁ（ぼそっと）。現場でこういう配置ってのをメモるには、なんだか向いてるような気がしたりもします。3DCGじゃなくていいので、上面図の配置（設計図）だけでもできるとありがたいかも。実は上の配置図を構成するのは3分もかかってません。ぱぱっと、マウスドラッグで部屋やら廊下やらを配置しただけ。細かい作業はいらないので規格におさまった建物だとモバイル系には向いてそうな気が。

で、玄関入ってすぐのところに書庫があったのですが、山積みの本はなかなか。埃まみれではあったのですが、またそれがいい味出してました。「秩父事件」と書かれた書物が多かったです。埼玉の旧家で明治20年の建物ですのでその時代と、明治17年におきた秩父事件は年代としても一致。ググってみると、増税やデフレにて農家の生活が苦しくなり武装蜂起して政府に反乱した事件、だそうです。

後は、建物としての柱の組み方や窓部分の作り方/天井、などをじっくり見てきました。せっかく3D化するので、知識を身につけた上でモデリングしないとね。といっても、そのまま再現するわけじゃなくて参考にさせていただいて、自分の思う昔の家の空気感を表現したい、ってだけではありますが(^_^;;。屋根裏部屋に上る階段があったのですが、そこは閉鎖されてました。忍者屋敷（？）みたいな収納できる階段でしたねぇ。

で、やっぱりお客さんは誰もおらず貸切状態。床の間のある部屋にて座ってみると、なんだかトリップできますねぇ。夕方くらいに縁側から日が差し込む感じがたまらなく趣を感じます。今度は巻尺を持って寸法など計りにいこうかな。「静」な空気を味わいたい方は、そういう家に立ち寄ってみたら落ち着きますよ。

あっと、床の間について。6畳の部屋の場合は、プラスで床の間部分の面積が増えるのか（つまり8畳の部屋になる）、6畳のうちマイナスで床の間部分の面積を占有するのか調べるのを忘れた。また見てこよう。

続・iVOCALOID VY1（2010/12/18）

制限のある中でこそ燃えるものがあるっ！ということで、引き続きiVOCALOID VY1。というよりも、先日夜中布団の中でいじってました。

音長の最小が8分音符の制限を突破

2小節を1小節に見立てて入力してみる。これだと16分音符相当も表現できました。ただし、テンポをx2倍する必要あり。32分音符が必要な場合は、4小節を1小節に見立ててテンポx4倍ですね。

でも、最大17小節なんで窮屈かも。

音域の制限を突破

これは、AppStoreのコメントに書かれていた方法。iVOCALOID VY1はC3-F4までですが、ピッチベンドで-1〜+1オクターブまで調整できるので無理やり調整すると、C2-F5まで可能に。でも、調整が数値指定じゃないので絶対音感的に調整しないと苦しい（汗）

VOCALOIDエンジンとしては表現はできるんだけど、おそらくアプリとしてのUIなどで制約されてしまってるんだろうなぁと。後、指操作独特のめんどくささがあったりするのはiPad/iPhoneアプリの課題かもしれませんね。範囲選択がしたい(^_^;;

iVOCALOID VY1（2010/12/17）

iPad用のYAMAHAのiVOCALOID VY1のアプリを購入してみました。

http://www.vocaloid.com/iVOCALOID.html

指定できる音域は1オクターブちょっと（C3-F4）。8分音符が最小の長さ。調整は、ダイナミクスとビブラートとピッチベンドのみ。で、17小節までの入力なので PC版よりもかなり簡易的なVOCALOIDって感じですね。寝ながらいじる分にはちょうどよいくらいではありますが、ちょっと物足りないかな。もう少し音域が広ければよかったのですが、、、。

VSQファイルはメール経由で保存できるようになってました。ですので、iPadで思い浮かんだメロディーをとりあえず貯めておいてPC版のVOCALOIDで編集って使い方がよいですかね。

後、本日仕事帰りに秋葉原寄ってきたのですが、いつの間にか知らないVOCALOIDシリーズが増えてました。なんか、ガチャピンのが宣伝されてたぞ(^_^;;でも、正直、あんまり種類が増えすぎるのはどうかと思ったりもしてしまいます。キャラやネタに走るんでなくて、本格的なオペラ歌手のサンプリングとかそっちを個人的には期待するかなぁと。

高田馬場の三味線（2010/12/17）

先日の晩に東京の高田馬場駅に行ったのですが、駅付近で三味線の音色が。人だかりができていたので除いてみると、パーカーのにーちゃんが三味線弾いてました。

ネットはすごいもんで その動画がありました。ブログも書かれてますね。

http://www.youtube.com/watch?v=BETzxBbmXQE

ご年配の方も足を止めて聴いてました、粋だねぇ。高田馬場では有名みたいですね。

Google ebookstore（2010/12/14）

まだ日本ではサービスが始まってないのですが、Googleの電子書籍購入サイト。

http://www.itmedia.co.jp/news/articles/1012/07/news024.html
http://books.google.com/ebooks

Android/iPhone/iPadで見ることも可能みたいですね。日本語書籍はまだないかと思ったら、ちらほらあるみたい。

気のせいか、日本語でひっかかるのは慶応義塾のが多いような。福沢諭吉とかで検索したら、図書館の目次が。

http://books.google.com/ebooks?id=ex5KAAAAIAAJ

300万冊といいつつ、結構ごった煮なのかな。結構古い書物もあるっぽい。でも、古いのはキャプチャの質は悪いかもしれんですね、斜めに傾いてるのとかあるし。800ページを超える書物が無料だったりしますねぇ。

技術書があるか調べたのですが、お目当てのは見つからず。ただ、古い書物をいろいろあさるのには使えそうです。

昔の日本家屋を見学（2010/12/12）

間接照明というか昔の日本家屋の空気感を味わってくるため、近所（といっても歩いて40分ほど）の民俗資料館を見に行ってきました。当時の暮らしの道具なんか展示されているのですが、建造物も保存されてるんですよ、平屋丸ごと一軒が。昔の当時の木材で縁側のある廊下、畳部屋、庭園、とやはり実物はすばらしい。そして、あまり知名度がない場所なのか人がいない(^_^;;。見て回ってる間、管理人さん以外に誰とも出くわしませんでした。

わびさびというか趣があるというか、私はそういうのにトキメキを感じますねぇ。本日見てきたのは、明治20年に建てられた建物とのこと。明治20年が1887年ですので今から120年以上前ですね。ぜひ、これを3DCGで表現したいところ。ということで、作品作りのテーマは決まりました。

ただ、写真撮影は禁止ですので何回か通わないと細かい部分が把握できないかもしれません。GI的にもおそらく日本建築物は難易度が高く、再現が難しいのだろうなと。そんなこんなで天邪鬼な自分としてはチャレンジしたい。小さいころに連れられていった田舎は似たような雰囲気だったので、思い出再現みたいな趣旨もありますかね。

巨大アヒル（2010/12/12）

大阪の中之島に、今年も巨大アヒルが浮かんでいるらしい。

http://www.yomiuri.co.jp/national/news/20101211-OYT1T00427.htm

見に行きたいなぁ、なんでいつも年末のクリスマスまでなんだ(^_^;。これ、登場のたびに撮影された写真をネットで見て癒されてます。

レイトレーシングの画質とレンダリング時間の関係（2010/12/11）

Giレンダリングの場合は、小さい解像度とサンプリング数でまずは試しレンダリングしてから、本番サイズと過去の経験を基にしたサンプリング数でGoする、という場合があるかと思います。

Shadeではレイトレーシングの画質の値を上げていくとサンプリング数が上がり、パストレーシング時のノイズは消えていくことになります。以前、レンダリング時間の見積もりが難しいと書いていたのもあり、レイトレーシングの画質とレンダリング時間の相関関係が知りたかったため、計測してみました。Shade12にて。

以下のレンダリング（パストレーシング/イラディアンスキャッシュなし）で、光線追跡レベルは20。

上記ですと、150画質くらいでノイズはほぼ消えます。

これをグラフ化すると、、、。

のように、きれいな二次曲線に。式では「((画質*n)^2)」（nは定数）のようなものを当てはめていくと、似たような曲線になってました。

ということは、たとえばピクセルのアンチエイリアスが4x4分割、8x8分割となるように、「画質x画質」でレンダリング時間は比例するものと考えてもよいのかも。

ためしに、レンダリング時間の平方根をグラフ化すると、、、。

みごとに線形に。でも、逆算で時間を推測するのが面倒だ(^_^;;。

追記：

計算式にしてみると、画質soのときのレンダリング時間をtoとした場合、画質sのときのレンダリング時間tは、、、

t = to * (s * s) / (so * so)

くらい？結構誤差が出てしまいますが(^_^;;。画質100くらいのときのレンダリング時間を計測して、後は推測してみるのがいいのかな。上記画像のサンプリングだと、画質100のときは61秒なので、画質300のときは「61*(300*300)/(100*100)=549秒（実際の計測では519秒）」、画質350のときは「61*(350*350)/(100*100)=747秒（実際の計測では711秒）」、画質1000のときは「61*(1000*1000)/(100*100)=6100秒」という感じ。

続・入力画像のガンマ補正（2010/12/11）

表面材質の入力画像と色もガンマ補正（逆ガンマ補正）でリニアにしてから、最終的にガンマ2.2で補正してみました。レンダリング画像の出力はShade上ではガンマ1.0でhdr出力、HDRViewでガンマ2.2をかけてから出力しています。

2つめの画像の元テクスチャは以下のような色合いです（これはガンマ補正後であるpng画像）。

ちょっと分かりにくい例ではありますが(汗）。白っぽい問題が解決できてるかと。というか、私が日記に張ってた画像で往々に白くなってたのはいっぱいありますね(^_^;;。この変換が必要ってことであります。

入力画像のガンマ補正（2010/12/11）

おそまきさんのところの「DeGamma」がそのままShade12でも使えたのでこれを使わせてもらいます。

http://oso.tea-nifty.com/blog/

表面材質の色や画像を変換するスクリプトを書かれています。

これで作る手間が省けた(^_^;;。

ガンマを考慮した入力画像（色）と出力画像（2010/12/11)

自身の勉強もかねて。もうちょっとガンマについては掘り下げてみましょう。

突然ですが、言葉の説明。

HDR(High Dynamic Range)

RGBの各色（光量と解釈してもよいかも）を0.0〜1.0とした場合、1.0以上の値を持つもの。公園などで光量をサンプリングできる魔法の機械があったとして、太陽光が直接あたるところを場合は1.0をはるかに超えるけども、ベンチの影は黒く影になっていて0.2とかも共存できる状態。カメラ一発では撮影不可（内部的に何枚か連続撮影して合成するのはあるとは思います）。CGで使われる画像フォーマットはhdr/exrなど。これらは加工後のものではありますが、一応ハイダイナミックレンジも再現できた画像と言えます。

LDR(Low Dynamic Range)

RGBを0.0〜1.0に収めたもの。HDRが生に近いものだとするとこれは再加工したもの。ディスプレイにてきれいに見えている、のはここまで落としてきたものになります。当然、HDRに比べて強さ的な情報は失われることになります。CGで使われる画像フォーマットはjpeg/pngなど。この場合は整数値の0-255段階で表現。0.0〜1.0の小数点表現よりもさらに情報が失われた状態ともいえます。

元に戻って、撮影されたHDR画像を生データとしてIBLでレンダリングした場合は、PCで見ることができるようにするにはガンマを2.2などにする。これはOKですが、では撮影されたjpegやpngなどのLDRな写真をテクスチャとしてマテリアルに貼り付ける場合は？

GIレンダリングで全体的に白くなるのはこれが絡んでまして（二重にかかったような状態）、PCで見て調整した色とか画像を入力に使う場合は、2.2の逆をかける必要があります。もちろん、3Dツールによってはそれを標準サポートしているのもあります。Shadeはないですが(^_^;;。

で、実験しようと思うと、、マテリアルとしての画像と色を補正するプラグイン作らないといかんですね。これはすぐにできそうなので、比較画像はしばしお待ちを。ガンとくる画質が作れるまで、マテリアルは掘り進むことに。しかし、いろいろ要望が(^_^;;。プラグイン作れば拡張できるのでいいのですが、、できれば本体にほしいかもしれないですね。

NHKのホラーゲーム（2010/12/10)

子供向けだそうです、ホラーゲーム。こういうのは大好きです。

http://www9.nhk.or.jp/bitworld/game/ruin_101119/index2.html

つか、クオリティーたけぇ(^_^;;怖いですがな。

Shade12 - 表面材質プリセット（2010/12/09)

Shade11では表面材質のプリセットはbasic/otherの2種類しかなかったのですが、Shade12ではコンテンツデータとして結構増えてます。

ShadeExplorerからドラッグすればすぐに試せるため、マテリアル設定がメンドクサイ場合は使えそうです。

例によって、Shadeでレンダリング後 hdr形式でファイル出力、ガンマ補正はHDRViewで行ってます。露出はそのままで無調整。

私は「とりあえずレンガを」とかすぐ探してしまうのですが、なんでレンガのマテリアルがすぐ思い浮かぶのだろう。昔の8ビット時代のゲームってやたらとレンガのパターンが流行ってたというかよく使われていたので、それの刷り込みかもしれませんね。

先日日記に書いていたものはマテリアルはほぼ無設定の状態でして、ほんとはマテリアル設定に力を注がないと絵的にも面白くなかったりします（あくまでもGIとしてらしくなるかどうかのテストなんでお許しを）。せっかく空気感を出す方法が分かったのもありますので、ちょっと作品ライクなのを作ってみたいなぁ。Shadeドリームハウスに頼らずに(^_^;;その前にR-Billboardプラグインの技術解説をしないとね。

ところで、木のデータ（ビルボード用）が素材としてほしくなりました。どっかにフリー素材ででも商用でもいいのでないかな。写真撮影しても（というか携帯電話のカメラ以外撮影機材を持ってない）、アルファのトリミングが必要なので結構苦労しそうなんですよね。

ebiReader HD（2010/12/08)

電子書籍であるeBookJapanのebi形式のReaderソフトが正式にiPad版に対応してました。

http://itunes.apple.com/jp/app/ebireaderhd/id406624956?mt=8

案内メールが届いてましたわ。で、ひたすらデータ移行。一度トランクルームに上げてからHD版のebiReaderにてダウンロードする必要があるんですね。回線切断が激しいですが、たぶんWi-Fi通信の安定性とeBookのサーバが混雑してるからかも。

iPhone版と比べてかなり広く感じますねぇ。まだ半分も移行しきれてないのですが、以下な感じです。

購入もお手軽なもんで、iPadは私の場合は電子書籍端末（もっぱら漫画）として活躍中。HD版に同梱版としてハルヒの1巻が入ってたのですが、ようは立ち読み版ですね。コミックのはじめの数ページ（これはコミックによって差があります）は、「立ち読み版」としてほとんどの書籍にてダウンロードして試し見することができるようになってます。

もう、有名ダウンロード販売サイトでは書籍数が増え続けてますので（eBookは現在では42000ほど）、書籍の扱いに関してはAppStoreやiBookでなくていいや(^_^;;。人によるでしょうけど、PCではあまり書籍類を読む気がなかったりするので、やっぱり寝ながら読めるモバイル機はデバイスとしても電子書籍には向いてるかなと思ってます。

ゲイン（2010/12/07)

Shadeでは色補正の「ゲイン」というのが露出相当の機能を提供するもののようでした。単位は何なのでしょうね。ゲインでググってみると、増幅器の意味合いだそうな。

ちょっとぜんぜん知識ないので書き連ね、ですが、、。カメラのゲインというのは感度をあらわして、露出は絞りになるみたい。

http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1419568994

ということは異なる意味合いで本来分けるものなのかな。

Shade 12 - 続続続続続・GIテスト（2010/12/06)

HDRViewでhdrを読み込むとかかるガンマ補正値は「2.2」で確認が取れました。確認手順は以下のとおり。

• 一度、hdrファイルをShadeで読み込んで背景だけでガンマ1.0にしてレンダリング、これをhdr形式で保存してHDRViewで開く。そして、bmp形式で保存。
• Shade上でhdrの背景だけのシーンをガンマ2.2にしてレンダリング。これをbmpなどに保存。

この2枚の画像を比較して一致することを確認。

で、確認していて、もしかしてShadeのガンマ補正自身が正しくないかもしれない、というのを発見（HDRViewが間違ってるかもしれないですが）。

Shadeにてガンマ1.0でレンダリングして、hdrで保存。HDRViewに読み込んだ画像が以下です。面光源で照らしてます。

Shadeにてガンマ2.2でレンダリングして、bmpで保存。以下のようになりました。

比較すると、Shadeでガンマ指定した場合は全体的に影部分が暗くなってるみたいです。これが間接照明が弱い原因かな？とすると、ガンマ補正はShadeではなく他ツールで行う（HDRViewとかPhotoShopとか）、露出も他ツールにてガンマ補正の前に行う、が今のところ確実なのかも。

と、休日中Shadeをいじりまくってとりあえず、フォトリアルにする方法と問題点に対する原因らしきものが洗い出せました。私自身はGIソムリエにはほど遠いのですが、たぶん画像をぱっと見ただけで、「なんだか間接照明がおかしい」「このノイズはxxxxだね」とか分かるツワモノもいるんだろうなぁと。

ちなみに、上記の画像は「荒さ」を指定すると磨りガラス表現ができるのと金属のような鈍い反射もできるよ、というサンプルを作ろうとしてた例です。磨りガラスは荒さ20.0、右下の金属球（？）は荒さ1.0です。

Shade 12 - 続続続続・GIテスト（2010/12/05)

室内シーンでどれくらいで高周波ノイズが消えるかの実験。

Shade12にてパストレーシングレンダリングです。イラディアンスキャッシュOffです。

gamma 1.0
視線追跡レベル 100
レイトレーシングの画質 1500
光源は背景IBLとしてのHDRのみ

とレンダリングの画質を奮発。これでCore i5のWin64bitで400x300 pixelにて7時間40分かかりました。レイトレーシングの画質は線形増加じゃないっぽいので、時間の見積もりが難しい、、、。単純にサンプリング数指定ができたとすると、たとえば100サンプルのレンダリング時間を計測して、後は比例計算とできるのですが、、、

で、露出+3/gamma 2.2の補正（HDRViewにて）

で、露出+4/gamma 2.2の補正（HDRViewにて）

若干ノイズが気になりますがこれならOKかな。空気感は問題なさそうですね。レンダリング時間でお分かりのとおり、室内のシーンは面光源がないときは途方もなく時間がかかります（視線からの追跡のみでパストレースするため）。後はレンダラがどうはしょるかというのが大事かと。そのためのレンダリングの方法論はあるのですが、ここでは割愛。イラディアンスキャッシュはノイズを低周波化＋レンダリングを高速化するひとつの解決策ではありますね。でも、細部が薄っぺらくなって眠くなるのは否定できないため、私としては時間がかかってもパストレースのみでよりリアルになれば御の字ではあります。

ということで、なんとか自分にとって好みの色合いを出せるようになりました。

Shade 12 - 続続続・GIテスト（2010/12/05)

先日の日記に書いてた「16677216.0」は「16777216.0」です、どうでもいいことではありますが（汗）。2の24乗ね。たしか、昔クイズ番組にてパソコンオタク（当時は偏見があったのよ）向けの質問で「フルカラーとは何色？」というのがあってそれに即座に16777216と回答していて、会場が「おおっ」となっていたのをテレビで見たことがあります。そのときに画像系プログラミングしてた学生だった自分は、普通それくらいは暗記してるだろうといきがってましたねぇ。今思うとまさにどうでもいいがな、ですが(^_^;;知識なんてそんなもんです。知ってたほうがいいのですが、知ってるか知らないか、なんて些細なことでして。

さて、Shadeの間接照明ですが原因がわかったかもしれないです。

色補正でガンマを1.0にしたShade上のレンダリング画像。

真っ暗ですよね。これをそのままhdr形式で保存。HDRViewに読み込むと、ガンマ2.2(1.8だったかも、このへん不確か)がかかるので以下の画像になります。

Shadeのガンマ指定とは明らかに異なります。

で、露出（exposure）をそれぞれ調整。ちなみに、hdrやHDRViewの露出とは、光の明るさ（RGB）を2^n倍するシフト変換です。

以下は、露出+3

以下は、露出+4

以下は、露出+6

いかに露出が大事か、ってのがわかりますでしょうか？ということで、「Shadeは間接照明が暗い？」というのではなくて露出計算＋ガンマフィルタを適切に調整しないと本来のGI的な絵は得られない、ということになりそうな気がしてます。なお、ガンマ補正は0.0〜1.0のクランプが発生するため（Shadeではわからないです、私が覚えたときはクランプしてた）

• レンダリングを行う。ダイナミックレンジを保持した生データであること。
• 露出調整（2^n倍をRGBにかけてあげる）
• ガンマ補正

で、トーンマップしてあげる/露出は自由に調整できるとよいかも、ってことですかね。露出に関しては後処理なんですが、光源としての明るさを「2^n」倍すれば露出は前処理で再現できるはずなんですが（それが先日の日記の内容です）、なんだかうまくいかないね。

露出とガンマ補正のプラグイン作ろうかな。HDRViewでやってることは単純だったりするので、すぐできるかと。

Shade 12 - 続続・GIテスト（2010/12/04)

Shadeのパストレーシングレンダリングにて、hdrとしての光源のみの室内をレンダリングすると、背景の「光源としての明るさ」を調整しても、なかなか光が行き渡りません。というか、行き渡らないように見えます（実際は1.0よりもかなり低い明るさで存在）。以下、デフォルト1.0/16.0/512.0に変化させて確認したもの。

gamma 2.2
光線追跡レベル  50
レイトレーシングの画質 300
大域照明の反射係数 1.0

徐々に明るくなっているようではありますが、8192.0や16677216.0などにしても結局部屋全体が明るくなることはありませんでした。なお、光線追跡レベルを50と高くしているのは、パストレーシングの場合は視点からレイを飛ばして窓から外に出るまで何回も跳ね返って外にでない可能性があり、より反射を必要とするためです。レイが外に出ない限りは、交差した位置は真っ暗になってしまいます。室内での間接照明が難しかったりノイズが多かったりするのはそれが理由でもあります。面光源使用の場合は、面光源からのレイを飛ばして補正するためになんとかなったりもします。

なお、背景の「光源としての明るさ」は整数部二桁以上の入力をすると「####」となってしまうため、スクリプトにて、

xshade.scene().background.lighting_intensity_factor=512.0

のように指定。

結論から言うと、要因の1つとしてレンダリング画像に対しての露出調整がないために、どうも暗いままの状態が発生しているのかもしれません。イメージウィンドウにて画像編集というのがあり、カラーコレクションでいろいろ調整できるのですが、ここの露出パラメータでは思い通りの調整方法がわかりませんでした。一応、光源としての明るさ=1.0でレンダリングした画像を以下のように調整すると今まで暗かった部分が明るくなるのですが、、

求めるのはこれではないかなぁと。

そこで、光源としての明るさ=128.0としてレンダリングした以下の画像。

これを、hdr形式で保存してHDRViewに読み込んでみました。HDRViewは以下のURLからダウンロードできるWindowsアプリです。

http://ict.debevec.org/~debevec/FiatLux/hdrview/

なんということでしょう。Shadeらしくない色合いになりました。これで空気感は出始めた感じです。結局、他のツール使ってしまった(^_^;;。

でも、HDRViewはガンマを2.2に調整して読み込みだったっけ？ガンマ二重にかかるとそれっぽくなるというのは、なんかたまたまのような気も、、、。

過去、Maxwellなんか触った場合では室内と室外で光源が同じ強さの場合の調整は露出で行ってたのですが、もうちと調べてみます。ちなみに、hdrのみの光源の場合に 同じシーンでカメラ位置を移動させただけでは、室内と室外は露出を調整せずに比較すると、どっちかが明るすぎるか暗すぎるかになります。両方が何も調整せずにちょうどいい感じになるということはありえません。人間の目自身は、意識していないだけで露出を自動調整しているからうまくいくわけですね。

Shade 12 - 続・GIテスト（2010/12/04)

前置きですが、Shade12ではGIとしての質はShade11以前とあまり変わらない感じです。

Shadeドリームハウスのシーンを野外レンダリング。

gamma 2.2
背景の光源としての明るさ 1.0
光線追跡レベル  50
レイトレーシングの画質 300
大域照明の反射係数 1.0

hdrはShade12付属のBackground/Green/Park_of_pine_1.shdbgrです。さりげなく、ビルボードプラグインで木を置いてます。

室内では「なんだか真っ暗になる、間接照明弱いか？」というのがShadeの印象なんですが、あることをすると光源は背景hdrだけのIBLの室内シーンでも驚くほどフォトリアルになります。

というテクニックを次回紹介します。Shade BASICでもいけるはず。ラジオシティは使いません。パストレーシングのみでできます。というか、あるパラメータがShadeは決定的に欠けてまして、簡単にいえばそれを再現すれば「おおっ」っていう空気感が出るんですねぇ、というのをさっき遊んでいて発見しました。レンダリング中なのでしばしお待ちを。びっくりするよ〜、マジで。

Akinator（2010/12/04)

魔人のおっちゃんの質問に「はい／いいえ」で答えていくと、誰を想像しているか当ててくれるやつ。

http://jp.akinator.com/

これの、iPhone版が

http://itunes.apple.com/jp/app/akinator/id325822882?mt=8

にて公開されてます。

昔、PC版のURLをお気に入りに登録していてたのですが、最近iPhone版で話題になったのもあり、ついつい遊んでみたりしてます。ほとんど正解してくれますね、今のところ自分で遊んだ限りでははずれなしです。こういうのは、iPhone/iPadアプリに向くなぁと。何回でも楽しめるし。

R-Billboard Ver 0.0.1.0 for Shade11/12（2010/12/04)

Shade11またはShade12にて、ビルボードをレンダリング時に反映するプラグイン「R-Billboard」を0.0.1.0にバージョンアップしました。

以下よりダウンロードできます（ソース付きです）。

http://ft-lab.ne.jp/cgi-bin/wiki.cgi?page=RBillboard_shade

主な変更点は、空間分割（UG:UniformGrid）を行うことでレンダリング時のビルボードとのレイトレース処理を高速化しました。過去、19秒かかっていたものが7秒に。ビルボード枚数が少ない場合はあまり効果がないですが、ビルボードを数百枚配置してる場合は、結構速度アップしたかと思います。あえてUG使ってることにご了承を。kd-treeとかBVHとかのほうが効率がいいのですが、いわゆる効率のいい空間分割は仕事で使ってるのもありまして、今回は私が昔々から使っていたUG使用ということで。

また、Mac版もビルドしました。Shade12での動作も確認、問題なさそうでした。ということで、正式リリースです。

私のやりたいことは、Shadeドリームハウスから取り込んだ家モデルの前にちょっと木をはやしてGIレンダリングする、ってことだったりするので、それくらいの目的では本プラグインは効果があるかと思います。ところで、ShadeドリームハウスからShadeにデータを持ってきたとき、反射してほしくない表面材質でも反射があったりしてちとGI向きじゃないshd生成ですね。表面材質一括変換プラグインでも作るかぁ。というか、すでに作ってあるのですが自分用なのであんまり公開できるもんじゃないですが(^_^;;。

後、遅くなりましたが順次やってることの技術解説を行う予定です。

Shade 12 - GIテスト（2010/12/02)

メタセコのインポータプラグインですが、そのままShade12で使用できて動作としても問題なさそうです。よかった、、、。

後、背景のIBLは6000x3000 pixelで実用に十分使えるレベルの解像度です。これらが複数付属。

以下サイトより、メタセコのはちゅねさんをダウンロードして読み込み。

http://nanoha.kirara.st/3dcg/file/dlrank.php?top=50

野外シーンのGIレンダリングテストです。

レンダリング手法 パストレーシング（イラディアンスキャッシュ無効）
光線追跡レベル 20
レイトレーシングの画質 300

私はイラディアンスキャッシュを使わない派（なんのこっちゃ）ですので、あえて無効で。

以下、ガンマ 1.8。

以下、ガンマ 2.2。

とりあえず、写真を伴ったIBLを使う＝色補正でガンマ指定、は必須ですのでそれを知らないと、薄暗い画像しか生成できないです。ガンマは即変更してレンダリングしましょう。Windowsですと2.2。Macだと1.8が適切らしい。

マニュアルですと、背景の「光源としての明るさ」を1.0から若干あげているのですが、私はこれには反対です。カメラで撮影された画像自身がカメラマン自身の「俺はこの光の強さがいい」の調整された結果と感じており、明るさ調整としても加工するのはナンセンスかと思ったり。写真データはそのままではディスプレイには向かないので、ガンマ補正をかけるのが妥当かと思います。そうしないと、間接照明は残念な結果になります（たぶん、どのGIレンダラでも同じ）。

野外ではそれなりの質になってますね。ということで、次回は室内を。面光源を使用した場合と、HDRを使った照明のみ、の2パターンが考えられるかな。光が室内に差し込む感じ、がGIレンダラの得手不得手を見極めるには重要と思いますのでとりあえずそこまでレポートしてみたいところです。

なお、モデリングでも強化されてますのでそれもまた記載せねば。

追記：

iPadでもガンマのどっちがいいのか見てみたけど、2.2のほうがそれっぽい？見るデバイスによって千差万別なのと、人によって感じ方が違うのでこればっかりは目で見て確認してみるしかないですね。キャリブレーションしてみる、ってのも手なのかも（私は詳しくないのでそこは語れないっす）。

Shade 12（2010/12/02)

郵送されてきました。1日フライングです。Shade 12 Standard バージョンアップ版。

ただいま、インストール中ですがコンテンツ多し。

パッケージが裸眼立体視できる仕組みになってました。これ、面白いね。BASICだとピンク髪のキャラクタが立体視できるんだろうか。後、アナグリフ（青赤）の紙のメガネ付いてきました。学研の付録みたいなやつ。使ってみての感想や機能の説明はまた今度。

ビルボードプラグインを発売日に間に合わせて公開しようと思ったのですが、、、無念っ。また、恒例の手持ちプラグインチェック＆報告は今週末にでも。今回は、フェイスグループという仕組みで ようやくメタセコからのデータインポートが1形状に複数マテリアル、とできるので、またこれも対応しないといけませんね。