3D Box Kollision
-
Cpp_Junky schrieb:
hellihjb schrieb:
...
Du pruefst ob eine Kante des einen Wuerfels eine Flaeche des anderen Wuerfels schneidet...Wie macht man sowas, geometrisch/mathematisch gesehen?
Line/Plane-Intersection und dann pruefen, ob der Schnittpunkt innerhalb der Flaeche liegt.
-
hab jetzt vergessen gehabt drauf zu antworten, was ich urspruenglich vor hatte
hellihjb schrieb:
Cpp_Junky schrieb:
hellihjb schrieb:
...
Du pruefst ob eine Kante des einen Wuerfels eine Flaeche des anderen Wuerfels schneidet...Wie macht man sowas, geometrisch/mathematisch gesehen?
Line/Plane-Intersection und dann pruefen, ob der Schnittpunkt innerhalb der Flaeche liegt.
wobei die planes ja axis aligned sind wenn du im space der einen box bist, da kannst du viel vereinfachen, notfalls nach 'line AABB intersection' googlen.
ach ja, kann man ein preview vom source bekommen? (bei deiner page steht dass es irgendwann open source wird)
-
Danke!
Wir räumen jetzt nach und nach unseren Source auf und stellen das Zeug dann bei Sourceforge rein. Momentan ist das leider noch ziemlich chaotisch und sogut wie undokumentiert *schäm*
-
Cpp_Junky schrieb:
Danke!
Wir räumen jetzt nach und nach unseren Source auf und stellen das Zeug dann bei Sourceforge rein. Momentan ist das leider noch ziemlich chaotisch und sogut wie undokumentiert *schäm*
http://www.stack.nl/~dimitri/doxygen/ + http://www.graphviz.org/
-
Ja, gute Idee
-
Hier gibts eine wunderbare Tabelle mit sogut wie allen aktuellen Algorithmen:
http://www.realtimerendering.com/intersections.html
-
Die meissten "Lösungen" basieren einfach darauf, das die "oriented" Box in eine "axis aligned" Box umgewandelt wird. Dabei wird die Kollisionsprüfung natürlich noch ungenauer als sie bei einem Bounding Volume ohnehin schon ist.
Ich habe mir dann mal einen Ansatz angesehen, der sich "Separating Axis Theorem" nennt.
Zur Info:
http://en.wikipedia.org/wiki/Separating_axis_theorem
http://www.lidev.com.ar/?p=295Diese Lösung funktioniert nun sehr gut, mit beliebigen Boxen, unabängig von ihrer Ausrichtung. Zur Performance Verbesserung findet zusätzlich vorher eine Bounding Sphere prüfung statt. Ich denke das sollte erstmal reichen. Danke euch trotzdem
-
Cpp_Junky schrieb:
Die meissten "Lösungen" basieren einfach darauf, das die "oriented" Box in eine "axis aligned" Box umgewandelt wird.
Dabei wird die Kollisionsprüfung natürlich noch ungenauer als sie bei einem Bounding Volume ohnehin schon ist.Eigentlich dreht man einfach *beide* Boxen so, dass eine von ihnen axis-aligned ist; Genauigkeit geht dabei nicht verloren.
Diese Lösung funktioniert nun sehr gut, mit beliebigen Boxen, unabängig von ihrer Ausrichtung.
Dann ist's ja gut
-
hellihjb schrieb:
...Eigentlich dreht man einfach *beide* Boxen so, dass eine von ihnen axis-aligned ist; Genauigkeit geht dabei nicht verloren.
...Naja die nehmen halt die transformierte Box, holen sich Min/Max X/Y/Z und machen daraus eine neue. Das heisst, wenn die Box ungünstig gedreht ist, wird die neue unter Umständen fast doppelt so gross
Wie funktioniert denn diese Variante mit dem Drehen?
-
Cpp_Junky schrieb:
Wie funktioniert denn diese Variante mit dem Drehen?
Eine Bounding-Box spannt ja ein Koordinatensystem auf:
Wenn Du einen beliebigen Eckpunkt (Position) nimmst, liegen dort drei Kanten (Richtungsvektoren) an, die alle senkrecht aufeinander stehen - daraus machst Du eine 4x3 Matrix.
Diese Matrix wuerde einen Einheitswuerfel, der an (0,0,0) liegt und entlang der kartesischen Achsen ausgerichtet ist, so transformieren, dass er genau Deckungsgleich mit Deiner Bounding-Box ist.
Die inverse Matrix transformiert dann Deine Bounding-Box genau auf diesen Einheitswuerfel.
Die gleiche Transformation wendest Du dann auf die Eckpunkte der zweiten Bounding-Box an und pruefst diese gegen den Einheits-Wuerfel.