2020年2月19日水曜日

塗りつぶし

 forリミットのアルゴリズムを変えて、かなり早くなった。





 従来方式と同程度の速度にはなった。そう考えるとさほど高速でもないか。。。
 今は各所で浮動小数点演算を行っているので、整数化したら多少は早くなるかな。あとはifの場所を変えるとか。

 塗りつぶし指示の入力形式は、3頂点の反時計回り、という固定フォーマットなので、頂点1が上になるように前処理を行えば、頂点2が頂点3より左側に来ることが確定する。あとは、頂点1のYからforを回して、頂点2.Yと頂点3.Yのどちらか大きい方を超えた段階でループを打ち切る。X方向は、頂点の配置に応じて、各頂点のXを線形補間している。
 Y1行毎にXの補完が2回、値の補完がY毎に2回、X毎に1回あるので、線形補間の高速アルゴリズムがあれば、かなり早くなる気がする。ポリゴン1個の大きさが最大で256未満、みたいな仮定をすれば、加減とテーブル参照で行ける。いろいろ方法はありそう。深度はダイナミックレンジが広いので、テーブル参照は現実的じゃないか。深度が一番回数多いので、こいつを早くできれば効くんだけどなぁ。
 3DCGでZを0-1に正規化したりするの、そのあたりが関係してるのかも。スクリーン座標に変換した段階でfloatで並ぶんだから、そのまま使えばいいだろうに、わざわざ一番奥を探して正規化するんだから、なにか利点があるはず。

 今回は平面にスカラ(Z値)を貼り付けるために補間してるけど、ベクトルの補間ができれば、法線ベクトルを補間できるようになる。陰影の計算を高精度にできるようになるので、ポリゴン数を減らしても陰影の品質が悪化しない。ポリゴンの法線ベクトルの視線との内積がゼロ付近の部分の描画品質は悪化するけど。
 グラフィック処理、スカラやベクトルの線形補間を多用しがちな感じだし、ハードウェアで大量に並べて並列処理できるようになってるんだろうな。それともプログラマブルに演算できるんだろうか? 線形補間専用の回路のほうが低コストだろうけど、汎用性を考えれば通常の浮動小数点演算で計算したほうが、トータルではメリットが大きいかな。
 ベクトルの並列演算ができるハードウェアがあるなら、そりゃシミュレーションとかにもGPU使おうぜ、って話になるよなぁ。あるいは、機械学習とかにも。

***

 せっかくなので、ちゃんとした3Dも表示してみたいな、と思い始めて、素材をダウンロードして読み込んでみた。
 海外のサイトのフリー素材だけど、ライセンスが謎いんだよなぁ。あとファイルフォーマットも謎い。すごくふしぎなふぉーまっと(SF: Sugoku husigina Format)。

 当初の構想からはどんどん脱線していってるけど、まぁ、暇つぶしの遊びでやってるだけなので、これでいいのだ。

***
追記
 ファイルフォーマットは、なんとなくわかった。べつに、すごくふしぎではなかった。Wikipedia読んだらちゃんと書いてあった。
 ちゃんとしたモデルを描画しようとすると大変。レンダリングエンジンにGUIが結合されてるのが特に面倒。このあたりの分離とかの勘所がよくわからないからなぁ。これを気にちゃんと作り込みたい。と、毎回思うわけだが。。。
 まずは機能追加でなくリファクタリングかなぁ。

0 件のコメント:

コメントを投稿