web-dev-qa-db-ja.com

glm :: ortho（）は実際に間違っていますか？

最近、行列演算や固定関数パイプラインなど、OpenGLが提供する古い（非推奨の）機能から切り替えるのは良い考えだと思いました。

少し単純化するために、マトリックスライブラリとしてGLMを使用しています。問題は、単純化したよりも多くの問題を引き起こした可能性があることです...

パースペクティブプロジェクションはシェーダーとセットアップで正常に機能しましたが、直交に切り替えようとすると、すべてが機能しなくなりました。私のポイントと単純なクワッドは表示されませんでした。古いOpenGLマトリックスを使用すると、物事は再び機能し始めました。

私はそれをすべて射影行列に絞り込みました。これが私がそれを呼んだ方法です：

glm::mat4 projMat = glm::ortho( 0, 400, 0, 400, -1, 1 );

これが呼び出されたら、openglによって提供されるものと比較しました」

glOrtho( 0, 400, 0, 400, -1, 1 );

唯一の違いは、[0] [0]要素と[1] [1]要素です（私が知る限り、これらはそれぞれ「2 /幅」と「2 /高さ」に等しい）。 OpenGLマトリックスから、値はまさにそれでした！ただし、glmマトリックスでは、値は0でした。

Glm :: orthoを呼び出した後、glmマトリックスから値を手動で切り替えると、すべてが再び機能していました。

だから私の質問：glm :: ortho（）関数は本当に壊れていますか、それとも私はそれを間違って使用していますか？

c++openglorthogonalglm-math
16
Jamie Syme

ソースコード（v 0.9.3.4）から切り離されるべきではないようです

_template <typename valType> 
GLM_FUNC_QUALIFIER detail::tmat4x4<valType> ortho
(
    valType const & left, 
    valType const & right, 
    valType const & bottom, 
    valType const & top, 
    valType const & zNear, 
    valType const & zFar
)
{
    detail::tmat4x4<valType> Result(1);
    Result[0][0] = valType(2) / (right - left);
    Result[1][1] = valType(2) / (top - bottom);
    Result[2][2] = - valType(2) / (zFar - zNear);
    Result[3][0] = - (right + left) / (right - left);
    Result[3][1] = - (top + bottom) / (top - bottom);
    Result[3][2] = - (zFar + zNear) / (zFar - zNear);
    return Result;
}
_

私の唯一の考えは、このテンプレートが整数の行列を作成している可能性があることです（すべての整数を関数に渡したため）。したがって、浮動小数点の代わりに整数除算を実行します。すべてのパラメーターに_.f_を追加してみてください。

glm::mat4 projMat = glm::ortho( 0.f, 400.f, 0.f, 400.f, -1.f, 1.f );

46
Tim