Kamerafrustumplanes berechnen

[Niki]

Bist du eine der genannten Personen?

Klaus Hartmann. Niki ist mein Spitzname.

[Alexander Kornrumpf]

Wie cool. Irgendwann in der Steinzeit vor dem Studium und bevor ich wusste was eine Ebenengleichung ist, hab ich auch mal versucht das Paper zu implementieren. Oh the memories :)

[Niki]

@Schrompf, da du ja eh immer alles mitliest... hast du die Möglichkeit das Tutorial zu korrigieren? Zerbie habe ich erst einmal gesehen seit ich wieder hier bin.

Code: Alles auswählen

   // Nahe Clipping Plane
    VFrustrum[VF_N].vNormal.x = -matViewProj._13;
    VFrustrum[VF_N].vNormal.y = -matViewProj._23;
    VFrustrum[VF_N].vNormal.z = -matViewProj._33;
    VFrustrum[VF_N].fDistanz  = -matViewProj._43;

[Alexander Kornrumpf]

Im Zweifel mal den Seraph anschreiben.

[Andre]

Ich habs jetzt soweit hinbekommen, dass das Frustum richtig aussieht (Habs doch gezeichnet bekommen, dank dem BoundingFrustum-Interface aus DirectXCollision), aber die Farplane viel zu nah dran ist. Und obwohl der Check aus ist wird immernoch das meißte nicht gezeichnet.

Edit: Ah, es ist im moment so, dass die Nearplane viel zu nah an der Kamera ist und die Farplane genau auf der Nearplane liegt.

[Niki]

Glückwunsch! Hast du jetzt also die Extraction weggeworfen, oder habe ich das falsch verstanden? Ich benutze die momentan auch nicht, da ich gerne die 8 Eckpunkte des Frustums zur Verfügung habe. Geht natürlich auch mit Ebenen schneiden, aber muss ja nicht. Auf Extraction gehe ich erst zurück falls ich Culling im Object Space haben will.

[Andre]

Ich habe den Code von hier mal getestet: http://social.msdn.microsoft.com/Forums ... c450646833
Und der gibt mir auch ein gutes Frustum aus, bis auf das was ich eben noch in meinem Post über dir reineditiert habe... aber das sollte ja eigentlich egal sein, da ich die checks mit Planes mache. Naja, bestimmt reichts aus die Normalen zu invertieren wenn ich so drüber nachdenke.

[Andre]

So, Normalen invertieren, UND WorldPos der Objekte auch berücksichtigen habens jetzt gebracht. :roll:

Funktioniert, bis auf, dass die Near- und Farplanes nicht richtig sind, aber das ist in meinem Fall egal. :)

[dot]

Bringen wir mal ein wenig Ordnung in die Sache. Wofür genau das Transponieren? Betrachtest du Vektoren als Zeilen oder als Spalten? Wegen der Plane Extraction schau mal hier: http://www.cs.otago.ac.nz/postgrads/ale ... action.pdf, Handedness sollte da imo keine Rolle spielen.
Wenn du nur die Eckpunkte des Frustum brauchst, kannst du auch einfach die Ecken des Frustum in Normalized Device Coords (also die Punkte (-1, -1, -1) etc.) durch die inverse ViewProjection schicken.

[Niki]

Wenn das erwünscht ist, dann kann ich das PDF heute Abend auch mal ganz offiziell in der Rubrik "Artikel, Tutorials und Materialen" als Dateianhang hochladen. Ich weiß aber nicht, ob diese Dateianhänge eine begrenzte Lebensdauer haben.

[Artificial Mind]

Bringen wir mal ein wenig Ordnung in die Sache. Wofür genau das Transponieren? Betrachtest du Vektoren als Zeilen oder als Spalten? Wegen der Plane Extraction schau mal hier: http://www.cs.otago.ac.nz/postgrads/ale ... action.pdf, Handedness sollte da imo keine Rolle spielen.
Wenn du nur die Eckpunkte des Frustum brauchst, kannst du auch einfach die Ecken des Frustum in Normalized Device Coords (also die Punkte (-1, -1, -1) etc.) durch die inverse ViewProjection schicken.

Nur mal so als kleiner Tipp am Rande fürs Implementieren: Niemals die inverse ViewProjection nutzen.
Die wird schon bei Koordinaten im dreistelligen Bereich instabil.
Lieber folgenden Pseudocode nutzen:

Code: Alles auswählen

vec4 screenPos = ...;
vec4 eyePos = inverseProjection * screenPos;
eyePos /= eyePos.w;
vec4 worldPos = inverseView * eyePos;

Das ist wesentlich stabiler (am eigenen Leib erlebt) ;)

[Andre]

Bringen wir mal ein wenig Ordnung in die Sache. Wofür genau das Transponieren?

Das kommt noch von den Anfangszeiten dieses Projektes, wo ich noch nicht genau verstanden hatte was das Transponieren überhaupt macht. Das Transponieren soll die Matrizen anscheinend GPU-Freundlicher machen, auf jeden Fall ging es ohne nicht und ich wusste zu der Zeit auch nicht genau wieso, da ich auf ein wenig Samplecode aufgebaut habe.
Also hab ich einfach jede Matrix direkt nach dem erstellen Transponiert, also World-, View-, und Projection, da ich auf der CPU Seite noch nicht groß damit rechnen musste.

Jetzt bin ich aber um einiges Schlauer und weiß, dass es sehr viel günstiger und übersichtlicher ist dies nur beim eingeben in die Shader zu machen.

Und danke für den Tipp mit der invViewProj, ich werds mir merken!

[dot]

Das Transponieren ist nur notwendig, da die D3DX Matritzen nicht mit dem standardmäßig von HLSL angenommenen Speicherlayout übereinstimmen. Sofern du dich an die von D3DX vorgegebenen Konventionen hältst (Vektoren sind Zeilen, mathematisch gesehen zwar Schwachsinn, aber so ist es nunmal in D3DX), gibt es keinen mathematischen Grund dafür und der einzige richtige Zeitpunkt dafür ist, vor der Übergabe an den Shader. Mit den transponierten Matritzen auch nur irgendwas zu rechnen wäre schlichtweg falsch.

(Zumindest im Allgemeinen, natürlich kann man unter Umständen Dinge so umformulieren, dass man direkt mit transponierten Werten rechnen kann und das transponierte Ergebnis erhält, sodass man sich evtl. ein paar Mal unnötiges Transponieren spart, aber dann könnte man auch gleich eine anständige Mathelibrary verwenden und sich derartige Kunststücke von vorn herein ganz sparen...)

[Andre]

Ich benutze allerdings DirectXMath. Bei D3DX mit Direct3D11 war Transpornieren auch nicht notwendig.

[dot]

Transponieren ist nur notwendig, wenn das Speicherlayout der Matritzen auf CPU Seite nicht mit dem von den Shadern erwarteten Layout übereinstimmt. Das Layout lässt sich z.B. beim HLSL Compiler global über Flags und auch im Code über Keywords steuern, Stichwort column_major vs row_major...

[Andre]

Jop, das weiß ich jetzt auch :)