entscheiden ob vertex in raum liegt
-
hi folks!
ich bastle gerade an einer octree-implementierung.
momentan moechte ich geschwinigkeit gewinnen, indem ich ueberpruefe, welche
nodes/leafs meines octrees innerhalb des sichtbaren bereichs liegt, und zeichne nur diese.der sichtbare bereich ist ja, wenn ich eine maximale sichtweite definiere, (in etwa) eine pyramide, deren spitze durch den punkt der kamera definiert wird, und die mitte der bodenflaeche ist dann der sicht-vektor (simpel ausgedrueckt).
wie kann ich jetzt entscheiden, ob ein vertex innerhalb dieser pyramide liegt (und somit gezeichnet werden soll)?
danke im voraus,
---loki
-
Ich würde das Koordinatensystem so legen bzw. transformieren, daß die Kamera aus dem Usprung in Richtung der x-Achse liegt. Dann liegen alle Punkte in der Pyramide, für die |y|/x ≤ tan α und |z|/x ≤ tan α gilt:
^y | _- | _- |_- [e]alpha[/e]\ -+[u]-[/u]----->x | - | -_ | -
-
extrahiere die clippingplanes und dann kannst du rausfinden ob der vertex davor oder dahinter liegt, liegt er hinter einer plane ist er raus.
-
rapso schrieb:
extrahiere die clippingplanes und dann kannst du rausfinden ob der vertex davor oder dahinter liegt, liegt er hinter einer plane ist er raus.
Stichwort Frustum Culling...
bei NeHe gibts auch ein Tutorial drüber: 3D Lens Flare With Occlusion Testing
-
rapso schrieb:
extrahiere die clippingplanes und dann kannst du rausfinden ob der vertex davor oder dahinter liegt, liegt er hinter einer plane ist er raus.
öhm, das sind doch insgesamt 6 clippingplanes, das heisst, der muss für jeden vertex eine Addition + Punktproduktmultiplikation durchführen, um zu gugn, ob das oberhalb oder unterhalb der ebene liegt... (36 Additionen+ 18 Multiplikationen wenn ich mich ned irre)
wär's da nich einfacher, die fertige kameramatrix zu nehmen, und zu gugn, ob die werte des damit transformierten vertex immer im [-1 ; 1]-Interval liegen?
Das wären nur noch 16 multiplikationen und 12 additionen, nicht wesentlich weniger, aber immerhin...@ loki: wen du aber mit großen quaderförmigen Octree-Nodes herumhantierst, bringen dich die ecken des quaders eh nich weiter, weil die alle auserhalb des view-frustums liegen können, obwohl der quader das ganze bild einnimmt
-
Und eine frage, passend zum thema... kann mir bidde jemand sagen, welchen vorteil es hat, dass man octree und kein BSP-tree (mit immer nur zwei child-nodes) einsetzt?
-
Andrey schrieb:
öhm, das sind doch insgesamt 6 clippingplanes, das heisst, der muss für jeden vertex eine Addition + Punktproduktmultiplikation durchführen, um zu gugn, ob das oberhalb oder unterhalb der ebene liegt...
nein, er kann immer 3mul und 4 additionen machen und gleich testen, die near und farplane kann man auch mit 3mul und 5 additionen insgesammt herausbekommen und nach dem test hat man schon die meisten punkte herausgefiltert.
zudem ging es hier nicht um optimierungen sondern ueber die grundsaetzliche funktionsweise, ansonsten koennte man ums frustum eine sphere machen oder einen cone mit dem man sehr effektiv das meiste verwerfen koennte.Andrey schrieb:
Und eine frage, passend zum thema... kann mir bidde jemand sagen, welchen vorteil es hat, dass man octree und kein BSP-tree (mit immer nur zwei child-nodes) einsetzt?
weil man mit weniger tests ein octree testen kann, als man 3ebenen vom bsp testet (damit man die selbe raumaufteilung bekommt. zudem gibt es speichervorteile (weniger und effizienter) etc.
am ende kommt es immer auf das anwendungsgebiet und die implementierung an.
-
hm, dat stimmt alles
, hab mich dann wohl doch bissl verkalkuliert^^ 
außerdem: bei der matrix-projektion müsste ich noch alles mit 1/w multiplizieren, und das würde ne ewigkeit dauern
-
Andrey schrieb:
außerdem: bei der matrix-projektion müsste ich noch alles mit 1/w multiplizieren, und das würde ne ewigkeit dauern
nur zum testen muestest du das nicht unbedingt dividieren, du muesstest dann nur immer in der ragen von -w bos +w statt -1 + 1 (bei der nearplane weiter hin gegen 0) testen.