View-Frustum culling
-
Du hast die Ebenengleichung der Frustumseiten in Hessescher Normalform.
Die ersten 3 Parameter sind die Normale der Ebene und der vierte der Abstand vom Ursprung (besagt wie weit Du Dich vom Ursprung entlang der Normale bewegen musst um auf die Ebene zu stossen).
Um zu pruefen ob ein Objekt ausserhalb des Viewfrustums liegt, pruefst Du einfach ob alle Eckpunkte jenseits (Vorzeichen der Abstandspruefung) einer dieser Ebenen liegen.
Da Dich nur das Vorzeichen interessiert musst Du auch nicht "normalizieren".Deinen Code brauchst du nciht verstehen, den versteht fast niemand (glaube ich).
Der Vektorraum (Wuerfel dessen Normalen durch den 3x3-Teil der Matrix gegeben sind) wird entsprechend der Perspektive (4. Zeile der homogenen Matrix) zum Pyramidenstumpf geschert.
-
Danke, das hat mir sehr weiter geholfen! Wie teste ich denn am schnellsten ob eine Zahl im positioven oder negativen liegt?
-
das kann doch grnicht unktionieren, da ich entlang der normale vorher an der Ebene vorbei schießen würde?
Wenn ein Strahl die Ebene nicht schneidet verlaeuft er parallel zur Ebene.
Die Normale steht aber senkrecht zur Ebene.
Ein Strahl von einem beliebigen Punkt entlang der Ebenennormalen muss die Ebene also treffen.Wie teste ich denn am schnellsten ob eine Zahl im positioven oder negativen liegt?
Du pruefst keine Zahl sondern einen Vektor und zwar so:
Maxi schrieb:
musst du den Punkt in [die] Ebenengleichungen Ax+By+Cz-D=? einsetzen.
-
Wenn ein Strahl die Ebene nicht schneidet verlaeuft er parallel zur Ebene.
Die Normale steht aber senkrecht zur Ebene.
Ein Strahl von einem beliebigen Punkt entlang der Ebenennormalen muss die Ebene also treffen.Ist mir auch grad eingefallen.
Wie teste ich denn am schnellsten ob eine Zahl im positioven oder negativen liegt?
Damit meine ich eigentlich wie ich am schnellsten teste welches vorzeichen eine Zahl hat, habe das noch nie getestet.
-
Blöde frage, natürlich mit < > Operatoren. Sorry, liege grad zuhause mit Fieber im Bett, hab da so ne Denkblokade
-
habe das noch nie getestet.
Ob zwei Vektoren einander zugewand sind kann man einfach per Dot-Produkt testen (kennst Du sicher von diffuser Beleuchtung). Zusaetzlich willst Du noch wissen, ob der zu pruefende Punkt weiter weg liegt als die Ebene selbst (darum einfach den Abstand "D" abziehen) woraus sich die "Seite" der Ebene ergibt.
-
Habe das ganze nun mal umgesetzt. Am Anfang gab es ein paar Probleme, bis ich darauf gekommen bin das ich in der rechnung noch die vorzeichen des Vectors ändern muss.
Nun muss ich testen ob eine BoundigBox im Sichtbereich ist. Leider kann ich ja nicht einfach testen ob ein Punkt im Sichtbereich ist, und es dann anzeigen, da j lle Ecken der Bounding Bx aussehalb des Sichtbereichs sein können, aber trotzdem den ganzen Bildschirm einnimmt. Giebt es ür Bounding Boxes einen bestimmten Algo?
* Bin richtig happy das das Frustum culling endlich funktioniert *
-
Man prueft ob *alle* Punkte ausserhalb *einer* Seite liegen.
Fuer gewoehnlich setzt man ein Flag fuer jede Seite und "undet" die dann zusammen.Ob ein Punkt im Viewfrustum liegt ist im Clipspace uebrigens leichter festzustellen (-w<=x<=w && -w<=y<=w && 0<=z<=1) und bei Boundingspheres muesstest Du nur einen Punkt pruefen.
-
Ne, es geht darum aus meinem Terrain die nicht sichtbaren Patches weg zu lassen, aus diesem Grund kann ich keine BoundingSpheres benutzen.
-
er hat nichts von spheres gesagt
er meint eckpunnkte
die 8 von deiner bounding box
-
Nur mal so einige Hinweise:
Wenn man Wikipedia benutzt erübrigt sich das "Rumgebastel", denn sogar hierfür gibts nen Eintrag.
http://wiki.delphigl.com/index.php/Tutorial_Frustum_Culling
(OK in Delphi aber soooooo anders ist das auch wieder nich)Die verwendung von VBOs
http://wiki.delphigl.com/index.php/Tutorial_Vertexbufferobject
bringt dir 10 mal mehr Geschwindigkeitsgewinn als das Frustum culling.
Weil nicht die Grafikkarte das Problem ist sondern der Bus dazwischen.
Mit dem Frustum Culling vermeidest du höchstens 50% der Vertexe. Wenn du aber VBOs nimmst kannste sehr viel mehr Busdaten aufkommen vermeiden und die Grafikkarten schaffen deutlich mehr zu verarbeiten als sie über den Bus an Daten bekommen können.
-
Mit dem Frustum Culling vermeidest du höchstens 50% der Vertexe
Warum das?
-
Code-Walker schrieb:
Ne, es geht darum aus meinem Terrain die nicht sichtbaren Patches weg zu lassen, aus diesem Grund kann ich keine BoundingSpheres benutzen.
Doch, kann du. Du kannst einfach jeden Patch in eine Kugel einhüllen, dann einen Frustum<->Sphere Schnittest machen und nur wenn ein Schnitt rauskommt dann den genaueren Test mit der AABB durchführen.
Andreas XXL schrieb:
Die verwendung von VBOs
bringt dir 10 mal mehr Geschwindigkeitsgewinn als das Frustum culling.Die 2 Themen haben nichts miteinander zu tun.
Andreas XXL schrieb:
Mit dem Frustum Culling vermeidest du höchstens 50% der Vertexe.
Nein. Du verwechselst das vielleicht mit Backface Culling, und auch da ist diese Aussage zweifelhaft.
@Implementierung: Ich hoffe du testest nicht wirklich alle 8 Vertices gegen alle 6 Ebenen (solange bis die Box sicher drinnen oder draußen ist). Das wäre ziemlich ineffizient.
-
this->that schrieb:
@Implementierung: Ich hoffe du testest nicht wirklich alle 8 Vertices gegen alle 6 Ebenen (solange bis die Box sicher drinnen oder draußen ist). Das wäre ziemlich ineffizient.
das ist was die meisten tutorials vorschlagen. frustumculling an sich ist ineffizient.
-
rapso schrieb:
frustumculling an sich ist ineffizient.
Kannst Du mir das bitte ein wenig erläutern? Ich meine, wenn man eine Bounding Sphere benutzt, hält sich der Aufwand doch in Grenzen, oder?
-
Wenn man Wikipedia benutzt erübrigt sich das "Rumgebastel", denn sogar hierfür gibts nen Eintrag.
Nicht jeder findet das was er sucht auf anhieb!
Mit dem Frustum Culling vermeidest du höchstens 50% der Vertexe. Wenn du aber VBOs nimmst kannste sehr viel mehr Busdaten aufkommen vermeiden und die Grafikkarten schaffen deutlich mehr zu verarbeiten als sie über den Bus an Daten bekommen können.
Ertsmal benutze ich DirectX und nicht OpenGL, und zweitens woher willste denn wissen ob ich nicht schon längst Vertex/Index Buffer benutze?? Und durch Frustum Culling werden ganz bestimmt nicht nur 50% reduziert, mein Terrain wird aus der Vogelperspektive betrachtet und von 64x64 patches sind maximal 4 patches sichtbar! Ich würde nicht sagen das es unefizient ist!
-
iop schrieb:
rapso schrieb:
frustumculling an sich ist ineffizient.
Kannst Du mir das bitte ein wenig erläutern? Ich meine, wenn man eine Bounding Sphere benutzt, hält sich der Aufwand doch in Grenzen, oder?
du hast trotzdem viele tests.
gerade wenn du z.b. ein octree mit ueblichen frustumplanes durchgehst gibt es erstmal sehr viele ebenen die 'potentiel' sichtbar sind bis du dann mit unmengen tests auf kleiner ebene feststellst die meisten elemente sind nicht sichtbar.
besonders wenn du schreg schaust, sind die planes so unguenstig dass sie sehr viel ueberschuss produzieren.
willst du das nun akkurater machen um die effiziens zu steigern, hast du mehr berechnungen pro test -> ineffizienter.deswegen ist es oft nuetzlich boundingobjekte um und im frustum zu haben und dagegen zu testen (wenn man es smart anstellt, ist die camera nur ein weiteres objekt im z.b. octree) und damit cullt man schon unmengen von objekten weg.
danach bleiben nicht mehr viele die mit simplen plane-tests verworfen werden.das resultat ist dann oft besser und man ist sehr viel schneller gewesen.
sowas in der art steht: http://www.flipcode.com/archives/Frustum_Culling.shtml
leider find ich nichts wirklich gutes.
-
rapso schrieb:
frustumculling an sich ist ineffizient.
Kann man so nicht sagen. Wenn man es einigermaßen gut implementiert kann es extrem viel bringen. Ohne irgendwelche weiteren Maßnahmen hat es bei mir FPS verdoppelt.
-
bei mir ist es do (habe vogelperspektive):
Mit Frustum-culling: ca. 2500 fps
Ohne Frustum culling: ca. 27 fpsBei mir bringt das dann dch schon einiges! Aber ich habe mal eine frage, eine ganz kleine für die ich kein neues Thema aufmachen will. Warscheinlch kennt ihr das problem.
Wenn ich mein Programm compiliere, und es dann automatsch von der ide gestartet wird, dann zeigt es von meinem terrain die hügel an, wenn ich die exe aber normal starte, also einfach doppelklick drauf mache, dann ist das land plötzlich ganz flach. Wenn ich die exe aber an andere weiter schicke, und die sie startet, sehen sie die berge. Ich lade die höhen daten *nicht* aus einer datei, sondern generiere sie vollkommen automatisch. Jetzt frage ich mich woran das liegen kann?? Denn das verwundert mich sehr, denn die ide macht dch nichts anderes als die exe auch normal zu starten.
-
this->that schrieb:
rapso schrieb:
frustumculling an sich ist ineffizient.
Kann man so nicht sagen.
kann man genau so sagen wie man sagen kann: "Ich hoffe du testest nicht wirklich alle 8 Vertices gegen alle 6 Ebenen (solange bis die Box sicher drinnen oder draußen ist). Das wäre ziemlich ineffizient."