01.03.2013 Aufrufe

Diplomarbeit (*.pdf - 5,3MB) - Faculty of Computer Science ...

Diplomarbeit (*.pdf - 5,3MB) - Faculty of Computer Science ...

Diplomarbeit (*.pdf - 5,3MB) - Faculty of Computer Science ...

MEHR ANZEIGEN
WENIGER ANZEIGEN

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.

oder deren gegenseitiger Abstand teilweise nur sehr gering ist und die meisten<br />

Implementierungen auf Grund dessen versagten.<br />

Als herausragend, was Geschwindigkeit und Robustheit angeht, stellte sich die<br />

Implementierung von [Lloyd] heraus, welche auf dem Verfahren nach [Barber,<br />

Dopkin u. Huhdanpaa] beruht. Hier wurden von den Autoren für Testzwecke<br />

zufällige Punktmengen im R³ generiert und die gleichen Punkte anschließend<br />

mit einer geringen Streuung versehen noch mehrmals hinzugefügt. Somit<br />

entstanden Punktmengen, in denen mehrere Punkte sehr dicht beieinander<br />

liegen. Anschließend wurde der Algorithmus auf diesen Punktmengen getestet<br />

und unter dieser Prämisse entwickelt.<br />

Ein weiterer Vorteil dieser Implementierung ist, dass sich die konvexe Hülle<br />

auch trianguliert ausgeben lässt. Auf Grund dieser entscheidenden Vorteile<br />

wurde die Implementierung von [Lloyd], die mit „QuickHull3D“ bezeichnet<br />

wird, folglich für die Generierung und Triangulierung der konvexen Hülle<br />

verwendet.<br />

4.3.2 OBB Aktualisierung<br />

Da die Erzeugung der OBBs relativ viel Rechenzeit beansprucht, werden diese<br />

im Bauteilkoordinatensystem erstellt und nach deren Erstellung in den<br />

zugehörigen virtuellen Baugruppen gespeichert. Sollen nun zwei OBB-<br />

Hierarchien auf Überschneidung getestet werden, so müssen diese in ein<br />

gemeinsames Koordinatensystem transformiert werden.<br />

Hierfür gibt es zwei Möglichkeiten: Entweder werden beide Objekte in das<br />

sogenannte Weltkoordinatensystem oder eines in das Koordinatensystem des<br />

jeweils anderen transformiert. Letzteres hat den Vorteil, dass nur ein OBB<br />

transformiert werden muss. Gleichzeitig müsste ein und dasselbe OBB bei Test<br />

mit unterschiedlichen anderen OBBs dafür aber jedesmal erneut transformiert<br />

werden. Folglich bietet es sich an, die OBBs in das Weltkoordinatensystem zu<br />

transformieren, da sich einerseits diese Transformation in Java3D schnell<br />

bestimmen lässt:<br />

Node.getLocalToVWorld(Transform3D transform)<br />

und sich andererseits die Transformationen somit wiederverwenden lassen:<br />

Da während einer vollständigen Kollisionskontrolle ein OBB unter Umständen<br />

mehrfach mit anderen auf Überlappungen getestet wird, sollte diese<br />

Transformation nicht bei jedem Test neu durchgeführt werden müssen. Die<br />

Idee ist daher, die transformierten Parameter mit im Original-OBB zu<br />

speichern. Es stellt sich nun jedoch die Frage, wann und wie diese aktualisiert<br />

werden sollten?<br />

Unter Verwendung der in Abschnitt 3.3.3 dargestellten Kohärenz, wäre ein<br />

erster Ansatz, in jedem Zeitschritt nur die OBBs von bewegten Objekten zu<br />

aktualisieren. Das Problem hierbei ist, dass alle OBBs, die in den Hierarchien<br />

88

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!