頂点ベクトル・に

　オブジェクトの姿勢を変えると頂点ベクトルの計算が不正になる不具合があったので、修正。ポリをグローバルに変換する際にベクトルを変換してなかった。ということで、その処理が増えた分計算コストも増。せっかく減らした処理時間が……

**********
　株式会社インフィニットループのマスコットキャラクターのモデルデータ「あいえるたん3Dモデル」を使用しています。
　配布元：https://www.infiniteloop.co.jp/special/iltan/
**********





***





***





***

　椅子・コップ共に、右が読み込み時に頂点ベクトルを自動生成、左が頂点ベクトル無し(ポリゴンのベクトルを使用)。
　やはり頂点ベクトルがある方が全体的に綺麗に出る。

***

　今の所、ツリー構造でポリゴン等を管理して、各ノードで位置や姿勢を制御できる。
　レンダリング時は、ツリーをたどりながら、ポリゴンに出会ったときは視線ベクトルとの内積を取って合格すればキューに追加していく。すべてのノードをたどったら座標変換処理を終了する。
　続いてラスタライズ処理を開始する。すでに描画が必要ないポリゴンは除外されているので、キューに入ったポリゴンを総当りでラスタライズしてバッファに書き込んでいく。もちろんZバッファで書き込みの判定を行うが。

　実際の(DirectXとかの)レンダリングパイプラインでは、まずすべてのポリゴンをグローバルに持ってきて、その後でラスタライズの判定を行うらしい。たぶん影とか多機能なことをやろうとすると見えない面の情報も必要になるからじゃないかと思うんだが。
　不要なポリをローカル座標の時点で判定して省くと、結構処理速度に効いてくる。四元数の座標変換はSIMDで流しやすそうな構造だけど、System.Numerics.Quaternionってハードウェアアクセラレータ使ってるんだろうか？ Vectorは、使えるときは使う、みたいな感じに書いてあるけど、Quaternionには書いてない。

***

　調べてみると、SlimDXとかでGPGPUがサクッと動くっぽい。しかし、シェーダで動くプログラムは独立したCっぽい感じなので、C#の構造体とかを直接使うような処理はかけなさそう。そもそも、GPUを使いだしたら、「ならGPU(DirectX)でレンダリングしろよ」という話になってしまうのでなぁ。
　とはいえ、GPGPUは面白そうなネタなので、多少なりとも使えるようになっておけば便利そう。気分転換にちょっと遊んでみよう。

　しっかし、オープンソースライブラリ系、2015年前後で開発止まってるやつ多すぎ。。。いったいこの時期に何があったんだ…… 2005年頃にオープンソースバブル始まって15年頃に弾けた、って感じ？