!!!独り言日記 !!Big fat cat（2005/03/31） 今年の目標として何回も挫折している「英語を覚えたい」というのがあります。 とりあえず、何かトリガーが体感できるところまで勉強したいなということで、 知り合いに教えてもらった「バカでも分かる英語の本」のご紹介です。 （私含めてバカばっかりですので、今度こそっ！！） 「ビッグ・ファット・キャットの世界一簡単な英語の本」 http://www.studioetcetera.com/bigfatcat/ 物語になっていてシリーズ化してます。 さらっと本屋で見ていたのですが、これなら読みやすそうです。 プログラマでプログラムの腕はあるのですがなぜか英語だけはできない （プログラム言語は 私も５種類以上使いこなせるのですが、英語はからっきし）、 って人は多いですね。 仕事で使っているから楽なんだろうか、しかし絶対英語しゃべれる人口の ほうがプログラマよりも多いはず・・・。 遊びの中で英語を覚えていけるというと読書や映画なんで（おそらく 私の場合は遊びにならないと覚えないと思うので）、 とりあえずは１日の中で時間を見つけて理解していきたいものです。 ということで「英語ノート」を作成。がんばっていこうと思います。 いろんな意味で、幅を広げて基礎体力をつけねば。 プログラムが難しい、って言っている人って同じ気持ちなんだろうなぁ。 まぁ、一緒にがんばりましょう。 !!もうすぐ４月（2005/03/29） だからなのか、うちのアパートの両隣が引っ越していったようです。 いつの間にか人の気配が消えてました。 ただ、貧乏生活に慣れてないとアパートはハードルきついでしょうね。 ゴキブリ・ネズミ・ナメクジ・すきま風、これに耐えることができないと （実は梅雨になるとどこからともなくナメクジが畳に鎮座していることが あるのです）。 後、壁が薄いので隣人の会話や鼻歌が筒抜けです（苦笑）。 私はそんなことは気にしないので鼻歌歌って仕事したりしてるんですけど。 そんな質素な生活が好きなもんで楽しんでいるのですが、地震は怖いですね。 最近はよく揺れを感じます。 さて、仕事の締め切り第一段の納品段階に入りました。 ようやくここまで来ました。が、できたバイナリが300KBくらいになった ときの妙な悲しさ・・・。1MB以上は詰め込んだつもりだけどなぁ、むむっ。 後、４月中に仕事用（いわゆる会社・・というか事務所ですね）のサイトを立ち上げないと いけませんので即座に作業をシフトしてます。 今年は面白いことをしたいなぁと思ってますが、会社だと「実績」が 大事というのを身にしみて思います。 普段は仕事仲間は二次受け・三次受けの仕事が多く、この場合は 仕事内容を公にできません。 私も、システム開発を主に行うはずなのですが（実は３Ｄは趣味というか サブだったりする）、「ああ、これを表に出せると大きなアピール材料になるのになぁ」 という悲しさがあります。 二次受け・三次受けというのは、実は大手ほどよくやる手段です。 いわゆる上から見るとアウトソーシングですね。これは、管理だけを行って 実作業をすべて他社に任せてしまう、という仕事のやり方です。 大きなプロジェクトになると、さらに他社から他社に仕事を 振って、と流れます（孫受け、曾孫受けといわれる状態）。 私はこの方法は好きではないのですが、なぜそんなことになるのでしょうか？ 「こんなことをすると技術自身が他社に取られるのでは」と思われるのですが、 実際は技術も上流過程では持っていないことが多いかもしれません。 （これに派遣が加わるとさらに拍車がかかり、結局は左から右に流すだけを 上流でしているように見える） しかし、奇妙なことに「実作業をしないほうが利益になる」なんて へんなからくりがあるもんで（つまり蛇口の元栓を押さえる感じです） そんな方法が最近増えてますね。個人的見解としては、M&Aってそんな ことかなと想像してます。 海外にも（特に中国・韓国）遅れを取ってると思われますので（技術で言うと 日本はすでに追い越されていると思う）、気づいてほしいのですが・・・。 利益追求型だと実がつかないと思うのですが、実のつくことに集中すると 経営が成り立ちにくい。ジレンマはありそうですが・・・ 数年先は日本はどうなるんでしょうね。 最近は経営的なことを教えていただく機会が多いので、いろいろ勉強させて もらうのですが、技術と違って難しいなぁと。これも才能がいると思います。 私には少なくともその才能はないです(^_^;;。 私は珍しくお金にはまったく興味がないので、これも改善しないとダメですね。 作業してもお金を安く見積もったり（もしくは無償でやったり）するんで、 これじゃあ労働の対価がなければ 相場は崩れるわ、というのをようやく最近理解した次第です(^_^;;。 社会全体をみたら、やはりこのへんは必要だわなぁ。 良くも悪くも「世の中お金」というのは間違ってはいないと思います。 （ホリエモンを見ていても、なんか一周回ってきてその理論を展開してるのかな、とか 思ったりしますし。もちろん、信頼を尊重しているようには見えないので そのあたりで異論はありますが） でも「技術」は好きなもんで、それを公開するのは 自分の趣味というか見せびらかし根性かもしれませんね(^_^;;。 なんで、このサイトでは今までどおり趣味を展開していければと思ってます。 仕事系はまたオフィシャルで、ってことで。 !!モナリザ（2005/03/26） テレビで特集やってたもんで見ました。 モナリザはダヴィンチの代表的な絵画で、ただいまルーヴル美術館にあるものですね。 正直、モナリザ自身は（私自身の感想として）魅力に感じてなかったのですが （絵としては理解できるのですがちょっと怖い雰囲気だなぁと。好みと違う、ってやつか）、 もう一枚のダヴィンチ作と言われる「アイルワース版（Isleworth）」 は魅力的ですな。 贋作かどうかは不明ですが（テレビによると鑑定中らしい）、美形だなぁと 感じました（結局好みかよ、っていうツッコミはなしで(^_^;;）。 とはいえ、私自身、実際は絵画には全然詳しくないのですが 親が好きだったもんで（大原美術館とか子供時代に連れて行ってもらったり） 「作品ってこのレベルだよな」とか知りもしないのに思っちゃったりします(^_^;;。 で、絵画って何かGIにも通じるフォトリアル感があるなぁと感じたと同時に、 作品としてひかれるものとしては「油絵＞3DCG（GI含む）」かな、私は。 作品レベルとしてはデジタル化でいくらリアルになったからといって、 歴史上の職人が造った作品はまだまだ超えられていないと感じてます。 音楽でもそうですが、デジタル・アナログ関係なく魅力的なものは 過去も現在も技術も関係ないもんですね（と思います）。 しかし、アイルワース版モナリザ画像をググってもないですねぇ。 結構衝撃的だったんで、ぜひ探し出したいものですが。 http://bluemoonnews.net/images5.htm の「Isleworth Mona Lisa」が拡大できるとわかりやすいのですが リンク切れだし。 絵からみてルーヴルのスタンダードなモナリザ（上）と、ラファエルのモナリザ模写（右下）と アイルワース版（左下）、と思いますが・・・。 なんか、美術館に行きたくなってきました。 4/9-7/18に横浜美術館にてルーヴル美術館展があるらしいので行ってみようかな。 !!イーグルマスク（2005/03/23） 花粉の季節です。雨の日が唯一のココロ休まるとき・・・。 で、例年に比べて10倍以上という驚異的なことに。 私は平年はあまり花粉症を意識するような重病患者ではないのですが・・・ 今年は勘弁して(T_T)。 ↓花粉グラフ http://www.sankyo.co.jp/healthcare/kahun/graph/22.html で、文明の利器に頼ろうということで、 生まれて初めてかもしれない「マスク」とやらを買ってみました。 「息苦しくない」というキャッチのあるやつですが・・・・ 電車の中で息苦しくなって途中下車・・・拘束系はダメだ。 ということで「上を向いて歩こう」が最近のトレンドです（鼻水出るんで）。 話変わってレンダラですが、高速化のための最適化を行ってます。 前処理の「頂点法線」の算出が結構重かったのですが、 見直して8秒近くかかっていたのを1秒程度に収まるようにしました（42000ポリゴンの シーン。Shadeのt_rex.shdです）。 その他、面光源・線光源の速度改善でShadeよりも速く品質も 追いつくレベルに。 前者は前処理の前処理（頂点別の共有ポリゴンを先にリスト化してしまう）と メモリ管理がキーです。後者は目で見て 明らかにはしょれる部分ははしょってしまおう、というのがキーワードとなります。 また日記でもネタにしますね。 そろそろやってみたいこととして「面光源・線光源のアニメーション」。 理論的にはちらつかないはずなのですが、実験で検証しなくては。 今のところ直接照明で止めているのでGIは棚においているのですが、 今後はGIでアニメーションなども実現範囲内になってくるでしょうね。 !!ノイズ除去（2005/03/21） 線光源の曲線上で光が均等に配分されるようにし、 2次元的なノイズ除去を行ってみました（ちょっとセコイか(^_^;;）。 後、多少速度アップで160secほど。 明らかに明るい部分などはまだはしょれそうですね。 Shadeはどうもまぶしい部分をスキップすることで最適化している箇所が 多いような気がします。 {{ref_image linelight_20050321.jpg}} こちらの生成するノイズはランダムでなくてパターン的ですので フィルタリングで消しやすそうです。 ただ、なんとなくですが「均等」だとノイズ除去するまでもなく ノイズが減りますね。 ランダムが入るとそれだけ目につきますので、均等にランダム（？）と できると目にやさしく低周波になりそうです。 !!面光源と線光源（2005/03/20） 花粉症で全体的にやばくなってきました。 連休なのに引きこもり中・・・・。 さて、Shade7では面光源だけではなく線光源も使えるようになっているのですが これをオリジナルレンダラでも実装してみました。 ・・・Shadeって面・線光源の処理、速くないですか(^_^;;？ 私のレンダラに比べて（単純なサンプリング）２倍以上は出ているんですけど・・。 しかもきれいだし。 Shadeの場合はノイズ除去処理をしているからか、品質もよいです。 これはShade6からShade7にかけての大きな違いかと。 {{ref_image llight_20050320.jpg}} オリジナルでは線光源時に等間隔に線を分割してないため、 均等に光が分散されてないですね。直さねば。 ちなみにShadeにこびを売っているわけじゃなく、純粋に技術的な評価を してみたいから、という理由でよいしょしてます(^_^;;。 しかし、Shade線光源はなぜかパストレーシングでしか 使えず、レイトレでは使用できません。 実は、面光源も線光源も理屈は点光源を拡張してサンプリングするもの でありますので、このときの最適化でわけあって 線光源をレイトレ対応しなかったのかもしれません（推測です）。 後、私のほうはトラバースの最適化も問題でしょうね。 まだまだ詰めるところはありそうです。 時間があれば、ですが次の日記ネタは面光源・線光源の最適化に フォーカスを置こうかな。 !!AIR 劇場版（2005/03/18） 本日で東京は最後の上映、ってことで急いで「AIR 劇場版」見に行きました。 最終日だし一般人は見に来ないから席も自由に選べるだろう、 とタカをくくってギリギリに行ったのですが、満員でした。 おかげさまで一番後ろで腕組みして仁王立ちで立ち見です（花粉症だったもんで、 常に前を見つつ、でちょうどよかったです(^_^;;。鼻をすすることもなく、 静かに見れました）。 隣でちらっとこちらを見ていた同胞の立ち見の貴方、それは私です（笑）。 にしても池袋のシネマサンシャインはなんであんなに複雑な構造なんだろう・・・。 評判がいまいちだったので期待せずにいったのですが・・・、 原作をプレイした自分からするとたしかに厳しい評価になりますね。 もしかしたら原作知らなければもっと話が分からなかったかも・・・。 まず、演出（カット割り、BGMのカットイン）がちょっとあってないのでは ないかな、と。違和感がありました。 神社の雨のシーンはもっと効果的に使ってほしかったです（っていうか、劇場であったっけ？）。 特に「ゴール・・・」は感動したい人にとってはアチャ〜です。 音の入りをはずしてないかなぁ。 昔話と現代のオーバーラップもちょっと無理矢理すぎないかと思いました。 というか、原作知らなければ過去編は現代とつながらないだろう、と(^_^;;。 後、止め絵が多かったのですが時間が足りなかったのかな。演出にしては 無駄に多い気が。 BSのアニメ版のAIRは好評価みたいですので（私はBS見れませんが）どうしても 対比してしまいますが、それにしても「劇場」の看板を期待していた 人からすると（ストーリーは知っていたにしても）ちと残念ですね。 夏の空気感もAIRのいいところだと思うのですが表現できてないし （祭りシーンも動きがないっす）。 とはいえ、100分の枠内だとたしかに表現が難しいでしょうけど。 この感じってハマってる（ハマった）人でないと分からないものがありますので （なんでこだわりがあるわけですが） 一概にゲームだから、とバカにはできないですよね。 よく考えれば、元「エロゲー」（ただし全年齢対象もあります）が 劇場版になって一般公開されるってすごいことだ・・(^_^;;。 !!確定申告（2005/03/14） げっ、明日3/15締め切りだった・・・（汗）。ということで急ピッチで作成。 税務署に直接出しにいくか・・・。 !!ラスタライズ系GI?をテストしてみた（2005/03/13） ちょっとやってみたかったんでやってみました。 明らかに間違いがあるのですが、以下の640x480 pixelで1.9秒（Athlon 1100MHz）。 オールソフトウェアです（拡散反射のみ）。 {{ref_image laster_20050313.jpg}} 視点移動だけするなら、リアルタイムでのレンダリングが可能です（640x480 pixelで0.05秒ほどでした）。 自己遮蔽なら前処理で計算する、頂点ごとのAmbient Occlusionがいいのかなぁ。 でも、オブジェクト固定はイヤだし・・・。 天空光を計算する部分（サンプリングする部分）が大部分を占めてますので（1.85秒ほど）、これをうまいこと ごまかすとリアルタイムでオブジェクトを動かしたりできそうですが・・・。 メガデモっぽいのをやりたかったのですが、技術的に追いつきませんでした(^_^;;。 私の環境ではGeForce4の旧世代なので、GPUを使ってというのは 難しいところ。 どちらにせよ、GIをリアルタイムにやろうと思うと「前処理がいる」「メモリを食う」 という可能性があるためこれを回避できれば面白いかなと思います。 ・・という息抜き実験をしました。 本当は、レイトレース手法でリアルタイムで動かしたいんですけどね(^_^;;。 私自身知識が何世代も遅れてますので、GPUの流れなど追いかけなければ。 実際、ゲームのリアルタイムレンダリング部とムービー部を 見比べても「はたして一般の方はどこまでリアルを求めるのか」と 思うことがあります。 別に反射・屈折は環境マップ（場合によっては二次以降をキューブマップで表す）、 間接照明はテクスチャに焼き付けでも問題ないのでは、というのが 一般的かもしれません。 そうすると、今のGPUで表現力は十分ではあるかもしれません（VRAM容量などは除く）。 そういうと、オフラインレンダラは元も子もないのですが(^_^;;。 後はレイトレースをいかに高速化するかを考えると、行き着くところまで行った、 となるのですが・・・まだ年月はかかりそうですし（というか不可能か、な）。 いろいろ模索してみようと思います。 ラスタライズでも、サンプリングが必要な処理は鬼門ですねぇ。 !!多角形を分解せよ(3)（2005/03/13） いろいろやること、やりたいことが多くて野ざらしになってました。 さて、三角形の分解のラストです。 {{ref_image tri_20050308_3.png}} ここから、0-1-2の三角形は削り落としたので、次は2-3-4をたどります。 これは、他頂点も内包されてないですし極端に平べったい三角形でもありませんので 三角形として成立します。これもカット。 {{ref_image tri_20050313.png}} 同様に4-5-6の三角形を調べます。これは面が逆転してますね（外積で判定です）。 なのでスキップします。4の頂点を飛ばします。 次、5-6-7の三角形。これも条件はOKです。カット。 {{ref_image tri_20050313_1.png}} この状態で残すは５角形ですね。 7-0-2の三角形もカットできます。 {{ref_image tri_20050313_2.png}} 次、2-4-5の三角形、ちょっと見にくくなったので色を黄色に変えました。 これもカットです。 {{ref_image tri_20050313_3.png}} そして、最後に三角形が１つ残りました（5-7-2の三角形）。 ここで処理を終了します。どんどんカットした三角形が分解された 残骸となるのが分かります。 うまいこと１ループして分解できればいいのですが、場合によっては 無限ループします。 その場合は不正と見なしてbreakしエラーを返します。 この状態は、調べている三角形内に他頂点が含まれる・平べったいポリゴンが 存在してにっちもさっちもいかない、などの状態です。 やたらと細長い面積の小さい三角形ができてしまったりするといけませんので、 １周させる間に大きなポリゴンが切り出せるようならそれを優先する、 などの最適化もできると思います。 外から中心に向かって渦巻き状に切り出している感じですね。 20角形とか多角形の角度が多くなると外周に小さなポリゴンができてしまう、などの 問題もありますが（こうなると頂点を増やして対応するほうがいいかも） 処理速度も軽く実装しやすいかと。 ちなみに、Shadeから得たポリゴンを三角形分解する場合は 「ポリゴンインデックスが異なるのに同じ頂点位置」「同じ頂点位置でありながら 微妙に（0.0001くらい）ずれている（自由曲面からポリゴンメッシュ変換時）」 など、そもそも妖しい多角形を作る場合があります。 表裏が変なのもあります。 ですので、その場合は前処理できっちりとした多角形になるように コンバートしてあげたほうがいいかもしれません。 ということで、この多角形分解はまた気が向いたらTipsとして格納しておきます （といいながら日記止まりのが多数・・・）。 !!ポリゴンの表と裏（2005/03/08） ちょうどShadeのフォーラムのほうでタイムリーな話題があったので、 かといって技術的なことをあの場で書いても意味がないのでここでメモっておきます。 （見ている人がいるかどうかは不明ではありますが(^_^;;。デベロップのフォーラムの 投稿がないので、こっちはROMってるだけ〜〜） ラジオシティーの面の表裏の問題ですが、レイトレーシングだと レイをたどってぶつかった面の法線とレイの作る角度により、もし角度が 90度以上（内積で求まります）なら法線を反転すればよい、というごく簡単な 解決策があります。 これならピクセル単位で常にレイに対して「表向き」のポリゴンが表現できます。 しかし、前処理の段階で表か裏か知りたい場合はどうすればいいでしょうか。 というか、ポリゴンモデリングだと表裏はきっちりと求めたいところです。 以下、私の考えた方法ですがオブジェクト単位で判別します。 結局はオブジェクトが外からみたらどのように見えているか、を推測すれば いいですのでそれを調べてます。 オブジェクトを囲むバウンディングボックスを求め、ちょうどキューブマップのように ６方向からオブジェクトを「ラスタライズで（Z値を考慮して）レンダリング」します。 キューブマップというよりも逆キューブマップですね。普通のＺバッファレンダリングx6です。 このとき、オブジェクトのポリゴン番号とZ値を保持します。ここで、面が裏を向いているから といってカリングしません。とりあえずすべてレンダリングです（透過は考慮しない）。 で、オブジェクトのポリゴンは頂点の並びによって表か裏かというのは（間違っているにせよ） あらかじめ判断できますので（これはポリゴン面法線で）、 個々の６方面のレンダリング結果で「ポリゴン番号に対する個々のピクセルで、ポリゴン法線としては表向きの場合はtrue/裏向きの場合はfalse」でピクセル数の累計を取っていきます。６方面全部のポリゴンごとのtrue/falseの累積を取ります。 もしもポリゴンごとにfalseが多い場合はその面は裏返っているかも、と推定できます。 確率的な推定ですね。この場合はポリゴンの頂点の並びを逆転させます。 これで大部分の面反転は修正できると妄想しています。 その他、「どっちが表やねん」って面や、オブジェクト内部の入り組んだ面は 上記では解決できません。 しかし、全球でオブジェクトを囲ってフォトン（とは言わないけど）を飛ばして判断もできますので、もうちょっと狭められるかな。 地面のような平面だと視点からみた場合でどう、という判断（もしくは光源からみたときの判断）という非常にあいまいな形しか取れませんので、表裏なんてあってないようなものです。 （ポリゴンだと時計方向と反対周りの頂点順、としっかりとルール付けされるのですけど このあたりのあいまいさが災いしてますね＜Shade） しかし、前処理で大部分の「ポリゴンの表裏」は解決できると思うのですが いかがでしょうか。 !!多角形を分解せよ(2)（2005/03/08） 続きです。2次元空間に投影されたポリゴンにて以下の８つの頂点があるとします。 反時計回りに頂点が振られています。 {{ref_image tri_20050308_0.png}} !多角形の表裏の判定 反時計回りに頂点が与えられたとき、スクリーンの手前に法線が伸びることになり、 このとき法線の向いている方向が「表」となります。 上図だと表を向いていることになります。 では、表を向いてるか裏を向いているかを調べるには？というと、外積を使います。 頂点0/1/2番をv0/v1/v2で表すとき、二次元のXY平面での表裏判定は、 float fDat = (v1.x - v0.x) * (v2.y - v1.y) - (v1.y - v0.y) * (v2.x - v1.x); で計算でき、 fDatが0より大きいとスクリーン方向に法線が出ることになり「表」と判定できます。 逆にfDatが0より小さい場合は面の向きは「裏」と判定できます。 ※だたし、多角形が同一平面上にあるとしたとき しかし、頂点1/2/3で判定するとこれだと裏になってしまいますね。 凹があるとどっちが表か裏か判断つきにくいです。 この場合は、頂点0/1/2の外積を求める、頂点1/2/3の外積を求める、 頂点2/3/4の外積を求める・・・頂点6/7/0の外積を求める、とそれぞれの ３頂点が作るベクトルにて判定を行います。 このうち、表が多いか裏が多いかを多数決を取るとよいです。 凹凸多角形だと凹部の方が多いことはありえませんので、仮に 裏の判定のほうが多い場合（上式のfDatが0より小さい角が多い場合）、 「多角形は裏を向いているのではないか」と推定できます。 その場合は、頂点の並びを逆転させて表を向くようにします （この処理が大事です！！）。 !三角形を削っていくべし！！ 次の段階です。きっちりとスクリーン方向を向いたであろう多角形の頂点があります。 このうち、頂点の先頭から三角形を抜き出します。 {{ref_image tri_20050308_1.png}} 三角形0-1-2は、上式の外積を使うと「表を向いている」ことが分かります。 ここでもう２つ判定を行います。以下の条件を満たしていることを確認しましょう。 *三角形内に他の頂点が内包されていないか 下図を見てください。三角形0-1-2が存在し、どこかしらの頂点A/Bがあります。 {{ref_image tri_20050308_2.png}} ここでまた外積を使います。頂点0/1/2をv0/v1/v2とし、頂点AをvAとします。 頂点v0-vA-v1の外積が正か負か、 頂点v1-vA-v2の外積が正か負か、 頂点v2-vA-v0の外積が正か負か、の判定を行います。 float fDat1 = (vA.x - v0.x) * (v1.y - vA.y) - (vA.y - v0.y) * (v1.x - vA.x); float fDat2 = (vA.x - v1.x) * (v2.y - vA.y) - (vA.y - v1.y) * (v2.x - vA.x); float fDat3 = (vA.x - v2.x) * (v0.y - vA.y) - (vA.y - v2.y) * (v0.x - vA.x); このfDat1/fDat2/fDat3がすべて正またはすべて負のとき、頂点Aは三角形に内包されている ことになります。 １つ目の条件は、対象となる三角形を構成する頂点以外を調べ「三角形内に他の頂点がない」 ことを確認します。 ちなみに、頂点AはfDat1が正で後は負ですので三角形の外にある、 頂点BはfDat1/fDat2/fDat3すべてが負ですので三角形の内にある、と判断できます。 *三角形の作る角度が極端に小さくないか 三角形の作る角度が小さい、つまり三角形がつぶれてしまってないか判定します。 いくつか方法がありますが、今回は２つの辺の傾きが同一でないかで判断します。 辺v0-v1と辺v1-v2の傾きを比較します。 fDat1 = (v0.y - v1.y); if(fabs(fDat1) > (1e-5)) fDat1 = (v0.x - v1.x) / fDat1; else fDat1 = 10000.0; fDat2 = (v2.y - v1.y); if(fabs(fDat2) > (1e-5)) fDat2 = (v2.x - v1.x) / fDat2; else fDat2 = 10000.0; fDat1 = fabs(fDat1 - fDat2); このとき、fDat1 > (1e-6)だと三角形として認めます。 おさらいすると、'''三角形が表を向いており'''、'''「三角形内に他の頂点が内包されていないか」''' '''「三角形の作る角度が極端に小さくはない」'''の２条件を満たした三角形を 多角形からばっさり切り離します。 これで、多角形は頂点が減って7頂点「0-2-3-4-5-6-7」で構成されることになります。 ここで切り取った三角形が、分割したときの三角形です。 {{ref_image tri_20050308_3.png}} これで薄々やり口が分かるかと思いますが、「三角形を削っていく」ことで多角形を分解していってます。 ここでとりあえず息継ぎとして次回に最後の解説いきますね。 !!Shadeをまねてみる（2005/03/07） レンダラのパラメータの挙動を調整して、Shadeとほぼ似たような画像を作るようにしてみました。以下、与えたパラメータ（マテリアル部）はまったく同じです。 {{ref_image shade_20050307.jpg}} スペキュラのパラメータがよく分からないので手探りで似せてみましたが、 やはりわずかに違いがありますね。 速度は上画像ではShadeが10秒、オリジナルが15秒でShadeのほうが速いです。 反射・屈折コンボにはまだ弱いか・・・・。 でも、なんとなくレイが二分するときの最適化はつかめそうです（反射だけ・屈折だけな シーンだとオリジナルが勝ってるんですけどねぇ・・・このへんは調整の余地ありです）。 ちょっとわかりにくいですが、Shadeでは反射・屈折する表面部でわずかに 白ノイズが出てますね。こちらのレンダラではいろいろ試行錯誤してノイズは 極力でないようにしたのですが、浮動小数点の微妙な誤差は鬼門ですねぇ（特にAthlon）。 しかし、レンダラを鍛えるのにShadeプラグインでチェックするのは結構有効なように 思います。 耐久テストやちょっとしたモデリングをかます実験にも使えますしね。 いろいろ間違っていた部分があったので合わせて修正してます。 （ただ、Shadeは方言のようなのがあるので一概にリファレンスになるか、は判断は できないですが・・・） 多角形分解の解説はしばらくお待ちください。三日坊主になる前に解説します(^_^;;。 !!多角形を分解せよ（2005/03/05） 突然なんですが、私はお茶（緑茶）好きでして お茶葉を蓄えているのですが、 長いこと飲んでいたお茶の賞味期限が半年前に過ぎていたことをさっき 知ってしまいました。知らずにずっと飲んでたよ・・そして今も飲んでるよ（汗）。 ちょっと薬っぽい味になってきたなぁとは思ってたのですが。 さて、ちょっとローテクなネタで。 レンダラでは、多頂点の（四角形以上の）ポリゴンを三角形にあらかじめ 分解しておいたほうが効率がよいです（交差判定で楽するため）。 ですので、内部的には三角形で持つ前にポリゴン分解を行います。 この分解方法について、しばらくは話題にしてみようかなと。 以下のような凹凸のあるポリゴンを分解するとします。 {{ref_image tri_20050305.png}} これを分解すると、以下のようになります（分解方法によっては別の分離形態もあり）。 {{ref_image tri_20050305_2.png}} 凹を含む多角形は処理が面倒になりますし、八角形の角だけ取れて 面積に偏りがある分解になってもいけませんので、 これを効率よく分解する方法を説明してみます。 多角形ポリゴンの分解前に、分解処理を行う場合は２Ｄ（XYの２軸の空間）で 行ったほうが効率がよいため、Y-Z平面/X-Z平面/X-Y平面のいずれかに投影してやります。 では、どの面に投影すればよいでしょうか？ これは、ポリゴンのはじめの３頂点を取り出してここでの法線を求めてやります（特に法線の向き（頂点順番によって反転しているか否か）に関してはこだわらなくてもいいです。投影のためだけのものですので）。 法線として(nx, ny, nz)成分が計算できたとすると、このうちnx/ny/nzの絶対値で 一番大きい軸方向に圧縮するとします。 「nx > ny, nz」ならY-Z平面に投影（X軸を圧縮）、 「ny > nx, nz」ならX-Z平面に圧縮（Y軸を圧縮）、 「nz > nx, ny」ならX-Y平面に圧縮（Z軸を圧縮）、 です。単純に２成分を取り出すだけです。 これで、後は２次元空間での問題となります。 ちょっと話が長くなるので、続きは次回。 !!レンダラ調整（2005/03/03） ピクセルシェーダみたいな「プログラムできる機能（というか、 コールバックでマテリアルのピクセルごとの挙動を調整できる）」をレンダラに追加して、 Shade7と比較してみました。 （こうしないと、Shade上のレンダラとしてチェックするには シームレスにいかないんですわ。表面材質情報・テクスチャ情報を 自分の世界（レンダラ）に持ってくるとリソース食いますしね） しかし、Shadeの表面材質の挙動が未だによく分からんです(^_^;;。 {{ref_image trans_20050303.png}} Shadeの場合は「表面材質」のインターフェースは ちょっと込み入っている部分があり、難しいです。 例えばステンドグラスの表現を行うにも、透過のテクスチャを新たに 貼り付けないといけないのですが、直感的に言うと「半透明のテクスチャ」１枚 あれば表現できる（デフューズのテクスチャだけ貼って透過にする）、と考えるかなぁと。 髪の毛の表現で抜いている作品も多いので（というか過去にやったぞ、ワシ(^_^;;）、 Shadeでもきれいに抜けるはずですが・・・マニュアル読むか・・・。 でも、透過時のレイの処理はShadeは速いですね。 総合すると、自作レンダラとしてはとんとんになってしまう。うまいことはしょらなくては。