固定機能3Dパイプライン向けのbaseline C APIを考える会
okuoku(none)
okuoku目的
各種3D APIにエディタを移植する上でプラットフォームになるものが欲しい。
必要性
いわゆるシェーダ世代向けのAPIは割と色々ある。
ただ、これらのAPIは当然シェーダを別にビルドして用意しないと機能しないので取り回しが悪い。このため固定機能に特化したAPIを設計して、シェーダ世代GPU向けにはwrapperを載せる方向にしたい。wrapperは事前にビルドすることができるので、アプリケーションのビルド環境にシェーダのビルド環境を組み合わせる必要がない。
okuokuデザイン
デザインの方向性として以下を置く。
- WebGLを踏襲する 。つまり、メインループをアプリケーションに書かせず、描画コマンドのkickを終えたら暗黙のうちにflipして出力する。
-
整数座標系をサポートする 。いわゆる固定小数点ハード(に見えるソフトウェア実装)をサポートする。浮動小数点は実装によっては再現性に欠けるため。逆にfloat系は後で用意する。float限定にする。再現性が欲しいならfloat処理全体をFPUエミュレータで動かせば十分だし。。 -
Quadやtri-stripのようなレガシプリミティブをサポートする 。ソフトウェアエミュレーションが容易なのと、現代的なindex描画をこれらに変換するのは地味に面倒なため。UI用の2DスプライトAPIは分離して、合成表示できるようにする方が良さそう。 → https://zenn.dev/okuoku/scraps/b454a6e262e95a - ポイントおよびラインは1pxのみで、ポイントスプライトをサポートしない 。GLES1的にこれらは必須でないため。
- Zバッファ必須 。
Zバッファなしのハードウェアまで想定するのはちょっと難しいのでナシ。99%のユースケースではZバッファは必要なはず。
okuoku参考 / ターゲットアーキテクチャ
NDS
NDSはゲーム特化なため今回のAPIのターゲットではない -- 特に、4096プリミティブ制限があるため汎用アプリは実行できない -- が、おそらく史上最後のフレームバッファを持たない3Dエンジンデザインで、フレームバッファの抽象化のデザインの参考になる。
NDSの描画アーキテクチャは、例えば NDSのラスタライザはねじれたQuadの描画が独特 なあたりに表われる。
The renderer is only able to fill one span per scanline. It determines the left and right edges starting at the topmost vertices, and follows those edges until it meets new vertices.
ソフトウェアラスタライザを実装するときに、これらを事前に禁止しておけば実装の手抜きが可能になる。
TinyGLES
(QEMU等で著名な)BellardのTinyGLにGLES APIを載せたもの。TinyGLとNDSがZバッファをサポートしているのでZバッファを採用することにした。
Zバッファを採用するということは、座標変換を隠蔽したアーキテクチャを採用することが必須になる(ラスタライザにZ値を与える必要がある)。APIのユーザ側に座標変換をやらせるアーキテクチャを取れないため、APIの規模は相応に増大する。
CSS3D
... 要る？