Entwickler-Ecke
Sonstiges (Delphi) - In der Box, oder nicht? (3d-Kollision)
Hugo343 - Sa 19.09.09 15:38
Titel: In der Box, oder nicht? (3d-Kollision)
Hallo Delphiforum! Ich programmier grad mit OpenGl, ich habe auch schon eine Funktion mit der ich aus einfachen Angaben einen Block gestalten kann (bestehend aus 6 Seiten) Bspl.: Startpunkte des Blockes x,y,z und deren Längen xl,yl,zl. Als String also 'x;y;z;xl;yl;zl;texnumber' geschrieben (texnumber ist die Adresse der Textur die ich verwenden will).
Jetzt zu meiner eigentlichen Fragestellung: Ich will eine recht simple Kollision machen, indem ich abfrage ob sich der Spieler in der Position des Würfels befindet, wenn ja, dann wird der Spieler an seine vorherige Position gesetzt, sodass er nie in einem Würfel drin sein dürfte. Leider fliege ich mit meiner Cam immernoch durch den Block...
Und um Bemerkungen wie "Forums-Suche" usw. auszuweichen weise ich darauf hin das ich gesucht habe und auch die tut's von delphigl durchforstet habe, leider ohne schlauer zu werden.
Hidden - Sa 19.09.09 16:20
Hi :)
Dein Post enthält für mich leider nicht die Information, was schief läuft, da kann ich nur noch einmal das Standardverfahren beschreiben :nixweiss:
Für jede Koordinate musst du einmal versichern, dass sich der Spieler außerhalb befindet, also (x1 > x) and (x1 < x + xL) damit geblockt wird. - das dürfte aber auch schon dein Ansatz gewesen sein, ich wüsste nicht welchen anderen man da noch finden kann.
Zu erwähnen wäre vielleicht noch, dass du die Terme richtig klammern musst und für alle Koordinaten prüfst - wenn dort etwas schiefgegangen wäre, sollte der Block aber auf jeden Fall gesperrt sein und gegebenenfalls ein bisschen mehr(aus dem Block wird eine Säule, wenn die x- und y-Koordinate zur Sperrung reichen), keinesfalls aber weniger.
Delphi-Quelltext
1: 2: 3: 4: 5:
| passive := true; if (((x1 > x) and (x1 < x + xL)) and ((x2 > y) and (x2 < y + yL)) and ((x3 > z) and (x3 < z + zL))) then passive := false; |
Wichtig: wenn irgendein Objekt blockt, reicht das schon also nicht beim 2. geprüften auf true stellen wenns da geht sondern einmal am Anfang auf true und dann jeweils auf false wenn was blockt. die andern Kollisionen brauchst du dann aber nichtmehr zu berechnen.
mfG,
Hugo343 - Sa 19.09.09 16:36
Ups, ich glaub ich hätte das wohl besser umschreiben können. ja genau den ansatz hatte ich gemacht, nur das ich irgendwo da nen fehler gemacht habe. Was macht das mit den klammern um zwei abfragen für einen sinn? Ich werd mal sehen ob ich das hinbekommen ^^. Vielen Dank nochmal!
nagel - Sa 19.09.09 16:42
Hidden hat folgendes geschrieben : |
Delphi-Quelltext 1: 2: 3: 4: 5:
| passive := true; if (((x1 > x) and (x1 < x + xL)) and ((x2 > y) and (x2 < y + yL)) and ((x3 > z) and (x3 < z + zL))) then passive := false; |
|
Bisschen viele Klammern.
Tobi482 - Sa 19.09.09 16:47
Hi,
Kollisionskontrolle ist ein nicht ganz so einfaches Thema. Da du bereits OpenGL erwähnt hat, wird es vermutlich um einer Echtzeitaniamtion gehen.
Zunächst musst du wissen in welche Richtung es geht: Spiel oder Simulation?
Wenn Simulation dann:
-Was kollidiert?
-Womit kann es kollidieren?
-Sind diese Kollisionen wichtig für die Simlationsergebnisse?
Wenn Spiel dann:
-Was kollidiert?
-Welche Kollisionen sind für den Spielverlauf dringend erforderlich?
-Wie genau muss die Kollision erkannt werden?
Bei Spielen ist es wichtig, die neue Position zu hypothetisch zuermitteln, und dann kontrollieren ob der Schritt druch eine Kollision behindert wird. In diesem Fall darf der Schritt nicht ausgeübt werden.
Viele schwierige multidimensionalen Probleme lassen sich oft, wenn einem klar ist wozu man sie braucht, auf niedere Kollsionen zurückführen. d.h.
-ist die räumliche Ausrichtung für eine Kollision wichtig?
-Wenn nein dann Kugeln nehmen => sehr schnelle und gut optimierente Algorithmen
-Wenn ja reichen AABB's aus?
-Wenn nein, sch****!!! dann wird es kompliziert
Mit ansteigender Objektzahl wird auch deine Kollisionskontrolle in Probleme kommen. Hier sollte der Einsatz von Algorithmen erforderlich werden die "Teilen und Herrschen" => KD-Tree, BSP-Tree, Oct-Tree
Die Strukturen um Kollisionen effektiv zu beherrschen sind nicht ganz ohne. Beim ersten Mal treiben einen nummerische Probleme (Epsilon besser wählen) und Bugs in Rekursionen(blöd zu debuggen) in den Wahnsinn.
Mein Tipp: Bleib in 2D!!!
Da kann man auch schöne Sachen machen und wenn du dich sicher fühlst, dann wage dich an das höher Dimensionale heran. 2D beherrschen wir zum Großteil mit unserer Vorstelllungskraft, 3D unterscheidet sich nichtmehr stark von n-Dimensionen was nur noch schwer mit dem Debugger zukontrollieren ist ohne ständiges nebenherrechnen.
Ich habe mich vor 5 Monaten mit Kollisionen höher dimensionaler Objekte beschäftgt und sie an ihren projektiven Schatten zu erkennen. Es macht Spaß wenn du Mathematik magst aber es kann einen auch in den Wahnsinn treiben^^.
Mit freundlichen Grüßen
Tobi
Hidden - Sa 19.09.09 16:55
Hi :)
nagel: In der Tat :lol: Ein bisschen zur Geschichte, ich hatte da zuerst eine weitere Verknüpfung drin.
and ist natürlich untereinander assoziativ und damit kann man die von dir markierten Klammern weglassen.
mfG,
Hugo343 - Sa 19.09.09 17:02
An Tobi482: Ich hab anfangs auch OpenGL für 2d gedacht, aber ich musste erstmal durch die ganzen Tut's um es zu verstehen. Es gäbe auch 2d aber ich hatte eher an First-Person gedacht (kein Shooter! ^^), jetzt da ich in 3d schon so viel gemacht hab. Und die Kollision wie ich sie beschrieben hab rechnet ja die Bewegung auch aus und setzt sie die Position bei Kollision zurück.
Hugo343 - Sa 19.09.09 19:29
ES KLAPPT!! :dance2: Die Kollision ist etwas zu genau, wenn ich kollidiere dann kann ich schon halb in die Box reinsehen ^^. Auch bleibt man etwas "kleben" weil man sich ja nicht von der Stelle bewegt bis man in eine ganz andere Richtung sieht, also auch kein rutschen am Würfel. Aber darüber mach ich mir noch gedanken. :les:
Hugo343 - So 20.09.09 16:02
Ups... Zu früh gefreut. Da gibt es noch einen Fehler den ich bei mir durch Zufall nicht enddeckt habe. Die Kollision des Würfels wird in irgendeiner Weise an dem 0,0,0 Punkt (wo auch mein Koordinatenkreuz sitzt) "gespiegelt" oder auch invertiert je wie man das nennen mag. Jedenfalls kollidiere ich, wenn mein Objekt die Koordinaten '0,0,0,2,2,2' hat bei '-2,-2,-2,2,2,2' (man könnte auch '0,0,0,-2,-2,-2' nehmen aber bei mir sind die Längen ausschließlich positiv). Ich bin schon selbst am rechnen (die Angaben *-1 zu rechen haben nicht geklappt) aber komme auf keine Lösung wie ich die kollision an die richtige Stelle rücken kann.
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!