右手座標系をサポートする

動機

なぜこれまで左手座標系だったのか？

キャラクターあるいはカメラを起点とした処理を考えやすいため。特にピクセルシェーダで ViewSpace 上の計算を行うときに Z+ が "進行方向" と一致するためイメージしやすかった。 ClipSpace に至っては OpenGL でも DirectX でも左手座標系であり、低レイヤーに近づくほど左手座標系の方が扱いやすい。

また Lumino の開発初期にリサーチできたゲームエンジンでは、左手座標系が採用されているものが多かった。（Unity, UE4 も左手）

これまではレンダリングエンジンの実装に力を入れていたため左手座標系の方が都合がよかったのだが、より高レベルの機能をサポートし始めたことで次のような問題が出てきた。

左手座標系の問題点

様々な DCC ツールで作成したアセットとの相性が悪いこと。特に3Dモデルは頂点データの他、ボーンやアニメーション等非常に多くのデータ構造を扱う必要がある。 DCC ツールのほとんどは右手座標系であるが、こういったアセットを正しくインポートするには常に座標系の変換に気を配る必要があり負担が大きい。

またこの変換のためのオーバーヘッドがどうしても乗ってくる。 Lumino が 3D をサポートし始めたころに対応した PMD,PMX は左手座標系であったため問題は少なかったが、その後 glTF を標準的に使用していくことに決めた。Lumino は独自形式を持たないためランタイムでは常にこの変換のオーバーヘッドが発生してしまうことになる。

左手座標系をやめることの問題点

シェーダを除いてほとんど無い。そのシェーダについても、この Issue を上げた時点の rh-proto ブランチでは既にすべてのユニットテストをパスしている。

X軸の意味が変わるが、実際にゲームでキャラクターの動きを作る際には Z(進行方向) と Y(上方向) をイメージしながら作ることが多く、X軸についてはそれらよりも明確な意図をもって使う機会は少ない。ZY の意味が変わらなければ、既に作られている Lumino のユーティリティへの被害も少ない。

面のカリング方向について

CCW を正面とする。（"右手" に統一する）

これは glTF・Vulkan の標準的な仕様なので、これに合わせてみる。他のライブラリだと imgui や nanovg がこれにあたる。

参考

https://note.com/it_ks/n/nb13311509f0a

imgui VK_FRONT_FACE_COUNTER_CLOCKWISE

vulkan VK_FRONT_FACE_COUNTER_CLOCKWISE

Three.js CW? https://github.com/KhronosGroup/glTF-Blender-IO/issues/551

glTF CCW

godot PipelineRasterizationState の初期値を見ると CW

LuminoEngine / Lumino