Wenn man mal im Netz nach Frustum Culling sucht, wird einem immer gesagt, man solle anhand der Normalen der Frustumflächen überprüfen, ob ein Punkt im Frustum ist oder nicht. Inzwischen ist mir das Prinzip auch klar geworden, nur damals (vor 3 Monaten) habe ich es nicht begriffen und dafür eine andere Lösung gefunden. Die ist IMHO leichter zu verstehen und braucht, wenn ich jetzt keinen Denkfehler mache auch weniger Berechnungnen => schneller. Meine Frage ist:

Wieso nutzen alle die Methode mit den Normalen? Was gibt es da für Vorteile und Nachteile?

Meine Methode scheint ja zumindestens zu funktionieren, ich hab mal ein Beispielprogramm angehängt.
(Achja, wenn sich jemand wundert, warum der Code dem aus dem SDL-Template ähnelt , das kommt davon, wenn man mit einem Auge Tutorials liest und mit dem anderen im Quellcode bastelt. Danke Phobeus, es gibt nun einen SDLer mehr auf dieser Welt )

Meine Frustumüberprüfung funkioniert so:

1. müssen Informationen über das Frustum gespeichert werden (ich hab mir eine Procedure geschrieben, die das macht und gleichzeitig gluPerspective ersetzt)

2. Vor der Frustumüberprüfung holt man sich die aktuelle Modelviewmatrix

3. Den zu testenden Punkt schickt man durch diese Matrix um seine Position nach Rotation usw. zu bekommen

4. Testen, ob sein z-Wert zwischen der Far und Nearclippingplane liegt, ansonsten ist schon sicher, dass er nicht im Frustum ist.

5. Da man die Breite und Höhe des Frustums an einer z-Position kennt (gespeicherte Frustuminformationen), kann man mit Hilfe der Strahlensätze die Breite und Höhe des Frustums an jeder z-Position berechnen. Dies wird also für die z-Position des Punkes gemacht und mit seiner x- und y-Position überprüft.

Die Überprüfung eines Punktes ist also relativ einfach (9. Schuljahr Mathematik ), Kugeln dürften dann auch nicht so schwer sein. Bei Würfeln oder Quadern müsste man sich noch etwas überlegen

Was meint ihr dazu?

PS: Leertaste: FrustumCulling an/aus
q u. w: Sichtwinkel
a u. s: Nearclippingplanedistanz
y u. x: Farclippingplanedistanz

_________________
Flummi: Projektseite und Projektthread

Hab mir jetzt deinen Srccode nicht angeguckt, aber bei der Normalenmethode hast du: 6x DP4 bei der Matrix-Methode: 4xDP4 für die Modelviewmatrix + die Berechnung mit den Strahlensätzen (die kannst du übrigends auch über die Projectionmatrix machen). Dürfte also mehr oder weniger aufs gleiche hinaus laufen, jedoch musst du bei der Matrixmethode immer mindestens 4xDP4 machen, wärend es bei der Normalenmethode schon nach 1xDP4 nen early-out geben kann.

Naja, ich steht total auf GL_NV_occlusion_query, da is Frustrumculling schon gratis mit dabei ^^

_________________
[18:30] tomok: so wie ich das sehe : alles. was nich was anderes ist als nen Essay ist nen Essay

hi, i'm a signature viruz, plz set me as your signature and help me spread

Verzeihung, was sind DP4s ?

@GL_NV_occlusion_query: Da hab ich noch gar nicht drüber nachgedacht, könnte ich mir aber auch mal anschauen. Danke für den Tip.

_________________
Flummi: Projektseite und Projektthread

DP4 steht in der Grafikkarten-Assemlber-Sprache für "4-component dot product" im Wiki hat Sascha das schon beschrieben.

Alle deine OpenGL-Befehle werden ja letztendlich von der Grafikkarte in diesem Maschinencode abgearbeitet. Dadurch lassen sich die verschiedenen Berechnungsmodelle einigermaßen vergleichen.

_________________
"Du musst ein Schwein sein in dieser Welt, sangen die Prinzen, das ist so 1.0. Du musst auf YouTube zeigen, dass dir dein Schweinsein gefällt, das ist leuchtendes, echtes Web 2.0."
- Hal Faber
Meine Homepage: http://laboda.delphigl.com

Die Occlusion Queries sind ausdrücklich nicht für frustum culling gedacht:

http://oss.sgi.com/projects/ogl-sample/ ... _query.txt

@Lars: Warum? Weils einfach kein Frustum Culling durchführt, oder weils zu aufwändig ist?

_________________
"Du musst ein Schwein sein in dieser Welt, sangen die Prinzen, das ist so 1.0. Du musst auf YouTube zeigen, dass dir dein Schweinsein gefällt, das ist leuchtendes, echtes Web 2.0."
- Hal Faber
Meine Homepage: http://laboda.delphigl.com

Die Occlusion Queries beziehen sich auf das, was man schon im Furstum zu sehen bekommt, und nicht darauf, was sowieso nicht im Blickwinkel drin ist.

_________________
"Meine Mutter sagt : 'Dumm ist der, der Dummes tut'." - Forrest Gump

@Average Idiot:
Deine Methode ist für Punkt<->Frustum Abfragen durchaus zu gebrauchen, müsste man halt schauen was sich effizienter implementieren lässt. Die Methode mit den Ebenen hat aber 2 Vorteile:
1. Eine Methode die den Abstand zwischen Ebene und Punkt berechnet braucht man ohnehin immer wieder, somit ist es meist überflüssig hier etwas eigenes zu schreiben. Zumal dann die Frustum behandelt werden kann wie eine "normale" Kollisionsabfrage.
2. Wenn du es mit Ebenen machst, so erhältst du den Abstand eines Punktes zur Ebene. Dadurch kannst du ohne Probleme deine Punkt<->Frustum Abfrage verwandeln in eine relativ genaue Kugel<->Frustum Abfrage. Relativ genau soll heißen, dass er Kugeln die sich ausserhalb der Frustum befinden hin und wieder auch als innerhalb der Frustum erkennt (also eine pessimistische Herangehensweise wie es beim Culling ja üblicherweise bevorzugt werden sollte, der umgekehrte Fall wäre schlimmer). Dieser (pessimistische) Fall tritt an den Eckpunkten und Kanten der Frustum auf.
Mit deiner Methode ist die Bestimmung des Abstandes eines Punktes zur Frustum verhältnismäßig schwierig. Bei Near- und Far-Plane kein Problem, aber bei den anderen Ebenen benötigst du in der ein oder anderen Weise den Normalvektor dieser Ebenen => wieso nicht gleich Ebenengleichungen wenns um Kugeln geht?

Ok, dann also keine Occlusion Queries (zumindestens nicht für Frustum Culling).

@AL: Bei mir gibts doch auch Early-Out, da ich ja erstmal nur die z-Position eines Punktes berechne. Damit fallen schon alle Punkte vor der Nearclippingplane und hinter der Farclippingplane weg, was je nach "Welt"-größe schon ein anständiger Anteil wär. Die (leicht) aufwändigere Berechnung der x- und z-Positionen wird nur für die übrig gebliebenen Punkte durchgeführt.

@Lyr: Hier steht wohl dein Wunsch "alles aus einem Guss" zu machen gegen meinen Wunsch es "anders" zu machen.
Mir reicht schon wenn man mir sagt "Persönlich würde ich es nicht so machen, aber ja, theoretisch würde es funktionieren"!
Danke, das meinte ich

Mit den Kugeln hast du vielleicht recht, soweit hatte ich noch nicht gedacht. Für Far- und Nearclippingplane ist es ja tatsächlich einfach. Für die Seiten geht es ja auch, nur muss man dann schauen, wie es mit der Übersichtlichkeit aussieht und ob es dann überhaupt noch effektiv ist.
Ich werds trotzdem mal ausprobieren

Punktüberprüfungen alleine sind wohl auch nicht so nützlich. Ich hab mir auch mal was für Boxes überlegt, das muss ich mir aber erst nochmal aufzeichnen, kann mir das nicht so im Kopf vorstellen.

_________________
Flummi: Projektseite und Projektthread

Für die Viewfrustum-Abfrage machst du hier üblicherweise ebenfalls einen eher pessimistischen Test, indem du schaust ob du eine Ebene der Frustum findest, welche _alle_ Punkte der Box ausschließt. Wiederum werden hier nur Kanten und Ecken der Frustum pessimistisch betrachtet. Diesen Test kannst du natürlich auch mit deiner Methode machen.
Für einen exakten Test verwendet man üblicherweise einen separation axis test (->Google), aber da dieser nicht gerade das performanteste ist was es gibt, wird gerne die pessimistische, aber schnellere Variante bevorzugt.

Gut, dass ich mir nichts kompliziertes überlegt habe Das geht ja um einiges leichter als ich dachte und vor allem schneller, was den vorhandenen Overdraw wettmacht

Danke.

_________________
Flummi: Projektseite und Projektthread

Man muß nur einen Punkt der Box betrachten, nämlich den der am nahesten an der Ebene dran bzw. am weitesten weg ist. Ob es schneller ist als alle 8 zu testen, habe ich nie gemessen.

if plane.normal.x>0 then punkt.x=bbox.min.x else punkt.x=bbox.max.x
if plane.normal.y>0 then punkt.y=bbox.min.y else punkt.y=bbox.max.y
if plane.normal.z>0 then punkt.z=bbox.min.z else punkt.z=bbox.max.z
punkt testen