独り言日記（2006/08）

独り言日記

PhysX in CEDEC 2006（2006/08/31）

今まで「ぱいず・えっくす」なんて脳内で呼んでいたのですが、ご本家の発音だと「ふぃじっくす」のようです。

で、イベントでもらったボール。なかなか弾力性があります。

しかし、単純な剛体演算以外でPhysX SDKでサポートされている機能は結構あるんですね。実際、物理運動をするシーンを見たら（QuickTimeムービーではありましたが）改めてすごいなぁと思いました。ただし、今のPhysXは剛体を元にした衝突処理のようで、ソフトボディー・流体は擬似的なもの（剛体を使っての動きを補間したようなものか、、、流体だと球を粒子のようにして動かして表面をメッシュで覆うとか＜勝手な想像です。内部的なことは分かりませんです）のようです。

別の講演でGPUを使った物理演算(Havok FX)も見たのですが、これもすげ〜。いい刺激になりました。なるほど、GPUでこうすれば物理演算に使えるのか、というのが非常に分かりやすく解説されてました。

デバッグ（2006/08/29）

たまに挙動が怪しくなるので今の仕事のソースを追っかけてたのですが、原因をようやく突き止めました。深い深い部分でした。・・・なんか具体性がなくてよくわからんですね(^_^;;。私の場合、よく使うルーチンは（ライブラリまではいかないですが）コピー＆ペーストできるようにまとめてあったりします。この今まで信頼しきっていたソース内にバグがありました。といっても落ちるバグでもなければメモリリークでもないです。とある条件の場合のみに誤動作してしまう、というなかなか原因のつかみにくいものでした。

ところで、デバッグ含むプログラム作業ってみなさんどのように進めるんでしょう。ノってくると脳内ミュージックがかかる、というのはよくあるパターンではあります。後、これは人によって違うとは思いますが、私の場合は脳内に「部品（ルーチン）を浮かす」ということを行います。デバッグのときは特になんですが、トレース機能が使えないときは脳内でプログラムを再生します（よね？）。そのときに、ソース上では気になる変数内容や通過情報をログとして出力するようにして、原因になる部分をログとソースを照らし合わせて追いかけます（ログを出した後は、プログラムを実際に実行するということはしません。後は目と脳で追うのみ）。で、「よし、半分はＯＫ。さらにその半分になるようにログを吐いてチェック」と二分木のようにどんどん絞り込んでいきます。理論上、どんな大きなプログラムであっても少ない労力でデバッグまでこぎつけることができます。

それを、脳内に浮かべた部品をキャッシュ代わりにして最適化するわけです。プログラムは設計もデバッグもイメージで考えていくことが多いのですが、結局そこに行きつくには経験を積み重ねた引き出しがあるから、ってのもあるんでしょうね。

まれに「いずれはプログラムはなくなって、GUIで直感的に（ソースをかかなくても）アプリを組めるようになる」なんて言う人がいますが、それは難しいんだろうなぁと思います。「直感的に」というのは、それだけ数多くのソースを書いた経験があるからできるわけですので、レゴブロック程度までならソースを書かなくてもできるでしょうけど、、、かゆいところに手を届かせるにはやはりソースコードは必要になってくるかなぁと。たぶんCMSもそんな感じかも（私にとっては、やはり窮屈だったりします。万能なものでなくて、限定的なものを実現するならいいのですけどね）。

・・・ところで、たぶん今の仕事のやつは客人のところででっかいバグがあるなぁ（結構報告は入れているのですが、まだまだありそう・・・）。ブラックボックス（ソース未開示）なんで、自分の範囲以外は追えない・・・・。

古い建造物（2006/08/23）

東京に戻ってきました。大阪は夜でも蒸し暑かったのですが、それと比べると東京の涼しいこと（笑）。

さて、最近は味のあるというか、昔の雰囲気を感じるものが好きだったりして、なんかの参考資料になれば、ということで携帯カメラで写真を撮ってきました。

大阪府堺市の大泉緑地

いや−、木造はすばらしいです。風車を見て、PS2の「大神」の１シーンを思い出してしまいました。

阪神甲子園球場（08/21の第88回全国高校野球 決勝戦）

戦前から存在する球場ですので歴史を感じます。上の写真は、試合開始より1時間くらい前のもの。すでに満員の状態。外野のグラウンドは天然芝とのことです（携帯の30万画素のカメラだと、さすがになんかよくわからんですね(^_^;;）。球場周りにある甲子園のシンボルであるツタは今年で撤去される、と（知り合いの阪神ファンに）聞いたのですがどうなんだろう？

夏の甲子園（2006/08/21）

持ち越しになって、08/21に早稲田実業と苫小牧との決勝戦が行われていました。たまたま知り合いとタイミングがあったため、甲子園に観戦に。私自身はそんなに野球には詳しくないのですが（というか、完全な「にわか」ではあります(^_^;;）、これが面白かったです。ありきたりな反応ですが、テレビとぜんぜん違いますね。

甲子園も初見だったのですが、意外とどの席でも全体を見渡せる感じでした。後テレビでの親切はなく、（当たり前ですが）解説はなし、スクリーンに選手たちのアップが映るわけでもなし（試合後のインタビューはアップでありましたが）。ですが、応援と盛り上がり、選手達の勢いは肌で感じてきました。私は苫小牧のアルプス席（一塁側）にいたのですが、９回表の苫小牧のホームランは鳥肌ものでした。ひょっとして逆転するかも？とか手に汗握る展開でしたし。

小さい子達もたくさんいましたが、こんな試合をその若い時期に生で見れるとは幸せだなぁと思ったりします。みなさん青春してるんだなぁと。私はというと高校時代どうだったんだろう？と考えると、いまさら振り返るのもアレですが、、、もっとこんないいものを早めに見ておけばよかった（気づいていればよかった）、というクイが残るだけではあります(^_^;;。

テレビではなかなか映らないのですが、応援合戦や場内アナウンス（声優さんがやってるのかと言うくらい声がよかった気がしたのですが（一瞬、山口勝平かと思った(^_^;;）、現役高校３年の方が担当されてました）などもなかなかの見ものでしたよ。全体を含めて高校野球なんだな、と再認識した次第です。

ただ、さすが夏の甲子園、ものすごい日差しが暑かったです。それにもかかわらず、ほぼ全席が埋まってました。大会歌の「栄冠は君に輝く」が結構ツボにはまったのですが、誰が歌ってるんだろうと思ったら、88回のは夏川りみさんですね。

http://www2.asahi.com/koshien/88/info/song.html

残像効果用テクスチャを作成する（2006/08/20）

どうでもいい日記とアルゴリズムと混ざってなので、見難いですが(^_^;;。残像効果のためのテクスチャを作るアルゴリズムの続きです。

以下のように残像ができているとして、これのテクスチャを考えます。残像用テクスチャは横方向に1ピクセル、縦方向は80pixel分のサンプリングを行うとしましょう。横方向のテクスチャの厚みはないので、UV値のUは不要、ということになります。

ティーポットが残像を作っているとしたとき、残像で一番強くでそうな部分として、以下の緑色部分のエッジ部を検出してみます。進行方向は、ちょっと下を向いた右に流れています。

ただし、エッジに沿って輪郭のみを取り出すのは（これをテクスチャ化するのは）負荷がかかりそうです。ので、ちょっとせこい手を使います。

まず、ティーポットを囲む画像（1ピクセルにてRGBAの情報を持つとしてください。アルファ値が重要です）を矩形で囲んだときの中心を求めます（下図の緑色の部分）。この中心を通る、進行方向に垂直な直線を求めます（下図の細い赤い線）。

この赤い直線上の点を80点分サンプリングして、テクスチャの色とすることにします。図では14点分しか書いてませんが、青い点で示した部分です。この各点から進行方向と逆方向に向かって「１ピクセルずつアルファ値を考慮して」合成していきます。

a1 = col.alpha;
a2 = 1.0f - a1;
rCol.red   = rCol.red   * a2 + col.red   * a1;
rCol.green = rCol.green * a2 + col.green * a1;
rCol.blue  = rCol.blue  * a2 + col.blue  * a1;
if(rCol.alpha < a1) rCol.alpha = a1;

の繰り返しで、ティーポットを囲む矩形の外に出るまで続けます。これで計算されたrColがその位置で採用するRGBA情報です。これをサンプリング点数分（ここでは80pixel分）繰り返します。

で、生成されるRGBAを縦に並べると以下のようになります。

ティーポットとぶつからない部分は真っ黒になり（アルファ値が0）、ティーポットとぶつかる部分はなんとなくエッジの色が採用されているみたいに見える、かな。実際は、1 x 80 pixel分の画像です。分かりにくいので横方向に引き伸ばしています。

これをテクスチャとして、残像の尻尾方向でのテクスチャとすると「びよーんと引き伸ばした感じ」がそれっぽくできます。このサンプリング計算でも負荷はかかりますので、あらかじめそれぞれの方向（たとえば16方向から）にてサンプリングした画像を前処理で作っておいて参照してもいいかもしれません。そうすると、リアルタイムにも使えるかも。ただ、ビルボードに限るわけですが。あくまでも「それっぽく」なんで、たとえば3D物体の場合でも球上に数十点先にサンプリングしておいても、たかだか「サンプリング方向数 x 1方向でのサンプリング数（V方向のピクセル数）」なんでリソースの消費が低いといえば低いですね。ゲームだと、これでも充分かもしれません。

これは推測ですが、シューティングゲームでのミサイルの残像もこれっぽいことをしてるんでないかなぁと思ったりします。

ここまでがエセ・ピクセルブラーでの残像の考え方でした。後は尻尾と元のティーポット形状の合成、です。ってことで、また次回。

続・おでん缶（2006/08/20）

親におでん缶をお土産として渡したのですが、「かわいいキャラクタの缶に入った珍しい形態のおでん」といった認識のようで、あまりネタになりませんでした(^_^;;。ちょっと変わった東京土産、といった感じで。秋葉原の状態を知らない人達からみたら、まぁ妥当な反応でしょうね。

で、実家のADSLモデムを正常動作させるために大阪の難波に行って新しいADSLモデムを探しにいきました。これが売ってないのなんの。NTTのADSLモデムしかなかったのでこれを購入。で、後から確認したら「NTTのフレッツADSL専用」だったということで、早とちりで無駄な買い物してしまいました・・(^_^;;。so-net ADSLでは使えねぇ・・・。

ただ、元のADSLモデムに内蔵されているスプリッタ部分が逝かれていただけで、外部にスプリッタをつけるとうまいこと動作するようになりました。わざわざADSLモデム自身を探す必要はなかったようです。と、しっかり現状の原因を把握してから行動すべし、とまたまた反省点ができてしまいました。この手の早とちり買い物ミスは多いなぁ＜私。昔から、ケーブル類で結構無駄買いしてましたので・・・。

難波も約半年振りに歩いたのですが、「おでん缶」見つけました、自販機と店頭販売のものを2箇所。ただし、LAOXみたいなキャラクタものではなくて、秋葉原の自販機にあるのと同じもののようでした。

おでん缶（2006/08/18）

実家に帰るときにはおみやげを買っていくのですが、駅構内の売店や土産物屋で買うのだけではつまらない、ということでコレを購入。

秋葉原土産です（笑）。なぜか秋葉原では「おでん缶」というのが名物かどうか知らないけど存在するのですが、自動販売機でも売っていますね。その自販機の写真を遠巻きに撮ってる人も見かけたりはするのですが(^_^;;。この萌えキャラのおでん缶はLAOXで販売しているものです。でも、ちょっとしたネタ土産としては、これくらいがちょうどいいですね。

残像効果のアルゴリズムの解説はちょっと待ってください（実家でゆったりと書く予定）。ようやく仕事のマイルストーンを一段落させましたので。

Shadeが起動できないときの対処（2006/08/16）

たぶん回答できそうってのが2chのスレにあって、OpenJane（2chブラウザ）で書き込みしようにも書き込みできなかったのでこっちで回答です(^_^;;。3回くらい書き込みを試したので、もしかしたらどっかで誤爆してるのかもしれん・・。

CG板の「Shade 質問/相談スレッド Ver.10.0」にて、477さんが「Shadeが起動しない、OSがシャットダウンする」というご報告がありますが、単純に言ってOSシャットダウンは、グラフィックドライバが原因のように思います。

nVIDIAのサイトより最新版のドライバをダウンロードしてアップデートすると、Shade起動時のOSシャットダウンは直る可能性があるかもしれません。これはShadeに限らずですが、DirectX/OpenGLをたたくアプリの場合、ドライバによってはOS自身が不安定になることがあります。私も実は過去にはその現象に遭遇してました（Shadeじゃないけど。回りの人では確実にShadeがトリガーになってたのもありました）。

後、ShadeはOpenGLのたたき方があまりうまくないようで、たぶん潜在的に未だにバグの宝庫であるように思います。これが図形ウィンドウ描画で使われているので、起こりうる現象としては

• Shadeが起動しない（図形ウィンドウの描画ができずに落ちる）
• Shadeが起動しても図形ウィンドウの描画がおかしい（くずれる、とか）
• 図形ウィンドウ描画が遅い

ってのがやはり発生することが多いです。起動しない場合や描画がおかしい場合は、Shade上でOpenGLをOffにすればいける場合が多いのですが（起動しない場合はそもそも対処できないですが）、これはOpenGLを経由したソフトウェア描画に切り替えているだけです。なので、安定はするかもしれませんが描画はさらに遅くなる可能性が高いです。描画がそもそも遅いのは、、編集用のバックバッファとして確保してるであろう処理自身がうまく調整できていないんでしょうね（OpenGLのglReadPixels/glDrawPixelsを多用してるんだと思ふ。これは実は報告済みだったりします）。

う〜ん、正直ソースコード公開してくれ（直すから）、って思っちゃいますよね(^_^;;。OpenGLの場合は、特に凝ったことをせずにまじめに扱うと普通に使えるんですが（でも細かい部分でやはりドライバ依存がありますが）、Shadeで表現できるレベルならそれほど大きなトラブルなく実装が可能なはずです。OpenGL速度アップでは、ちょっとしたトリックを使うとずいぶん快適になったりもします（ゲームだとそれほど気にしなくていいのですが、編集系ツールだと、おそらくアレがボトルネックになると思われますので）。

念のため、、、プラグインが悪さしている可能性もあるので[plugins]フォルダをリネームしてからShadeを起動して起動するかどうか、チェックするのも有効かもしれません。タイミングの問題で、、というか具体的に言うと、SDKのAPIにあるplugin_interface::make_wireframeでOpenGLにタッチできるのですが、ここで変なことすれば簡単に図形ウィンドウを崩せます(^_^;;（これ自身はうまいこと使うのが前提でしょうけど、お行儀の悪いプラグインだともしかしたら原因になってるかも。プラグインででも、メモリリークさせると全体的に不安定にはできますけどね）。逆に言うと、うまいこと使うと現ShadeのプラグインSDKで自由に図形ウィンドウにOpenGL描画でいろいろちょっかい出すことができるんです（そんなプラグインは今のところないわけですが）。

ひぐらしのなく頃に（2006/08/13）

なんというか、うまいキャッチだなぁと思います。俳句で言う季語があるというか、情景が目に浮かぶというか。で、このアニメって最近存在を知ったのですがホラーなんですね。雰囲気は好きなんですが、、、私にはちょっと合わないかな、AIRみたいなのを期待してたんですが(^_^;;。

ただ、「ひぐらしって何？」というのを知らない人も最近増えたんでないかなぁと思う今日この頃。都会じゃなかなかお目にかかれませんもんね。夕暮れによく鳴いている（鳴いていた）セミです。ちょっと木が密集している場所でないとなかなか集まらないかなぁと思います。私感ではありますが、都会ではクマゼミ（夏）〜アブラゼミ（夏の終わり）が多く、「ひぐらし」や「つくつくぼうし」は自然がないとなかなか集まらない気がしてます。

で、ひさびさにこのサイト内でなぜか一番アクセス数が多い（苦笑）、携帯写真のコーナーに「自然教育園-2006年夏」を追加いたしました。

http://ft-lab.ne.jp/photo/meguro_2006.html

目黒の自然教育園へは、実はちょくちょく足を運んでまして風流を味わいに行っています。今まさに、ひぐらしが風流レベルを通り越して、うるさいくらいに鳴いています(^_^;;。ただ、鳴き声を聞いているだけで涼しいですね。夏の風物詩、風鈴みたいです。

また、新たな公園を開拓したら載せていきたいです（最近はおんなじところばかり行ってたりしますので）。

帰ってきた１チップMSX（2006/08/12）

予約販売も予約数が足りなくて結局消えてしまったのですが、1チップMSX（FPGAお勉強用）が以下のサイトで復活してました。

http://www.msx.d4e.co.jp/

たぶん購入してもいじる時間もないので（というか以前よりも興味が薄れたのもあって）様子見ではありますが・・・コミケで展示か・・・。コミケって漫画のみかと思ってたんですが、こんなハードもあるんですね。

コミケといえば、昔近畿（神戸のほうだったと思う）で何回か見に行ったことがあるのですが（当時の流行はEVAでした）、Wikipediaで見ると 東京ビッグサイトで今現在開催されているのがコミケで、他のはコミケとは言わないみたいですね。

http://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%9F%E3%83%83%E3%82%AF%E3%83%9E%E3%83%BC%E3%82%B1%E3%83%83%E3%83%88#.E6.9C.89.E6.98.8E

近畿でもすさまじい順番待ちの列に並んだ記憶があるのですが、本場東京だとさすがにハンパない人数でしょうから、並ぶ勇気はないなぁ。今の流行はなんなのだろう、やはりハルヒ関連が多いんだろうか？

残像効果-軌跡（2006/08/09）

残像を作るにあたって、はじめに尻尾を作ることから考えてみます。描画したのは以下の感じです。ティーポットに残像を付けてみました。

ただ、なんか残像っぽくはないといえばないですね。ティーポットと尻尾の境界部にて移動のブラーフィルタをかけるともっとそれっぽくなるかもしれません。

以下、すべてスクリーン座標での２次元処理です。この残像を作る〜元のオブジェクトと合成する、までの処理は作業領域として２Ｄのバッファ（RGBA要素を持つ）を作ってそこで行います。Z情報はいりません、あくまで平面でのブラー作成ですので。ブラー付きの２Ｄ画像がレンダリングできたら、それを本来のバッファに転送することにします。

残像のための軌跡

残像を作るには、オブジェクトが移動したときの移動位置を履歴として保持しておきます。これを結ぶと線になりますよね（下図の赤い線）。

上図の場合は、一番新しい中心位置を含めて6個の座標を保持しています。これを元に「ポリゴンとして幅を付けて」残像部分を描画していけばいいわけです。α値を徐々に0.0に近づけていけば、うっすらと消えゆく効果が出せそうですね。このとき、開始となる点はオブジェクト（ここではティーポット）を囲む長方形の中心としています。

残像のためのポリゴンを生成する

軌跡の方向ベクトルに垂直なベクトルを求めて、それが長方形中心を通るとします。そのときの長方形との垂直ベクトルが作る直線との交点位置を結び、ポリゴンの開始辺とします。後は、軌跡の方向に常に垂直になるようにポリゴンを構成します。奥行きを考慮する場合は、この辺が徐々に大きくなったり狭まったりしますので、これは、履歴として保持している古い中心位置をスクリーン座標に変換した場合のオブジェクトを囲む2Dボックスから判断するといいと思います。

また、残像部分を見れば感づく方もいるかと思いますが、引き延ばされたように同じ模様が描画されています。これは、テクスチャマッピングで表現できそうです。1ピクセル分を横方向にびよ〜んと延ばしているということで、UVのVだけ使用します(1 x n のテクスチャを作成)。このテクスチャのRGBA要素の作成ですが、これは別途行います。オブジェクトの進む方向により残像部の模様を変えたいですよね。ということで、これらは次回に。

残像効果の続き（2006/08/07）

残像効果の実験はようやく形に。諸事情でそのままでは見せられないので後でちょっとアレンジしてキャプチャすることにします。

「妄想理論」ということでアルゴリズムを解説。あくまでも私が勝手に解釈してるだけなんで、適当に流し見してください(^_^;;。ウソがある部分も多いかもしれません。

残像効果って目から見たときのエフェクトのようなもの、と以前書きました。目から見てブラーがかかってるように見える、ということは、実は残像は２次元の産物ではないか、ということから始めます。残像は大きく「移動」「回転」の運動により発生します。拡大縮小は、移動で表現とみます。ここで考えたアルゴリズムは移動のみです。

右から左に移動してるようにみえる

視点から見てそう見えるなら、たぶん左から右に向かって徐々に透明になるような残像効果がかかる。

奥から手前に移動しているようにみえる

スクリーン変換されたものが小さいのから大きいのに拡大しつつ移動してると考えてはどうか。

イメージとしては以下のような感じ。

視点手前方向をZ軸とした運動も、移動により表されます。上の図のような円とは違う形状でも（たとえばビルボードとか）、尻尾（残像）をつけるとそれっぽくなるかもしれない、というのが分かりますでしょうか？では３Ｄ形状は？この場合でも「残像は所詮２次元の産物」と考えます。つまりは、一度テンポラリにレンダリングしてからそれを２次元の画像として扱います。

で、「残像を生む元になる２Ｄ画像」「尻尾」の２つを合成することにより、ぐねぐねと曲線を描くような残像でも表現できるようになりそうです。「残像を生む元になる２Ｄ画像」は、ビルボードだとビルボード画像、３Ｄだとレンダリングした２Ｄ画像を矩形に入れて画像にする、でＯＫ。問題は「尻尾」です。ビルボードだと前処理で用意してもそれっぽくなりそうです。３Ｄだとリアルタイムに（というかその都度）生成するのがいいのかなぁ。単純に１色のみで表現された円だと、単なるグラデーションで済むのですが、もっと複雑な「元の２Ｄ画像」だとどう考えられるでしょうか？

この「尻尾」を作る方法と、レンダリングする方法を次回書いていきます（図と例で示さないと言わんとすることが分かりにくいですね(^_^;;）。曲がりくねった尻尾も、とにかく描く！！そうなると、１ピクセルごとに処理しないといけないのか、というとそういう必要はなかったりします。もっと簡単で手早い方法（おそらくリアルタイムでも実現可能）があります。・・と続きは明日にでも。

鍛える（2006/08/06）

脳も、ではありますが、夏といえば体も鍛えたいというのが私が思うところでして。休日は、暑くなるとだいたいは外で走ってる（ランニング）か散歩に出かけてます。

しかし、自分自身、昔の休日の過ごし方はどうしていたんだろう？プログラムに燃えていたときもあったし走りに行ってるときもあったし、、、ですがそんなに運動はしてなかったように思います（というか本来は苦手です（笑））。最近は仕事以外はほとんどプログラムしなくなったかなぁ。もしかしたら「趣味＝仕事」が成立している現在、別段それ以上プログラムに時間を費やすことに情熱を注げていないのかもしれない、とも思ったり（年齢もたぶんあるんでしょうけど）。仕事でするプログラムは今まで以上に熱中しているつもりです。

ただ、真夏日の中走ったりしていて前回よりも二倍の距離を速度を落とさずに走れるようになった、とかのほうがなんかうれしい（苦笑）。持論ですが、机上での仕事でも、持久力（＆体力）はものすごい大事だと思います。開発だけしてても、年齢を重ねるにつれて限界を狭めてしまうのではと。どうも、「かつてプログラマだった方」をたまに見かけてもなんかそんな気がしてなりません(^_^;;。ええっ、ほんとにプログラムできる（た）の？昔話だけしかしてねーんじゃ（略）、とか。プログラマも会社などではエスカレータ的に管理側に昇進していくことが多いので、そのうちに開発の精神が薄まるのだと思うのですが、そこでどのように自分の方向性を見極めるか、それが分かれ道かもしれない、と思う今日この頃です。逆に、50代ですごい開発者的バイタリティーのある方もいらっしゃったりしましたので、そんなのにあこがれますねぇ。これは体力よりも環境かな？

どれが最適な道か、なんて人それぞれなんで個々人が判断するもんでしょうけど、私の場合は体力＋知力は両方鍛えていきたいもんです（あくまでも自分のペースで）。ただ、ほんと人それぞれですので、プログラミングスキルって自分の場合に当てはめて考えちゃいかん、といつも自分に言い聞かせてます(^_^;;。しかし、一般的に言う年齢に対する最低限ほしいスキルってどの程度なんでしょうねぇ。開発含むモノ造り系のお仕事の場合（開発が、今やモノ造りと言えるかどうかは微妙ですが）は、なんか自分自身でボーダーラインを決めたりしているのですが、よく考えればこれもオレサマ基準だなと。

と、ひさびさにたわいのない今思ってることなどを書いてみました（最近は、このへんはmixiと分けてはいるのですが、なんとなく）。しかし、ブログ＋SNS＋その他、など日記が点在してる方はネタ続くのだろうか、とか多少気になります(^_^;;。過去の日記とか読んでみると、アホな昔の自分が見えたりしてある種面白いですね（苦笑）。私自身、日記系は結構長いこと続けてると思ったら、まだ４年くらいっすか・・・。

ソニータイマー（2006/08/04）

どうも実家のADSLモデム（レンタル）が故障したらしく、その連絡が親からありました。東京のアパートも実家のほうもはso-netなのですが、これがうわさに聞く「ソニータイマー」かっ！！そう思う今日この頃です（so-netのレンタルモデム自身はNECか富士通製ではありますが）。どうも、レンタルのハードは壊れやすいみたいですね。

う〜ん、相性があるのかなぁ、私の場合はテレビからPC（VAIO）からゲーム機（PS2）からいろんなハードウェアはソニー一色なんですが、あまり壊れないです。もちろんso-netからお借りしているレンタルモデムも。もう５年は使ってるかな。

ということで、急遽修理のために大阪に戻ることに。新幹線の座席取れるかなぁ・・・。

残像効果（2006/08/04）

モーションブラーと残像は厳密にはどうやら意味が違うらしく、モーションブラーはカメラによるブレでの表現（？）のようです。

http://ja.wikipedia.org/wiki/%E3%83%A2%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%96%E3%83%A9%E3%83%BC

目が作る妄想である残像を表現するアルゴリズムを考える、ってことで「残像効果」と表記を改めました。

で、実験してみたのですが、それらしく見えるようになってきました。まだバグがあって表に出せる状態ではないのですが、もうちょっと詰めてから理論的な部分を書きためていく予定です。う〜ん、リアルタイムでいけるかな、、、まだオフラインレンダラの範疇から抜け出せない速度ですが(^_^;;。少なくとも、複数のオブジェクトを半透明合成するよりは速度をアップできそうです（2パスにはなりますが）。

ピクセルモーションブラーを考える（2006/08/02）

モーションブラーといえば、1フレームを再分割して半透明合成、という方法が考えつきます。ただ、この方法は物体の動きが速い場合に不都合が出てしまいます（計算時間が分割数分かかってしまう、さらに速い動きをする場合はさらに多くの分割数が必要になってしまう、というか際限がなくなってしまう）。

ゲームでは「引き伸ばし」が使われたりします。これはたとえば3D物体があった場合に、ポリゴンを構成する頂点を速度の逆方向に引き伸ばして徐々に半透明のグラデーションをかけます。これの問題点としては、長い軌跡を描く場合には向かない、アニメーションならいいのですが静止してみればトリックがばれてしまう、など。

でも、シューティングゲームのホーミングミサイルとかきれいにでてるよなぁ。どうやってるんだろ？単純に考えると、軌跡を膨らませてポリゴン化、特定の色でグラデーション、かなぁ（つまり、単純な弾のデザインでないと表現できない？）。

もっとブラーをブラーらしく、となると最終的にはピクセル単位にできないだろうか、という考えに行き着いてしまいました。でも、アルゴリズムがググッても見つからない・・・ってことで、お得意の妄想理論にて アルゴリズムを新たに考案することにしました。

ただ、モーションブラーって結局は人間が動きを目と脳で補間している現象でしょうから、厳密には正確な表現ではないですよね。どっちかというとエフェクト、かな。おそらくこれならいけそう、というアルゴリズムがようやく固まりましたので早急に実装に入らなければ。

• モーションブラーは残像であり、1フレームよりも小さい時間での表現である（時間軸でのアンチエイリアス、とも言えます。が、人間の目からの考えだともうちょっと別視点で考えたほうがいいような気もする）
• ブラーは、１つの視点が勝手に補間している現象。他者が見た場合は違ってみえる可能性あり。
• 適当な脳内補間だから、適当にやったほうがそれっぽくなるかも。

ということで、時間を見つけてこれを8月からの日記ネタにしていくことにします。よくあるモーションブラーのアルゴリズムっぽくない解説で攻めることができればと考えてます。