Rendering
WMMDのレンダリング：ゴールデン画像で検証するトゥーンパイプライン
WBOIT透過、ESMシャドウ、SSAOとRT AO、IBLとブルームを備えた前方トゥーンシェーディングと、それを誠実に保つヘッドレススナップショット基盤。
MMDエンジンにおけるレンダラーの仕事は、少し変わっています。みんながすでに知っている見た目に合う様式化されたトゥーン出力を出しながら、コンサートのステージやARシーンに放り込まれても耐えるだけの現代的なライティングを持たないといけません。
トゥーン側を外すとMMDに見えなくなります。ライティング側を外すと、面白い場所に組み込めなくなります。
WMMDはこれをwgpu上で、GPUについて何も知らないレンダリングインターフェースの背後でやっています。
パス
wmmd-render-wgpuがGPU側のすべてを所有します。
- 前方トゥーンパス
- 重み付きブレンドによる順序非依存透過（WBOIT）
- スクリーンスペースAO。
ray-queryフィーチャの背後にレイトレースAOの経路も用意 - イメージベースドライティング
- ソフトシャドウのための指数シャドウマップ
- ブルーム
ONNXによるテクスチャアップスケールの経路も専用フィーチャの背後にありますが、依存が重いので既定では無効です。
もう1つのバックエンドが sylveon です。エディタに既定で組み込まれるEEVEE風のレンダラーで、より映像寄りの仕事を担います。オートフォーカス付き被写界深度と、既定では無効のMcGuire方式タイルベースモーションブラー。専用のGPUプロファイラを持っていて、パスごとのタイミングをJSON Linesとして追記し、後から解析できます。
難しいのは髪
MMDのコンテンツで厄介なのは透過で、その中でも髪が一番です。
髪は、アルファブレンドされたマテリアル、深度書き込み、アンビエントオクルージョンのちょうど交点にあります。間違えるとすぐ分かります。背後のものを遮蔽しない髪、あるいはAO構造から丸ごと消えてしまう髪。
どちらも実際に踏んで、追跡して直した不具合です。髪の形状はレイプロキシ構造に参加するようになり、髪の深度キーが、順序の誤ったフラグメントを弾く合成ステップを駆動します。
ホスト側の2パスループ
レンダラーがスワップチェーンを所有しないので、エディタのフレームは明示的です。
- シーンをエンコーダに描く
- シーンを保持するロード操作で、同じエンコーダにeguiパネルを描く
- サブミットする
- 提示する
パネルはレンダラーとは完全に別のクレートにあります。そのおかげで、UIを一切持たないホスト、たとえば書き出しジョブやARサーフェスが、同じ描画経路を駆動できます。
ゴールデン画像が自分を誠実に保つ
上の全部を保守可能にしているのがこの部分です。WMMDはヘッドレスでPNGへ描画し、ゴールデン画像と比較します。スナップショットランナーはツールクレートにあります。
様式化されたレンダラーには解析的な正解がありません。「このフレームは正しい」と言ってくれる式は存在しません。だから基準は以前に承認したフレームで、ピクセルを変える変更は自分を正当化しないといけません。
実際、シャドウの忠実度、マテリアルとスペキュラの挙動、被写界深度の作り直しは、この方法で評価してきました。同じシーンと同じ画角で前後を描画し、意見ではなく較正済みの基準と比べます。
出荷するコードのどこにも特定のモデル名を書かない、という規則の理由もここです。スナップショットは再現ケースであって、目標ではありません。修正は任意のPMX/VMD入力に対して成り立つ必要があり、テストもそう書かれていないといけません。