hi :)

yay, mein erster beitrag *G*

ich hab eine frage... ich benutze TFrustumClass (wozu das Rad 1000mal neu erfinden, außerdem hab ich keine Ahnung
von der mathematik *g*) aber ich bräuchte eine kleine änderung.



die schwarze linie ist der berechnete frustum, also das tatsächliche blickfeld (was so nicht ganz stimmt, weil die berechnung ungenau ist). ich bräuchte als ergebnis aber so etwas wie die rote linie... also quasi ein vergrößertes frustum, das die
"kamera" und auch die fläche um das blickfeld einbezieht.

ist das verständlich? *g* kann mir da jemand helfen? ich muß mich mit anderen dingen herumschlagen, als das ich mich
jetzt eingehend mit matrizen usw beschäftigen könnte (effizientes terrain-culling zB).

dankeschön :)

EDIT: BBCode aktivieren nicht vergessen, damit man das Bild sieht lol

Am einfachsten ist es das Volumen mit dem du den Test durchführst zu vergrößern. Bei einer Kugel brauchst du z.B. einfach nur den Radius verändern und erhälst genau den von dir beschriebenen Effekt.

Wobei sich mir die Frage stellt wofür du das brauchst. Ich kenne die TFrustumClass-Klasse nicht, aber eigentlich sollten die Berechnungen genau sein.

_________________
Nichts auf der Welt ist so gerecht verteilt wie der Verstand. Denn jederman ist überzeugt, dass er genug davon habe.
Rene Descartes, frz. Mathematiker u. Philosoph, 1596-1650

Ist das nicht die Klasse von Sascha? (DelphiGL.de)

_________________
Blog: kevin-fleischer.de und fbaingermany.com

ok, meine frage war wohl doch zu ungenau.

das volumen für den test vergrößern hilft mir nichts, weil ich nur punkte-tests mach. sprich "isPointWithin". und ja, die klasse ist die öffentliche, die jeder
benutzen kann und wenn der coder sascha heißt ists auch gut *gg*

mir gehts darum, das das frustum punkte am rand des blickfelds (sprich: das gerenderte bild) nicht als punkte im frustrum erkennt ... was dazu führt, das
das frustum rechnerisch etwas vergrößert werden müßte, ich aber keinen schimmer darüber hab, wie das funktioniert.

Hallo,

ich hab mich jetzt mal etwas mehr mit Frustum beschäftigt und es geschafft ein eigenes FrustumCulling zu implementieren *stolz sei*
Vorher habe ich immer die Klasse von Sascha benutzt, wusste aber nie genau wie das jetzt funktionier (habe ich auch jetzt noch nicht verstanden). Meine Lösung ist zwar vielleicht "Hausgemachter", oder im Endeffekt sogar irgendwie die gleiche, Hauptsache es funktioniert. Ein Nachteil ist, dass man diese Methode am besten mit glFrustum statt mit gluPerspective benutzt. Sollte aber eigentlich kein Problem sein.

So ersteinmal die Definitionen:


Es wird zwar nicht alles gebraucht (z.B Width und Height der FarClippingPlane), aber so gibt es Möglichkeiten für Erweiterungen. Ich hoffe die Begriffe sind alle selbsterklärend .

Kommen wir zum nächsten Teil:

Jetzt fragt mancher sich vielleicht, warum ich die Entfernungen der ClippingPlanes vom Betrachter negiere. Das ist nur dazu da, damit die Parameterübergabe zu glFrustum identisch ist. Eigentlich ist es unnötig und man könnte direkt negative Parameter übergeben, aber so gefällts mir halt

Nun kommt die eigentliche Frustumüberprüfung:

Das muss ich vielleicht etwas genauer erklären. Also erstmal wird die Modelviewmatrix von OpenGL geholt. Zu Matrizen gibt es hier bei DGL ein sehr gutes Tutorial (unter Mathematisches wars glaube ich), außerdem muss mann darauf achten, dass eine Matrix in OpenGL wie folgt aussieht (Ich meine hier die Indexe des Arrays):
0 4 8 12
1 5 9 13
2 6 10 14
3 7 11 15

Nun errechnen wir erstmal mit der Modelviewmatrix, an welcher Z-Position sich unser Point nach den von OpenGL durchgeführten Translationen und Rotationen befindet.

Dann wird zuerst abgefragt, ob sich diese Z-Position zwischen dem Betrachter und der FarClippingPlane befindet. Wenn nicht, wird im Else-Teil result auf FALSE gesetzt und die Procedure ist zuende, der Punkt ist nicht sichtbar.

Sollte der Punkt doch dazwischen liegen, müssen wir noch prüfen, ob er nicht über, unter oder neben unserem Frustum liegt. Dazu berechnen wir erstmal noch die \"echten\" X- und Y-Positionen.

Da wir ja ein perspektivisches Frustum haben, müssen wir die Breite und Höhe davon anhand der Z-Position unseres Punktes herausfinden. Dafür wurden die Stahlensätze erfunden . Ich weiss jetzt nicht wie ich das jetzt verständlich erklören soll, aber auf Anfrage werde ich es gerne versuchen. Ich bin übrigens davon ausgegangen, dass man ein symetrisches Frustum besitzt, also z.B glFrustum(-4,4, -3,3, 5,100) und nicht glFrustum(-9,3, -6,7, 5,100) .


Der Rest dürfte so dann auch klar sein. Ist die If-Abfrage erfüllt wird, dann liegt der Punkt im Frustum und wenn nicht, dann halt nicht .

Im Programm muss man dann irgendwo beim initialisieren nur noch SetFrustum aufrufen.

Zeichnen dann folgendermaßen:


Das ist zwar nur ein Überprüfung für einzelne Punkte, aber auch Kugeln und Würfel sind kein Problem, siehe TFrustumClass von Sascha. Das überlasse ich dann noch an Arbeit .
FrustumCulling benutzt sowieso am besten zusammen mit einem Octree oder Ähnlichem, bringt noch einmal unheimlich viel Performance.

Ich gebe ja zu, dass dieser Post jetzt ein kleines (nur ein kleines) bisschen lang geworden ist. Hoffe ich habe nicht gelangweilt und konnte helfen. Würde mich über Feedback freuen.


PS: Der Code könnte Tippfehler enthalten, da ich ihn von nem anderen Rechner abgeschrieben hab und nicht mit Copy&Paste eingefügt hab.

_________________
Flummi: Projektseite und Projektthread

Wenn du sowieso nur Punkte testest und du den Bereich vergrößern willst, der als Frustum zählt, dann kannst du doch einfach statt der Punkte Spheres nehmen! Dann hast du einen bestimmten Radius der Kugeln, und wenn der Punkt also mit dem Radius drinnen liegt im Frustum (oder die Ebenen schneidet), wird dir ja automatisch True zurückgegeben, und hast deine Toleranzgrenze somit auch erweitert

PS: Hab AI's Post nicht gelesen, sorry falls du es schon so gelöst haben solltest

hey danke A.I, ich werd mir das beizeiten genauer ansehen und mich dann melden :) muß derzeit mein Zimmer wegen Staubbelastung reinigen *ggg*
das glGetFloatV stört mich etwas, muß mir da den Speed ansehen.. ist es echt notwendig, diese matrize bei jedem punkt neu auszulesen?

lol danke Mr. Fletcher, daran hab ich gar nicht gedacht... hab den Code verglichen, ist genau das gleiche, nur das ein Radius getestet wird. werd mir das
auch zu gemüte führen (war wohl echt blind) und dann testen.

übrigens... ja, frustum culling ist super für terrain-culling, aber ich benutze weder quadtrees noch octtrees dafür, weil ich das als fürchterlich ineffizient anseh.

wie viele tests pro frame (bzw blickwinkelveränderung) habt ihr durchschnittlich im quad-/oct-tree (nodes)? und wie viele frustum-tests?

In einem Octree wird ja auch nur mit Frustrum getestet. Höchstens noch über Occlusion Queries, wobei ich mich mit denen net auskenn' Aber wie willst du eine Landschaft mit Frustrum Culling schneller darstellen ohne Octree / Quad-? Irgendwie musst du es ja unterteilen, sonst bringt's dir gar nix Und Octrees sind schon verdammt schnell. Ich bekomm' damit einen Geschwindigkeitszuwachs von ca. 800%. Und das ist nicht wenig

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

hi ... eine kurze antwort *g* bin noch nicht dazu gekommen, mir den code anzusehen... zimmer und so *g*

das kommt drauf an, wie man das sieht ... ich muss die landschaft nicht unterteilen, wenn ich sowieso weiß, wo ich bin. verständlich? *g*
ist eh ganz logisch... wenns funktioniert, werd ichs auf jeden fall posten... was mich interessiert (damit ich einen vergleich hab) ist, wie viele
tests in euren routinen so durchgeführt werden. ich plane einen test pro "schritt" (=drehung links/rechts, schritt vor/zurück). aufsteigen (y-koordinate)
müßte genauso funktionieren, falls jemand denkt ich beschränk mich hier auf ne flache landschaft *g* aber das muß erst getestet werden.

kann sein, das ich kryptisch rede, aber ich stell mir alles immer irgendwie vor und der code ploppt dann heraus *g* und wenns nicht funktioniert ists
mir auch egal... ich hab immer versucht, mir eigenes zu überlegen, bevor ich das nutze, was alle nutzen *g* darum hab ich mich früher auch mit
voxel-engines beschäftigt lol

Voxel sind ja auch cool

Aber nur weil du weißt, wo du bist, weißt du ja noch nicht, was denn gerendert werden muss ^^

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

ja, voxel sind voll cool *g* ich dachte mir aber, ich versuch mal was anderes... ist ja auch schon "ewig" her *g*

hm ... du siehst das falsch. wenn ich weiß wo ich bin, kann ich auch "sehen" was gerendert werden muß *ggggg* wir werden ja sehen, noch ist es nicht
fertig :)

an die arbeit ^^

also, der code von fletcher funktioniert nicht... und ja, die fehler hab ich bemerkt und ausgebessert.

das mit dem sphärentest geht auch nicht, weil ich da 1. nicht genau weiß welche punkte genau inkludiert sind und ich, wenn ich einen hack einbaun würd
damit ich es weiß, letzten endes zu viele punkte hätte....

zurück zum 1. beitrag... *g*

muß schaun, das mir ein hack einfällt, wenn das so nicht funktioniert. oder vielleicht doch mal matrizen ansehen *raunz* *gg*

ist es so kompliziert, die berechnung zu erweitern? *hmpf*

Hi Akira, ich vermute dann also mal, dass du ne Landschaft hast. Ich hab zwar keine Ahnung, wie du das dann ohne Unterteilung (Octtree, Quadtree o.ä.), schneller machen willst, als mit. Lass mich mal überraschen .

Da ich in meinem Testprogramm jeden Punkt mit gltranslatef gesetzt habe, muss ich auch bei jedem Punkt mit glGetFloatv die ModelviewMatrix neu holen. Der Aufruf von glGetFloatv ist auch nicht wirklich teuer.
Allerdings hast du recht, wenn man ein großes Landschaftsmesh hat, bei dem die Vertexpositionen direkt angegeben werden, dann reicht es die Matrix einmal, nachdem die Betrachterposition und Drehung festgelegt wurden, zu holen.

Das gleiche gilt wenn man Würfel auf Sichtbarkeit testet (einfach schauen, ob einer der 8 Eckpunkte im Frustum liegt), die Eckpunkte sollen dann ja alle die gleiche Position und Drehung (in Relation zueinander) haben. Man kann sie also auch alle nacheinander durch die gleiche Matrix schicken.

Die Lösung mit dem Frustum einfach etwas vergrößern finde ich irgendwie "unsauber" . Andererseits wundert es mich auch, denn vorher habe ich auch immer TFrustumClass benutzt und keine Probleme gehabt.
Allerdings ist mir (nachdem ich es nochmal getestet hatte) aufgefallen, dass meine Methode viel schneller läuft. Kann es sein das ich Saschas Klasse falsch benutze? So FrustumCulling allein bringt da zwar ein bisschen, aber nicht wirklich viel Geschwindigkeit.
In nem anderen Programm von mir, zusammen mit nem Octtree rockt es aber.

Meinst du meinen Code, oder welchen von Mr.Fletcher?

Übrigens, was meint eigentlich dein Nick? Ich hab letzten Monat einen japanischen Austauschschüler kennengelernt, der hieß genauso.

_________________
Flummi: Projektseite und Projektthread

ähm... ich meinte deinen code, nicht den von fletcher. hab mich vertan *g*

ich wollte bescheid sagen, das ich einen anderen weg gefunden habe, mir auszurechnen, was ich brauche. mir wäre zwar die "unsaubere" (hä? *g*) lösung
mittels frustum lieber gewesen (weil einfacher), aber wenn das nicht einfach so klappen will, dann nicht. wenn dein code schneller ist, ists gut. das heißt ja
nicht, das du was falsch machst ^^

danke nochmal :) wenn ich hab, was ich wollt, werd ichs posten. und wenns nicht klappt, auch *g*

Woher willst du wissen was du siehst, wenn du keine Struktur gebaut hast die dir sagt was du siehst. Octrees sind gar nicht soooo aufwendig (wenn man nicht solchen quark codet wie ich damals )

_________________
Blog: kevin-fleischer.de und fbaingermany.com