C-WebGL: 自前のTrackerでUnityの絵出しを目指す
okuoku本業が多忙で死んだ目をしながらtrackerとGLES2バックエンドの繋ぎ込みをすることしかできなかった。。
とりあえず繋ぎ込みが終わったので、Unityの絵が出る程度にTrackerを完成させる。
WebGLの実装はTrackerとRendererに分割してやっている。TrackerがWebGLのAPIの殆どを実装し、Rendererは drawElements のような実際に描画を行ったりシェーダをコンパイルするなどGPU依存の必要最低限の部分だけ実装すれば済むようにしたい。
今のところ Renderer はOpenGL ES2をそのまま使っている が、それでも割とコンパクトにUnity WebGLがレンダリングできる程度の機能性を実装できている。と思う。。
okuoku
detachShader はlink後のprogramの機能には影響しない
... マジで。。？
detachShader のタイミングで頂点バッファのバインディングを解放していたのを linkProgram の段階に移動。 ...たぶん linkProgram が失敗した場合は復旧しないといけないからもうちょっと真剣に考えないといけないかもしれない。 EDIT: この対処も間違っていて、結局解放自体やめた。(see below)
GLES2仕様曰く:
While a valid program object is in use, applications are free to modify attached shader objects, compile attached shader objects, attach additional shader objects, and detach shader objects. These operations do not affect the link status or executable code of the program object.
okuokuUnityちゃん大爆発
いやこれマジ何が起きてるの。。？RenderDocで頂点を見ると、球状に纏まっていることがわかる。
おそらく頂点属性を正常にbindできておらず、法線のようなノーマライズされた別の配列を見てしまっているんではないだろうか。。
okuokuバインドする頂点配列が間違っている
しょうがないのでPowerVRのOpenGLESエミュレータでもトレースを掛けてみて、結果バインドされた offset 値が間違っていることがわかった。。
| 属性 | 正解 | まちがい |
|---|---|---|
in_POSITION0 |
0 | 12 |
in_NORMAL0 |
12 | 0 |
in_TEXCOORD0 |
40 | 40 |
PositionとNormalが入れかわっている。法線も通常ノーマライズされるので絶対値が1付近、つまり球面上を指す座標になる。
... 直前の修正で linkProgram 時にbindingを解消してしまった ので頂点配列のbindが失われているのが原因だな。。
このクリアを止めてみるとちゃんと描画された。
(Unityちゃんの出。最初の描画は地面の描画なのでUnityちゃんの上に地面が上書きされる。)
okuoku
bindFramebuffer は即時効果がある
いわゆるrender-to-textureがうまく動作していなかった。 bindFramebuffer 時にバックエンドの再設定を忘れていたので追加。
ここまででとりあえずUnityも出画するようになった。 ...まぁ描画バックエンドはGLES2のままなんで動いてあたりまえだけど。。このままVulkanへの移植に移る。