実は、学生時代にギターとキーボード（鍵盤）をちょこっとかじっていたのですが（どちらかというとキーボード専門）、 「趣味」として最近その意欲が復活してまして、ひさびさにキーボードの教本を引っ張り出してきて 練習してます（もちろん、時間があるときに）。
ギターはアパートでは音が漏れるためダメなので、ヘッドフォンしてキーボード練習っす。
で、リズム（左手と右手のコンビネーション）弱いっすわ＜私。 昔からなのですが「つられる」といった感じで、ぎこちないです。譜面がある曲をマスターする、 とかなら、無理矢理覚え込んでしまうのですが・・・これじゃあ応用は効かないですし（私の場合、途中で詰まると ダメダメになります（笑）。アドリブで次の小節までつなぐ、といった技がないんすね）。
このあたりは、感覚で（体で）覚え込むしかないっすねぇ。しかも、ブランクがあるので 過去覚えた曲をまったく忘れてしまってます(^_^;;。バッハの曲（「小フーガト短調」を足オルガンを使わずに 左右の手だけで弾けるようにアレンジしたやつ。でも、面倒くさくて途中まで、だったりします(^_^;;） とか覚えてたのになぁ・・
DTM用のソフトは作曲用というよりも、どちらかというと 教本の楽譜を打ち込んでリズム感を養うために、という目的で購入しました。
幸い、ネット上には講座を開いておられる方やリアルタイム録音されてる方がいたりしますので、 参考になります。
いい時代になったもんですね。
それにしても・・・仕事が忙しくなると（締め切り近いっす）、別のことに興味を散らしてしまう 性格をなんとかしたいもんです(^_^;;
やっぱし、私事と仕事が共有できる環境だと誘惑に負けてしまう・・・ と考えると、会社って隔離された環境は必要ですねぇ、む〜〜。
存在自体は知っていたのですが、場所すら知らなかったのであらかじめネットで調査してから出向いたのですが・・
歩きまくってようやく発見です(^_^;;。普通、見つけることができないような 場所に存在を確認しました。電気街からはずれたところにあるのね。 外見からして寂れてるなぁ、と思ったのもつかの間、 階段の踊り場（？）で待ち行列に遭遇。並んじゃいましたさ、あぁ。
で、ようやく入ったところで周りを見渡してみると・・・ウェイトレスがメイドさんのコスプレしている以外は、 いたって普通のカフェでした。
（ちょっとオサレな制服と見ればそんな感じっしょ、と言うと連れ曰く「萌えっ！最高！」だそうで(^_^;;。 いや、言わんとすることはよく分かりますよ（笑））
でも、よく見るとウエイトレスさんによって微妙に服の種類が違いますね（そこまで観察するな、って感じですが(^_^;;）。
飲み物代も高いかと思ったら、普通のカフェ・カラオケ屋と同じくらい（ちょっと割高かな）。 テーブルの「90分ほどで席をお空けください。写真撮影（携帯のカメラも含む）はご遠慮ください」（意訳です）は、ちと笑ってしまいました。 ねばる客も過去いたんだろうかぁ、と。
ココ（Mai:lish）がそのカフェのサイトです。
仕事の打ち合わせとかの場所としてはちと向かないですが、話題のネタ・ちょっと雑談する、ってときには いいかもしれないですね。決して妖しい雰囲気ではなかったっす（入り口付近は怪しさ抜群ですが(^_^;;）。
夜はまた様変わりするんですねぇ。
ところで、この店の近くで、メイドさん風の服がショールームのように飾ってあって（一着だけ）、 看板すらない店がありました。その中でメイドさんのコスプレ（？）をした人が なにやら勧誘したと思われる人に書類を書かせていた（ように見えた）のですが・・・あれはなんだったんでしょ？
看板がない、けど 近くに「歯科」の看板があったので歯医者？とか思ったのですがそんな雰囲気はさらさらなかったし、はて？
あわよくば秋葉原でt.A.T.uがゲリラライブしてないかな、とか思って出向いたのに、 結局メイドさんデーになっちまいました(^_^;;
なんか、日本来て印象悪くした感じっすね＜t.A.T.u
（といっても、ファンでもなんでもないのですが）
私は普段から料理をするのですが、お金をかけずに、となるとレパートリーは決まってしまいます。
で、よく作る料理として「肉じゃが」があります。
これで、個性を出せるといっても過言ではない代表格です（笑）。
作り方はいたって簡単です。
- タマネギ半分をきざむ。
- ジャガイモを切る（小さくしすぎないこと）。
- 肉を少々（私は「豚肉薄切り」使ってます）。
- 水を300mlくらい沸騰させ、上記の材料を入れる。
- ぐつぐつしてきた頃合いを見計らい、砂糖を小さじ１杯と半分くらい入れる。
- 料理酒を大さじ２杯入れる。
- みりんを大さじ２杯入れる。
- かき混ぜてから、フタをしてしばらく放置。
- 水分が無くなりかけるタイミングで、醤油を大さじ３杯入れる。
- かき混ぜてから、フタをしてしばらく放置。
- 水分が底をついた時点で、火を止めて盛りつけ。
肉として豚肉を使うのは、ちと意外かと思います。
普通は牛肉ですが、肉じゃがを覚えた当時が「狂牛病」が流行った時分でしたので、 ブタになっとります。
で、何よりも豚肉が肉の中では安い、ってことも大きな理由だったりします。
「豚肉薄切り」のパックだと、すでに切れた状態で売ってますので包丁入れる手間も省けていいですよ。
でも、これでは普通の肉じゃがです。
で、何を思ったのか、砂糖を入れるタイミングで「マーガリン」入れてみました。 隠し味程度なのですが。
ちと、クリーミーな感じの肉じゃがに・・（どんな感じや・・(^_^;;）。
微量の変化を求める方にはいいかもしれません。
料理でうまいことやりくりすることにより、食費をかなり削減できます。
１日300〜400円ほどで押さえることも可能です（しかも、きっちり朝昼晩食べて！！）。
そのへんも今後日記のネタにしていこうかと思ってます。
なんか、Appleからメールが来ましたが「Power Mac G5」発表ですと！
いや、Macははっきりいってどうでもいいのですが(^_^;;「64bit」というおいしいキーワードをひっさげてます。
「apple.co.jp」に詳細を見に行こうかと思ったのですが、つながりませんでした(^_^;;。
G5の石としての性能を見てみたかったのですが・・・、明日でも見に行こうっと。
一般のパソコンでは64bitは初めてでないかな。Solaris(SPARC)とかは64bit版はあったと思いますが。
で、何がいいというと・・・・32bitCPUの場合は、C言語のint型で表現できる整数値の最大は当然32bit（0-4294967295）。 2の32乗の幅があります。約4GBまでの表現が可能です。
64bitCPUの場合はレジスタが64bitであるので、2の64乗（数値にすると0-18446744073709551615）・・・さあ、どこまで表現できるのやら。
精度が32bitに比べて２乗になります。
おそらく、メモリ空間も64bit管理していると予想。
レンダラを作る場合は連続した膨大なメモリ量を確保するのですが、例えば、 3頂点を持つポリゴン（位置と法線を持つ）にて1ポリゴンで192バイト（32*3 + 32*3）の情報を持つとしましょう。
そのポリゴンに連番を振って、ポリゴンをシーン上でユニークなID（通し番号）で管理するとします。
32bit(最大4GBのメモリ空間：0x00000000-0xFFFFFFFF)なら、4294967296/192 = 22369621.333..で、最大でも約2237万ポリゴンしか格納できないということになります。 それ以上の場合は、物理的にメモリオーバーです。
つか、それよりもまず、すべて作業用に使うとOSを起動するメモリがない状態っすね(^_^;;
まあ、ポリゴンごとでなくてオブジェクトごとに分類して階層的にIDを振ればこの問題も解決できるわけですが・・・ん？でもシーン内に全ポリゴン情報を散らばらせるのは無理かな。 それと、構造が複雑化するとそれだけでも速度低下しますよね。
ところが、64bitの場合は、18446744073709551616/192 = 96076792050570581.333...と、結構いけそうです。
（もちろん、メモリが64bit対応するという仮定であります。G5マシンは8GBまで可能、っていうからには32bit幅のメモリ空間ではなさそうな感じですし）
実は、32bitCPUでも「int64」というので64ビットの整数表現は可能ですが、CPU（もしくはコンパイラ）でエミュレートしているような状態です。
これがネイティブになるだけでも、速度的にはアップしますわな。
浮動小数点は、浮動小数点エンジン(FPU)に処理を（現状32bitのCPUでも）投げているため、実際はどれくらい速度アップするのかは不明っす。
（FPUの場合は、現状でも64bit対応はdouble型対応でしているでしょうし）
いずれにせよ、メモリが4GB越えとかなると、メモリアクセスの面で64bitCPUでないと極端な速度低下を起こしますから （32bitCPUのレジスタでは、64bitのメモリ空間に１クロックでアクセスできない・・・たぶん）、これから需要は出てくるでしょうね。
普通のメモリブロック転送も、64ビットで送るとなると・・・単純計算で倍速です。画像転送には当然ながら効果絶大っすね。
いやはや、ようやく一般に64bitが下りてきたかって感じです(^_^)。
たしかに人材不足ですよね。それなりの腕を持った人が企業内に少ないのが現状ですから。
社内教育できるような余裕もなさそうですし。
また、「リーダー（責任者といってもいいかも）がいない・不適切な人がリーダーを無理矢理している」もよく出てきます。
プロジェクトをスケジューリングしたり、全体を把握する（できる）人がいないんですよ。
むしろ、上の（言っては不謹慎ですが「無能な」）人が判断を誤って「デスマーチ突入」って会社は山ほどあります。
この大部分は、（いわゆる決定権のある人の）期間に対する作業量の見積もりが甘いからだと思ってます。社員の能力を理解してないというか・・。 そもそも個々人でコミュニケーションが取れていない、ってのもあるし。
後、自分の管理下以外の部分で遅れてトバッチリを食らうという例もよくおきますね(^_^;;。 これも、全体を見渡せるリーダーがいないから、ってのもあるかもしれません（他社との連携時は特に）。
そんなこんなで、じゃぁプロジェクトとして成り立ってないやん、と思われるかと思います。 まさにその通りで、成り立たないんです(^_^;;。
で、その事実に上層部の人（プロジェクトの主旨が分からない方々・ノータッチな方々）は気づいてなかったりする。 もちろん、できる企業・団体もあるのも事実です。が、大部分はどうでしょうね？
でも〜、なかなかすべてを把握して指揮を取るなんて難しいことですよね。
リーダー（仕事において舵を取る人）がしっかりしていると社員のモチベーションも上がるし、もしかしたら「できる人材に」なるための教育も出来ていくかもしれない。 そう思うと「人材不足」よりも「リーダー不足」な現状を打破しないといろんな意味で好転はしないっしょ、と思っています。
たぶん、大部分の（「IT革命」というなんだか分からない肩書きを未だに引きずっている）日本の会社がそんな感じがしてます。
・・・ってのを、いろんな立場の人から聞いたり自分でも思ったりしますねぇ。
プログラマっていうのは、自分でスケジュールの見積もりを立てて・設計して開発、などは日常茶飯事ですので （自分で立てたスケジュール通りに期限を守れないのであれば、プログラマは失格っす（笑））、 システマチックに（論理的に）会社ごと引っぱっていってあげるリーダーには向くのでわ、などとも思ってます。
まあ、ぶっちゃけ「妄想」なんですが（笑）。
いやはや、好転させたいもんですね。
私の経験則ですが・・・
対外的に対会社でお仕事をされる方は、以下のことで探りを入れておくと幸せになれるかも、です。
「その会社の上層部の人（例えば社長とか）の意気があるかどうか・業務内容を理解しているか。」
「直属の担当者が仕事を理解しているか（一度抜き打ちで仕事内容を即興でプレゼンしてもらうと、信頼してもいい人かどうかすぐ把握できるかと思います）。」
「ドキュメント（仕様書・報告書など）をきっちりと残しているか（誰が何をしたか、というのが明確な会社かどうか）。」
「他の人が何をしているのか、クリアであるかどうか（社員間で仕事を理解しているかどうか）」
上の１つでも出来ていない会社だと、やはり「ゆるい」っす。
このあたりの（浅いですが経験的な）ノウハウは、社内プログラマであった時代は身に染みては実感できませんでしたねぇ。
むしろ、一度離れてみて何やら見えてきたって感じです。
もちろん、これは新入社員の方にとっても、入社する会社を判断する一応の目安にはなるかと。
そんなこんなで、これもTipsとして（笑）日記に書いてみました。
甘いものにさらに甘いモノを加えた組み合わせではありますが・・・ え〜〜、アメリカで飲んだ原液バリバリのジュースを思い出しました(^_^;;
日本人には合わないんでないかなと・・私はもう勘弁って感じです（苦笑）。
さて、レンダラは一段落してアプリケーション部を作ってます。
データ処理・管理の基盤から作っていて、OSのような仕組みとJavaのようなマルチプラットフォームを狙ってますので・・ 道は長いっす。今年中に完成するかなぁ。
つか、どっから沸いてくるんだろ・・・
ナメクジといえば足跡を残していきますので、当然経路は濡れているはずです。 しかし、まったく濡れてないし。かといって天井をはってきた形跡も見られず・・・ そもそも、アパートの１階ですので天井からダイレクトに進入・・というのも考えにくいです。
過去３回ほど家の中でナメクジを目撃していますが、すべて同じ位置に出没ってことは なんらかのトリックがあるんでしょうねぇ。
で、ナメクジの退治方法なのですがご存じでしょうか？
実はナメクジはビールが大好きのようで、 ビールを入れたカップをおいておくと、その中に入っておぼれ死ぬようです。 しかも、鬼のように集まります(^_^;;
一網打尽にするには効果的ですが、周囲のが寄り集まってくるとすると、あまりいい気はしないですね。
・・・東京の23区内なのに、毎日がサバイバルです（笑）。 今まで家の中で見た生命体としては、アリ・クモ（小型）・ネズミ・ゴキブリ・ナメクジ・でっかい蚊・キリギリスを華奢にしたような未知の昆虫、 と実家よりバリエーションに富んでます。かといって、私自身きれい好きなほうですので、ゴミはまったく散らかってないです。 （段ボールは散らかっているけど(^_^;;）
いや〜〜、自然ってすごいですね（壊）
今は結構私自身も免疫ついてきて、ネズミの足音ごときではびくともしなくなりました。 そのかわり、ちょっとした変化で何かの気配を感じ取る、といった感性は、 たぶん実家にいるときよりも研ぎすまされたと思います(^_^;;
夏はクーラーも扇風機も使わないし、冬は暖房を使わない（コタツのみ）って生活を続けると、 体だけでなく精神も鍛えられますね。おすすめです（笑）
「Fast Ray Tracing by Ray Classification」(James Arvo & David Kirk)という1987年（！！）の Siggraphの論文で発表されたアルゴリズムです。
レイトレーシングの速度的なボトルネックを改善するために有効です。
同タイトルでGoogleなどで検索すると論文がヒットするかと思うので、興味のある方は読んでみるのがいいかと。
いわゆる空間分割法のアプローチの１つなのですが、普通はXYZ軸に対して空間を分割するのに対し、 Ray Classificationでは方向により空間を分割します。方向をUVで表現することによる「５次元」（XYZとUV）で 空間を管理します。
これにより、レイトレーシングなどのように方向を持ったレイが飛び交うときの、 オブジェクト・ポリゴンとの交差処理を少なくすることができるようになります。
これで合っているのかどうかは分からないですが、私が採用した理論は以下のような感じです。 （論文はあくまでのヒントですから・・・と正当化してみる（笑））
中心を持つ点光源とスポットライトを方向を考慮した空間で管理し、影生成時の交差判定を最適化しています。
上記の図のように、光源を中心として６方向の面を持つ仮想的な立方体で囲みます。
で、各面ごとを縦横（便宜上、縦=U・横=Vとします）に分割してグリッド状にします。 この各格子から外をのぞき込んだ感じを想像してください。
上図では、赤で塗りつぶされている部分がとある１つの格子で見えるオブジェクトなりポリゴンになります。
この「見えるオブジェクト・ポリゴン」の番号を格子ごとに保持していきます。
例えば、UV共に40分割した場合は、40*40*6 = 9600 個分の格納領域が必要になることになります。
もちろん、光源ごとにこの情報は個々に必要になります。
この場合は、「光源から特定の方向にレイを飛ばした場合にぶつかるポリゴンをキャッシュする」といった意味合いになります。 つまりは、影の生成に使えそうですね。
光源からの（または光源に向かう）任意の方向ベクトルが、上図の光源を囲む６面のうちのどのUVに内包されるのか、というのを 計算すると、その方向からはどれくらいのオブジェクト・ポリゴンとぶつかるのか、というのはすぐに算出できます。
ぶつかるポリゴン数が少ない場合は、その場で各ポリゴンとの交点計算を行い、一番近いポリゴンを採用、とすると 普通に空間を3DDDAでたどるよりも効率がいいです。
ただ、方向で見て交差ポリゴンが多い場合は、普通の3DDDAで空間をたどるほうが速度的にいいかもしれません。 そのあたりの切り分けも速度アップのコツですね。
この各面のUVの１要素に対し、奥行き情報も保持できるかもしれませんが、 その判定自身が時間がかかりそうなので（２つ以上で交差しているとその別処理もいりますし） 今回は、単純に「ある方向から見えるポリゴンを列挙」してます。
１つの平行光源と１つの点光源を配置したシーンを影付きでレンダリングした場合、 適用前 19.2秒だったのが適用後16.8秒と、約2〜3秒ほど速度アップです。 もっと、点光源・スポットライトが増えると体感できるほどにはなるかもしれません。
Ray Classificationは、光源だけでなくシーン全体も「方向」で管理するみたいですので 上記で説明した方法だけが、Ray Classificationの神髄ではないってことだけご了承を。
また、グローバルイルミネーションでも応用は利くと思います。
ということで、現在のレンダリング結果は以下のような感じです。
Athlon 1100MHz/Mem512MBのWindows 2000環境で、640*480のレンダリングを行っています。
19215ポリゴンのシーン。光源は平行光源１つと点光源１つです。
http://y-yutaka.cool.ne.jp/diary/img_0613_2.png
9510ポリゴンのシーン。光源は平行光源１つと点光源１つです。
http://y-yutaka.cool.ne.jp/diary/img_0613_2.png
今まで使ったレイトレーシングの最適化技法をおさらいすると、 空間分割にユニフォームなグリッド分割、3D空間の走査に3DDDA、セレクティブレイトレース、点光源とスポットライトの影生成でのRay Classification、 といった感じです。
もちろん、主たる理論的なことはこれくらいなのですが、実際のコーディングでこれでもかというくらいに最適化してますので・・・ レンダラを書かれる場合は、いろいろチャレンジしてみてください(^_^;;
さて、レンダラのほうですが、さらに速度アップができそうです。
以前ちらっと書いた「Ray Classification」ですが、これを点光源とスポットライトに対し実装中です。
まだ知識不足なのでウソ付いているかもしれないですが、中心を持つ（光源・視点など）オブジェクトを 方向（ベクトル）で分類をした場合に（「直交座標」ではなく「極座標」で空間を管理する）、 一方方向から局所的に見ると交点計算が従来より少なくてすむような感じがしてます。
一定方向から見たときのオブジェクト・ポリゴンとの交差が多い場合は従来の3DDDAに切り替える、とかのスイッチングを行うことで Ray Classification自体が苦手なシーン（というよりも方向ベクトル）のときは従来の方法で、とかもできそうですね。
影が関わる場合に大きく貢献しそうです。逆に、影を生成しない場合はあまり効果がないかと。
まだ実験段階で実装途中ですが、結果が出次第、詳しいアルゴリズムを説明していこうかと思ってます。
後書き忘れてましたが、なぜわざわざレンダラを作っているのかというと、遠い将来に自分でストーリーのある動画作品を造ってみたい、 っていう目標があるんです。となると、高速なレンダラも必要です。 どうせなので自分好みのソフトウェアを作っちゃえ、ってことであります（飛躍しすぎ(^_^;;）。
ゲームキャラデザイン用のモデラーも作りたいなぁとか・・・ホビーとしての「おもちゃ」（アプリケーション）作っていきたいです。
最近の3DCGの冷え込みを見ると寂しいのですが、なんとか盛り上がるための力になれれば、とも思ってます。
といっても、コアな方々にとってはアツイには変わりないんですけどね（笑）。 私としても、8ビット全盛時代に「Oh!FM」という雑誌で見たときの感動以来、魅力にとりつかれてます。
当時は、複数の球が配置されていて反射している程度のものでしたが、レンダリングに数日のレベル。 雑誌に行列式が出ていてさっぱりだったのですが（といっても当時小学生だったので(^_^;;）、 まさかあの当時に将来レンダラを作る（作れるようになる）ことになろうとは思ってもみませんでした。
いやはや、感慨深いものです。好きこそ継続の元ですねぇ。
レイトレーシングを行う場合、例えば640*480ピクセル分の描画を行うとき、 640*480 = 307200回分、視点からスクリーンに向かってレイ（逆光線）を飛ばす必要があります。
また、スクリーンから飛ばされたレイは各オブジェクト（ポリゴン）との当たり判定を行わなければなりません。
以下のように２つの球が存在する場合、すべての交点計算は (640*480)*2 = 601440回行う必要があることになります。
オブジェクトがポリゴンで表現されている場合は、「スクリーンの総ピクセル数 * シーン上の総ポリゴン数」の交点計算を行う必要があることになります。
これに反射などの要素が加わった場合は、交点計算だけで1億回の計算なんてざらです。
さらに影を生成する場合は、光源と調査点との間にオブジェクトが存在するかという交点計算も行う必要が出てきます。
で、レイトレーシングのボトルネックになるのは、まさにこの大量の「交点計算（レイがオブジェクトまたはポリゴンと交わるかの判定）」なんです。
でも、各１本のレイは、すべてのオブジェクト（またはポリゴン）とは交差判定を行う必要がないはずです。 極端に言うと、レイの進行方向の近辺にあるオブジェクトとだけ交点計算を行えばいいのです。
っていうことで最適化として、シーン自体を簡単なオブジェクト（直方体・球など）でグルーピングして 交点計算を極力少なくする「空間分割」という方法があります。
大きく分けて、「バウンディングボリュームによるオブジェクトの階層管理」と「シーン自体をグリッド分割してオブジェクトを管理」する方法が有名です。
「バウンディングボリューム」は、オブジェクトを簡単な形状（球・直方体など：バウンディングボリュームといいます）で包み込むようにし、 そのバウンディングボリュームとレイとの当たり判定を行います。これにより、明らかに当たらないオブジェクトを早い段階から「刈り上げる」ことができ、 交点計算の候補からはずすことができます。
また、バウンディングボリュームを階層的に生成し、さらに交点計算を減らすことも有効です。
シーン自体をグリッド分割する方法は、シーン全体をグリッド状（マス目状）に分割して、その各マス目内に属するオブジェクトやポリゴンを保持します。
レイがシーンに入ったとき、そのマス目をたどっていってマス目内に存在するオブジェクトとの交点計算を行います。
これにより、レイを飛ばしたときに手前にあるオブジェクトから順番に交点計算の候補にしていくことができます。
下図の場合、はじめに四角形に当たるため、四角形との交点計算のみを行うといいです。
空間の管理方法は、グリッド状にXYZそれぞれの方向に等間隔に空間を分割管理する「ユニフォーム(Uniform)」タイプと、 八分木などを使って再帰的に空間をグリッド上に細分化する「ノンユニフォーム(Non-Uniform)」タイプがあります。
八分木のほうは、メモリ的にも速度的にも単純にグリッド分割するよりも時間がかかったです。 （これは管理方法がまずかったのかもしれないですが）
また、空間分割された空間を前からたどる方法として「3DDDA」があります。
「3DDDA」は、3次元空間において直線上の交差するマス目を順にたどっていくアルゴリズムです。
アルゴリズムはややこしいので省略です。Bressenhamの直線描画の方法とは感じが違いますので注意です。 「3DDDA」は、たどっていって少しでも交わるマス目を順に検出していくことができます。
こんなわけで、「交点計算をできるだけ省こう」というのが最適化の一番重要な課題となります。
私の作っているレンダラは、シーンをグリッド分割(32*32*32)して、3DDDAでたどる方式を採用しています。
あんまり空間分割の精度を細かくしすぎるとメモリを食いますし、3DDDA自身が遅くなることもありますのでバランスが大切です。
でも、これでもまだ「レイトレーシングは遅い」です。なので、もっと最適化できる方法はないのか、ってことで 編み出された方法があります。これはまたの機会に。
以前紹介した「セレクティブレイトレース」もさらなる最適化の方法の１つですね。
いつも粘着シートは２枚分セッティングしているのですが、そろそろ効果が切れてきた（ネズミが慣れてきた）のかな？
いつ目の前にあらわれるかのサバイバルに突入したもようです(T_T)。
（いや、古い木造アパートですのでそのへんの覚悟はいるのですが、気になるなぁ）
一番「ねずみ捕り」として効くのは、鉄製の網カゴのようですね。一度ネズミが中に入ったら扉が閉まって出られなくなるやつ。 で、捕まえた後の処理が「水死させる」だそうで・・・。昔ながらの手法が一番効く、なんて不思議なもんです。 ちなみに、私は水死させるのを凝視できるほどの根性はないです(^_^;;
やっぱ、粘着シートに引っかけてポイかなぁ。
ちなみに、「ペストX」という超音波を出してネズミを寄せ付けなくする、といううたい文句の機器があるのですが、 それは、「効かない」ことが証明されているそうです。
東京に巣くう野生生物（ネズミ・カラスなど）は頭がいいですので、人間との知恵比べですねぇ、ほんとに。
人工知能ネコ型ロボット（注意：ドラえもんではないです（笑））、マジでどこか開発してほしいっす。
当分は、近所で徘徊しているネコ達にがんばってもらうほかはありません（幸い、ご近所さんが放し飼いにしてますので いろいろいるんです）。
ネコを飼っているだけで（おそらくネコのニオイで）ネズミが寄りつかないみたいですね。
いいなぁ、ネコ飼いたいなぁ。でもアパートなんでダメ。というよりも、自分の生活費でいっぱいいっぱいですが（笑）
台所にゴキブリが出たため、とりあえず洗剤ぶっかけてみました。
数秒でひっくり返って活動停止。結構効くもんですな。
仕事の書類仕上げないとダメなのですが、なんとなくずるずるしてます(^_^;;。
締め切りまで後少しなのですが・・・夏休みの宿題状態。で、飽きずにレンダラいじってると。 い・いかん・・・。Ray Classification実装したくなってきました。 （今まで勘違いして覚えていたかも。日本ではアルゴリズムまでを紹介しているサイトがなかったので、 海外の論文をあさっていました）
たぶん、光源（点・スポットライト）にてRay Classification実装することで、 「影生成」の効率はかなりアップするような気がしてます。詳しくは後ほど。
簡単に説明すると、空間管理時、 XYZの３方向にレイの方向（UVの２軸で表現）を加えた「５次元」で 「レイがオブジェクト（またはポリゴンに）と交差するか」という情報をテーブル管理する方法です。
（はい、ぜんぜん分かりにくいですね。すみません・・・）
意欲が別方向に傾くのも、ある意味誘惑ではありますね。
学生時代にもっといろいろ掘っておくべきでした。
勉強時間がいくらでもほしい今日このごろです。今現在が一番勉強意欲があるかも。 今なら、英語とかも理解できるだけのモチベーションが引き出せる、かな（笑）。
なにげに毎日日記更新中ですが・・・たわいないことばっかりっすね(^_^;;。
ほか、譜面やら十数年前のプログラムソースやら・・・懐かしいっす。
ひさびさに鍵盤を引っぱり出して何か練習してみようかな。
さて、レンダラですがボトルネックになる部分をいろいろ探ってみました。
かなりカリカリにはしたつもりで、もうチューンのしようがない感じになってきているのですが、 「影処理」と「アンチエイリアス」が大部分を占めてる感じがします。
アンチエイリアスは、調査時の色差分のしきい値を0.15と少し甘くすることで、 45秒→36秒と大きくレンダリング速度に貢献しました。見た目には差は見られないので、 標準（デフォルト）はこれくらいでもOKかも。
このしきい値は、外部からも調整できるように関数を通して制御できるようにしました（ツール内では、「エキスパートモード」みたいので調整可能なようにしようかと）。
影処理は、調査点と光源とを結ぶ直線内に物体（ポリゴン）があるかどうかという判定を行うのですが、 この処理自体、視点からレイを飛ばすのと同じ負荷がかかります。影の影響度を調べるためには、 これを光源数分調査するのでそりゃ重くなりますわな。 かといって、シャドウマップは使いたくはないっす。
現状で、総ポリゴン数19215のシーンで 平行光源と点光源の２つがある状態にて（アンチエイリアスも行う）、反射なしの影なしで「4.7秒」・反射なしの影ありで「19.2秒」と、差は歴然です(^_^;;。
できれば、影ありでも10秒ジャストくらいにはしたいところ。
調査点から光源に向かって逆光線を飛ばして調べる、 というより光源からシーンに光線を無作為に飛ばしたほうが速度的に有利な気がしてきました。
光源からの光線がポリゴンにぶつかるときの情報をキャッシュして・・・ となるとフォトンになってしまう(^_^;;
影になる範囲が広いほど、この速度差は大きくなるでしょうね。
とはいえ・・・レンダラを極めることが目的ではないですので、とりあえずは現状維持で「ツール作り」進めていきます。
アンチエイリアスあり（4x4）で48秒だったのが44秒ほどに改善されました。
サンプルでは（2003/05/31の日記の画像参照）、 すべてが反射体のため時間がかかります。
けど、なによりもネックとなっているのが「影を生成する処理」です。これは何とか最適化したいとこですね。
では、前回予告していた、
アンチエイリアス処理をかけるにはどうするのか、というのをあらためて解説です。
- レンダリング領域を格子状に区切って、その交点での色(RGBA)を取得
この状態では、アンチエイリアスがかかっていない状態です。
上記の赤色の位置の色情報を取得します（レイを飛ばす）。
「各ピクセルの間（格子の交点）の色情報を取得する」というのが肝です。
ピクセルの中心ではないですよ。
これらの情報をバッファに蓄えておきます。
- 1ピクセルの細分化
1ピクセルを注目して見ていきます。
周囲の４つのコーナーをABCDとします。
このABCDの色情報（すでに計算済みですね）の平均を取ります。
具体的には、
です。O = (A + B + C + D)/4.0
このとき、AとO、BとO、CとO、DとOとの「色の違い」 を差分で求めて比較します（比較については後述）。
4つの比較共に条件を満たした場合（あまり色の差がないと判定された場合）、 このピクセルの色を平均色である「O」とします。
１つでも色の違いがある場合は、１ピクセルをさらに４等分します。
そして、新たに出来た中心位置（dO）・交点の位置（dA/dB/dC/dD）において、 色情報を取得します（レイを飛ばす）。
さて、この状態で「A-dC-dA-dO」「dC-B-dO-dB」「dA-dO-C-dD」「dO-dB-dD-D」の４つの領域に分けることができました。 同様に、この４つにおいて内部の色情報を調べていきます。
この４つの領域で得られた色の平均値が、最終的な１ピクセルの色となります。
もう見えてきましたね。これを「再帰的に」内側に向かって細分化していくことにより、1ピクセルより小さい部分も考慮された色を返してくることができます。
再帰レベルを決めて抜け出させることにより、「2x2」「4x4」「8x8」とより細かいアンチエイリアス処理を行うことができるわけです。
これらの細分化は全ピクセルに対して行う必要もなく、1ピクセルのコーナー４点がほぼ同じ色であればスキップされます。 ので、細かい（粗い）部分のみがさらにアンチエイリアスが掛かる状態となります。
では、細分化のキーとなる「色の違い」の判別条件ですが、 このレンダラではRGBをHSVに変換することをまず行ってます。
色相(H)/彩度(S)/明度(V)は、比較的人間の目で敏感な色の格差を表現しやすい、ということで 採用しました。
H（色相は度数で表現されます）はまだなので、とりあえずSとVのみの比較。
SとVは、0-1の間の小数値を取るとします。
2つの色を(h1,s1,v1)(h2,s2,v2)とします。これの差分を求めます。
d1 = fabs(s1-s2)
d2 = fabs(v1-v2)
として、d1とd2が共に0.1以下であれば色に差がないと判断してます。もちろん、Hやアルファ値の差分も比較対照に加えたほうがいい、というのは言うまでもありません。
このアルゴリズムは有名な方法でして、たぶんいろんなレンダラでも使われていると思います。
「コンピュータグラフィックス 理論と実践」って分厚い本があるのですが、 触り部分はこれにも載ってます。
何か、順番はめちゃくちゃですが(^_^;;、これにてアンチエイリアスについての奮闘記はFixです。
次回は空間分割の予定です（たぶん）。お楽しみに！！（・・・つか、今更レンダラ作りたい人いるんやろか(^_^;;）