三角形の塗りつぶし

　の、アルゴリズムを、考えてる。

　適当に乱数で三角形を作って走らせながら考えてる。



　とりあえず、16, 20, 52, 63, あたりは正常に描画できてる気がする。歩留まりとしちゃかなり悪いけど、傾向はおおよそ見えてるし、なんとかなりそう。おおよそどんなアルゴリズムで処理すればいいかはわかった気がする。

　想定としては、Zバッファの処理を先に実装しよう、と思っていたんだけど、気がついたら塗りつぶし領域の判定も動いてる件。そりゃぁ、Zバッファの値を書き込むか否かの判定をやってるんだから、そのまま色を塗るか否かの判定にも使えるわけで。
　それに、Zバッファの補完を目的に処理していたはずなのに、気がついたら頂点カラーの機能が実装されている気がする。もっとも、Zは1次元だけど、頂点カラーは3次元なので、そのまま使い回すことはできないが。C++ならテンプレートとかでゴリ押しできそうだけど、C#のテンプレートはそのあたりが弱いからなぁ。
　頂点カラーだけじゃなくて、テクスチャのマッピングとか、様々な機能が、似たようなアルゴリズムで処理できそうな感じ。さすがに頂点カラーやUVマッピングまで手を出すと、低ポリの3Dデータを作るだけでも大変なので、当分やる予定はないけど(←大昔にフリーのラジコンシミュレータ用データを作ろうとして挫折したの引きずってる
　しかし、フリーの低ポリなデータを探してきて、試しにレンダリングしてみたい気はするな。Zが扱えるようになって、UVやテクセルの貼り付けができるようになれば、あとはデータの読み込みが大変、くらいか。速度とか、ボーンとか、そのあたりを無視すれば、できそうな気はする。
　例えば、テクスチャを256x256pxに制限すれば、RGBの3chに対して、テクスチャID、テクセルX軸、テクセルY軸を割り当てて、グローバル空間からスクリーン空間にレンダリングして、レンダリング結果のID/X/Yでテーブルからテクセルを拾ってきて置き換えてやれば、テクスチャの貼り付けはできそうな気がする。テクスチャが16枚以下なら1024x1024pxまでアドレッシングできるし、8bit3chでなく、32bit1chとかに割り付ければ、8192x8192を64枚分、みたいなアドレッシングもできる。たぶん、動きそうな気がする。
　まぁ、相変わらず、「GPUでやれ」って処理なことに違いはないが。


　Ironパレットの三角形を黒背景に適当に散らばらせた画像、結構綺麗だな。変な金属の標本みたい。ビスマスとか。あれは矩形だけど。スクリーンセーバーとかにしたら楽しそう。フェードアウトの処理が計算負荷高そうだけど。