View-Frustum culling

hellihjb

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.

Code-Walker

Ne, es geht darum aus meinem Terrain die nicht sichtbaren Patches weg zu lassen, aus diesem Grund kann ich keine BoundingSpheres benutzen.

rapso

er hat nichts von spheres gesagt
er meint eckpunnkte
die 8 von deiner bounding box

Andreas XXL

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.

hellihjb

Mit dem Frustum Culling vermeidest du höchstens 50% der Vertexe

Warum das?

this-*gt*that

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.

rapso

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.

iop

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?

Code-Walker

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!

rapso

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.

this-*gt*that

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.

Code-Walker

bei mir ist es do (habe vogelperspektive):

Mit Frustum-culling: ca. 2500 fps
Ohne Frustum culling: ca. 27 fps

Bei 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.

rapso

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."

Code-Walker

genu so mache ich es im moment aber^^ wüsste nicht wirklich wie ich es sonst machen sollte.

rapso

Code-Walker schrieb:

bei mir ist es do (habe vogelperspektive):

Mit Frustum-culling: ca. 2500 fps
Ohne Frustum culling: ca. 27 fps

wenn du von der vogelperspektive aus ein grid siehst, brauchst du kein komplexes frustumculling, das dinge ganz trivial viel schneller, du weisst ja sicher welcher teil zu sehen ist vom ganzen 64*64 grid, da du die kamera drueber haengst.

Bei 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.

klar, nichts besonderes, uninitialisierte variablen.

Code-Walker

jo, grade bevor ich daslad, habe ich den fehler gefunden, lag daran. wusste nicht das man member variablen inistilisieren muss. Aber jetzt weiß ich es ja