問題タブ [frustum]

三次元空間での錐台の境界点の計算方法を次々と描きました。まず、カメラのxyz座標と、x、y、z軸を中心とした回転の3つの値をそれぞれ含む2つのデータセットがあります。特定のビュー距離が与えられると、6つの平面のそれぞれの境界点を計算できるはずです。私はこれらの方程式を使用して、遠方平面の幅と高さを計算しています。

hfarは遠方平面の高さ、wfarは幅、ratioはビューポートの幅を高さで割った比率です。私はそれを理解するために次の図を使用しています：

（？、？、？）で注釈が付けられたポイントを見つける必要があります。私は数日間これらの値を計算しようとしていますが、役に立ちません。どんな助けでもいただければ幸いです。

また、トピックに関する情報を提供するいくつかの素晴らしい情報源は、こことここにあります。

編集：私がホイップした別の画像は、x軸を見下ろすy軸を通る単一のスライスを示しています。上の画像と同じ情報が表示されますが、私の問題も示されています。遠方平面の各境界点の適切なz軸値を計算できません。

同じプロセスを示すために、x軸を介して同じカットを作成できますが、プレーヤーが上または下を向いている角度を使用することに注意してください。

錐台カリングに関するこの記事を読んでいますが、その背後にあるベクトル計算を理解するのに助けが必要です。より具体的には、彼が話している「上」と「右」のベクトルは何ですか? 彼らはどのような価値を持っていますか？簡潔で刺激のない質問で申し訳ありませんが、私は本当にこれにこだわっています。どんな助けでも大歓迎です！ありがとう

射影行列にモデルビュー行列を掛けた結果である列メジャー（opengl）行列がある場合。その行列の中心点を計算するにはどうすればよいですか？私が尋ねる理由は、結果のマトリックスにしかアクセスできず、ビューの中心の位置を見つける必要があるためです。

ありがとうございました。

少なくとも、Lighthouse3D Radar Frustum Culling チュートリアルの非常に単純な パート 1 を機能させようとしています...そして、その部分を自分のレンダラーで機能させることさえできないことに完全に困惑しています。

したがって、最初のステップは次のとおりです。ポイントがニアプレーンの前にあるかファープレーンの後ろにあるかをテストし、そうであれば早期カリングします。（そうでない場合は、さらにテストを実行しますが、最初の部分だけで行き詰まっています。）

2x2 の立方体のワールド空間の中心 (x1y2z3) を使用し、自由に移動および回転できるカメラを持っています。レンダラーはそれ以外の場合は問題なく動作するため、すべてのベクターとマトリックスのものはかなりしっかりしている必要があります。したがって、この最初の部分である単純な「Z vs Near-or-far」テストの (Go での) 私の見解は次のとおりです。

では、なぜ ref の Z を逆にするのでしょうか? チュートリアルでは、彼らは次のように書いているからです。もちろんこれは逆効果ですが…

上記のように Z を反転すると、約 50% の確率で必要以上にカリングされます。そうしないと、約 98% の確率で「過剰選別」されます。

何が欠けていますか？

私はタイル化されたレンダラーを機能させようとしていました (アイデアは、1 つの大きなビュー錐台をチャンクに分割して個別にレンダリングすることによってレンダリングすることです)。

私は、視野角を持つ標準的な透視投影を、glFrustum に渡すことができる左、右、上、および下のクリッピング プレーンに変換するコードを用意しました。

私はこれを適切に分解することに行き詰まりました。

画面に対するユーザーの位置を追跡し、レンダリングされたシーンをユーザーの視点に合わせて更新する OpenGL c++ アプリケーションを作成しています。これは「デスクトップ VR」と呼ばれ、画面をジオラマや水槽と考えることができます。私は OpenGL の初心者で、これまで非常に単純なシーン (立方体のみ) しか定義しておらず、最初は正しくレンダリングされていました。

問題は、移動を開始して立方体シーンを再レンダリングしたいときに、投影面が変換されたように見え、本来あるべき姿が見えないことです。この飛行機を直してほしい。レイ トレーサーを書いている場合、ウィンドウは常に固定されますが、目はさまよいます。カメラ/目を非原点座標でさまよいながら、希望する効果(表示ウィンドウを固定する)を実現する方法を誰かに説明してもらえますか?

私が見つけたすべての例は、カメラ/目が原点にあることを要求していますが、これは私にとって概念的に便利ではありません。また、これは「水槽」であるため、d_near を z = 0 の xy 平面に設定しています。

画面/ワールド空間では、画面の中心を (0,0,0) に割り当て、その 4 つのコーナーを次のように割り当てます: TL(-44.25, 25, 0) TR( 44.25, 25, 0) BR( 44.25,-25 , 0) BL(-44.25,-25, 0) これらの値は、16x9 ディスプレイの場合の cm 単位です。

次に、POSIT を使用してユーザーの目 (実際には私の顔の Web カメラ) を計算し、通常は (+/-40、+/-40、40-250) の範囲のどこかにあるようにします。私の POSIT メソッドは正確です。

パースペクティブ用に独自のマトリックスを定義し、変換を表示し、シェーダーを使用しています。

次のように初期化します。

Web で調べたところ、view_dir 以降は修正されたままです。これは、d_near と d_far だけでなく、d_x、d_y、d_y を更新するだけでよいことを意味します。私は glutIdleFunc( idle ); でこれを行います。

ここに私のシェーダーコードがあります:

OK、コードにいくつかの変更を加えましたが、成功しませんでした。頂点シェーダーで MV の代わりに V を使用すると、すべてが思いどおりに見え、遠近法は正しく、オブジェクトは適切なサイズになりますが、シーンはカメラの変位によって変換されます。

C と V を使用して MV を取得すると、シーンはオブザーバーの視点からまっすぐにレンダリングされ、レンダリングされたシーンはウィンドウを埋めますが、目/カメラの視点は失われます。

本当に、私が望むのは、オブジェクトの中心 (xy 中心が (0,0) である) をレンダリング イメージの中心。教科書「Interactive Computer Graphics: A Top-Down Approach with Shader-Based OpenGL (6th Edition)」の例を参考にしています。Web で無料で入手できる本とペアになっているファイルを使用して、行優先のアプローチを続けています。

以下の画像は、マトリックスCを使用してMVを作成しない場合に撮影されます。C を使用して MV を作成すると、すべてのシーンが下の最初の画像のようになります。z を平行移動させたくないので、0 のままにします。

投影面と私のカメラ面は平行なので、一方の座標系から他方の座標系への変換は単純な変換と inv(T) ~ -T です。

これが（0,0,50）での目の画像です：

(56,-16,50) での目の画像は次のとおりです。