Berechnung der Position der Ringaufhängung im Raum
Berechnung der einzelenen Fingergelenke im Raum
das ist die grundlagen um aus den Sensordaten die Geometrie der Hand zu errechnen und dadurch die Position der Fingerspitze.
aktueller screenshot vom programm für den versuchsaufbau.
im bild: die Kugel symbolisiert die Fingerspitze, die COMVEX_HULL_PRIMITIVE symbolisiert das thermObject. Die rote Linie ist die berechnete kürzeste Distanz zwischen den beiden Objek-Oberflächen. zu beachten ist, das die kollisionserkennung nicht an die vereinfachte Quadrat darstellung des convex-hull-primitiv gebunden ist. die berechnung erfolgt an der komplexen Oberfläche des Objektes. [collision A-B |x|y|z] gib den distanz-vektor relativ zum Ausgangspunkt an-> also die aktuelle entfernung der nähersten punkte auf den hüllen der zu berechnenden Objekte. Der Ausgangspunkt ist der mögliche Kollisionspunkt auf Objekt A -> der Kugel.
im bild: collision zwischen der Kugel und dem Objekt. zur veranschaulichung schaltet die wireframe-darstellung in rot um. der distanz-vektor ist bei 0,0,0.
[ _fps | timeStep] gibt die Performance aus, als bilder pro secunden die abhängig von der grafik-karten-leistung gerade ausgegeben werden.
das ist nun die grundlegende programmstruktur die ich für meinen versuchsaufbau benötige. Als nächster schritt soll die Position der Kugel über Sensoren gesteuert werden, und bei auftretender Kollision soll ein Peletrierelemente aktiviert werden.
ich entschied mich für die newton physic engine / version 1.52 / gibt es für mac linux u. pc
(freie bibliothek) newton physic engine ist aufgebaut auf OpenGL und enthält eine kollision detection (ideal für mein projekt). -> www.newtondynamics.com
-probleme beim einbinden am mac mit Xcode 2.1:
- newton 1.52 graucht gcc 4.x (bei mac ab XCode 2.x)
-fehlermeldung: error:’size_t’ has not been declared Newton.h:93
error:’size_t’ has not been declared Newton.h:92
typedef void (*NewtonSerialize) (void* serializeHandle, const void* buffer, size_t size);
typedef void (*NewtonDeserialize) (void* serializeHandle, void* buffer, size_t size);
size_t ist eine standart deklarierte variable die für speicherplatzreservierung verwendet wird. sie ist im stddef.h deklariert. Da ich ohne prefixheader arbeite in der diese includiert ist, muss sie in newton.h mit #include eingebunden werden.
-fehlermeldung: ZeroLink: unknown symbol ‘_hightMap_debugCount’
thermobject_C++_v2-1c has exited due to signal 6 (SIGABRT).
hightMap_debugCount ist im common/HeightFieldCollision.cpp declariert : extern dInt32 hightMap_debugCount; das problem hier ist, dass XCode das sogenannte ZeroLink verwendet. ZeroLink (näheres in XCode-Help) dient zum schnellen entwickeln von Programmen. Es legt bei Mehrdateien-Programme objekt-files an *.o, die miteinander wärend der Laufzeit verlinkt werden. Dadurch wird in einen Projekt immer nur die Code-Datei compiliert, die geändert wurde.Es mussen nicht immer die gesamten Datein des ganzen Projektes compilieren werden. ZeroLink unterstützt aber nicht die verwendung von privaten externen symbolen. privat externe symbole sind nur sichtbar in modulen, die das selbe Mach-O file besitzen. darum muss man in
Projekt->Edit Projekt Setting -> Build -> Other Linker Flags -> -no-run-initializers-before-main
eingeben. Dann wird nach statischen initilaisierunge in allen objekt-file’s gesucht, und verlinkt bevor die main-funktion aufgerufen wird.
Die “Bounding Box”-Methode
Kurz zusammengefasst: “Bounding Box”-Kollision ist die einfachste Kollisionsmethode, bei denen Rechtecke (die sog. “Bounding Boxes” - OBBs) die Umrisse von Objekten bilden. Wenn sich diese Rechtecke überlappen, dann findet eine Kollision statt. Ist rasend schnell, aber ungenau. Daher sollte man die “Bounding Box”-Routine behalten, um schnell herrauszufinden, ob zwei Objekte nicht oder möglicherweise kollidiert sind. Wenn die “Bounding Boxes” sich nicht überlappen, kann man gleich aufhüren, denn in diesem Fall gibt es sicherlich KEINE Kollision. überlappen sich aber die “Bounding Boxes”, so kann es möglicherweise eine Kollision geben, und diese genauer Berechnen (-> Kollisionsbaum).
Weiters gliedert sich die Kollisionserkennung in zwei wichtige Fragestellungen:
-Wann tritt die Kollision auf?
-Wo genau tritt Kollision auf?
Da die Simulation zeitlich diskret abläuft, kann es passieren, dass sich ein Objekt zunächst in einer gültigen und im
nächsten Zeitschritt bereits in einer ungültigen Konfiguration befindet (Objekte tauchen räumlich ineinander ein). Grund
für diese Situation ist die fehlende Behandlung des Kontaktes. Diese Behandlung muss möglichst genau dann stattfinden,
wenn eine Berührung vorliegt. Weiterhin ist es notwendig die genauen Stellen zu kennen, an denen diese Berührung stattfindet, wie die Oberflächennormale an diesen Stellen aussieht und welche Geschwindigkeiten dort vorliegen, um einen entsprechenden Stoss zwischen den Objekten zu berechnen.
Da die Oberflächen der Kollisionsobjekte durch sehr viele Dreiecke beschrieben sind, ist es in Echtzeit nicht mehr möglich
einfach jedes Dreieck des einen Kollisionspartners mit jedem Dreieck des anderen Kollisionspartners auf Schnitt zu
Überprüfen. Da kommen sogenannte Kollisionsbäume ins Spiel. Das sind räumliche Datenstrukturen, die eine effiziente Überprüfung der Dreiecke ermöglichen. Das Grundprinzip von Kollisionsbäume ist die hierachische Einteilung der Dreiecke in einen Baum aus Hüllvolumen. Der Wurzelknoten stellt ein Hüllvolumen um das gesamte Objekt dar (alle Dreiecke). Danach wird die Menge der Dreiecke entlang der Hauptausdehnung des Hüllvolumens in zwei Teilmengen zerlegt, die wiederum in eine Hüllvolumen gelegt werden. Diese bilden die Kindsknoten. Den Abschluss bilden dann die einzelnen Dreiecke als Blätter des Baumes.
(bild von University of Freiburg - Institute of Computer Science - Computer Graphics Laboratory)
kann dann effizient anhand des Baumes durchgeführt werden, indem bei dem Wurzelkonten begonnen und dann rekursiv durch den Baum traversiert wird. Findet an einem Knotenpaar keine Überlappung statt, so fallen sofort alle Kindsknoten aus dem Test.
Open GL hat selbst keine einfache Möglichkeit für Kollisionserkennung und simulieren von Physikalischen Ereignissen in 3D. Ich bin gerade auf der suche nach einer geeigneten freien Libary wie z.B die OPCODE-library (collision detection library).
www.codercorner.com/Opcode.htm