hey.
also ich beschäftige mich erst seit kurzem mit OpenGL und bin grade erst bei "Abeseits Eckiger Welten".
Ich habe schonmal so ein bischen abgefangen einen MapEditor zu machen und habe eine Frage.

Wie macht man ein Kollisionstest.
Ich mein es gibt ja maps, die sind in einem Raster aufgebaut. Für jedes Raster gibt es dann die Information Begehbar oder nicht begehbar. Was ist aber wenn ich eine Welt ohne ein solches Raster habe. Eine einfache 3d Welt.
Funktioniert die Kollision dann über die Objektselektion ?

Gruß
Simon

Die kollision funktioniert definitiv nicht über die Objektselektion, sondern soviel ich weiss über rein mathematische Rechnungen, ich hab davon allerdings nicht alzu viel ahnung, schau dir einfach zb mal den artikel über Bounding Volumes an.

_________________
bester uo-shard: www.uosigena.de

In der SDK befindet sich jeweils ein Beispiel für eine BoundingBox bzw. BoundingSphere.

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

hm.
Das heißt ich müsste alle Koordinaten über Matheatische Errehnungen sperren und irgendwo speichern. hm.. Sehr aufwendig oder ? macht das ein Rechner überhaupt mit oder wird das spiel dadurch zu langsam ?


Gibt es zu dem bounding nen tut ?

Nein, es gibt nur die Beispiele. Das Boundingverfahren versucht eben zu verhindern, dass alle Koordinaten für eine Kollision benötigt werden. In der Regel sind fast alle Gebilde als Boxen oder Kugeln darstellbar um ein Nährungsverfahren zu ermöglichen. Oftmals reicht es aus um ein Raumschiff eine Boundingpshere zu setzen um eine Kollision zu erkennen und zu reagieren. Wurde jahrelang überhaupt nicht anders im 2D-Bereich gemacht. Sollte diese Kollision nicht ausreichen, kann man eine mehrstufige realisieren. So könnte z.B. in einem 3D-Shooter um jede Figur eine großzügige Boundingbox gelegt werden. Schießt jemand auf diese Figur und das Projektil tritt in diesem Bereich ein, beginnt man die Figur in mehre kleinere Bounding-Bereich zu zerlegen um z.B. zu ermitteln, wo genau der Treffer gesehen ist. Wird dann die Schulter ermittelt, könnte man z.B. eine auf Koordinaten basierende Kollision berechnen, die bis aufs Pixel genau ist. Mit diesem Vorgehen lassen sich Kollisionen sehr simple Berechnen ohne das es zu einer erheblichen CPU-Last führt. Die Berechnung einer Box schafft selbst ne alte Krücke ohne Probleme.

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

Gut zu meinem Projekt!

Also so kann ich z.b. um einen Baum ein Bounding Box machen. Das ist eigentlich sehr gut.
Oder um Häuser oder um Personen. So weit so gut.

Also ich bin wie gesagt erst beim Tutorial Abseits Eckiger Welten und fang jetzt an ne engine zu schreiben. Bin grad beim Leveleditor. Weiß zwar nich obs jetzt schon sinn macht anzufangen. Habs aber einfach mal geamcht. Ich füge dann Tutorial für Tutorial sachen hinzu.
Zum meinem Boden ist zu sagen, dass er aus lauter vierecken bestehtt oder aus einer Runden fläche aus dem tut "Abseits Eckiger Welten".
Müsste ich um meinen runden boden dann lauter bounding Boxen legen? oder gäbe es da noch eine andere Möglichkeit ?

Gibt es ein Tutorial zu den Bounding Boxen ?

Erst mal zu den Levels:
Ein Level ist für mich ein Objekt wo du (nahezu) mit jedem 3eck eine Kollisionsabfrage durchführen musst. Hier bieten sich mal ganz grob 3 Alternativen an:

1. Du erstellst dir einen BSP-Baum. Das erstellen ist nicht ganz so einfach, deshalb könntest du dir hier evntl. überlegen bestehende Tools (zB Quake-Level-Editor) zu verwenden, wobei du natürlich etwas auf Copyrights aufpassen solltest aber der Q1-Editor (bzw. compiler) ist zumindest für Hobby-Projekte gratis wenn ich mich nicht irre. Die Kollisionsabfragen selbst sind dann verhältnismäßig einfach zu realisieren.

2. Du zerteilst dein Level in einen Octree, also so dass jeder Knoten nur noch die Dreiecke beinhaltet die für diesen Bereich relevant sind. Evntl. kannst du hier auch statt einem Octree gleich einen 3D-Array verwenden, ist wohl ein klein wenig einfacher zu realisieren, geht aber natürlich etwas auf Kosten von Speicherplatz und wohl auch etwas auf die Performance, und ist nicht ganz so flexibel. Die größe eines Bereiches in einem 3D-Array sollte dann etwas größer sein als die Objekte mit denen du am häufigsten Kollisionsabfragen durchführst (zB Spieler-Objekte).

3. Du erstellst dir Navigation Meshes für deine Level, dies kannst du dann auch gleichzeitig für das Pathfinding von NPCs verwenden. Hier hast du halt das Problem dass du keine richtigen Kollisionsabfragen durchführen kannst, sondern nur für ein konkretes Objekt (zB Spieler) sagst wo es sich überall befinden darf. Wenn du nun andere Objekte hast (zB Schüsse, NPCs mit unterschiedlicher Größe, ...) oder das Objekt auch springen kann und dergleichen, dann bekommst du mit dieser Methode ziemlich schnell ein paar zusätzliche Problemchen. Ist also wohl eine der einfacheren Methoden, jedoch auch die die am wenigsten flexibel ist. Ich würde also eher davon abraten ausschließlich Navigation Meshes zu verwenden.

Nun sprichst du von einer Art Heighmap. Für die Heighmap selbst würde ich eine spezielle Kollisionsabfrage verwenden, wo du beispielsweise an die Heighmap deine X, Y - Position (evntl. auch noch Bewegungsrichtung und Geschwindigkeit) übergibst und deine Heighmap gibt dir dann die relevanten Dreiecke zurück. Danach kannst du diese Dreiecke recht ähnlich behandeln wie Dreiecke deines Levels. Ein Problem das du dir noch durch den Kopf gehen lassen solltest ist, dass du vielleicht später auch mal Höhlen oder einen Keller in einem Haus haben möchtest, also wo du unter der Heighmap landest. Dies ist sowohl beim zeichnen der Heighmap als auch für Kollisionsabfragen insofern wichtig, als dass du hierfür irgend eine Möglichkeit benötigst um Teile deiner Heighmap sowohl beim zeichnen als auch bei den Kollisionsabfragen auszulassen.

Wenn du eine Heighmap hast, dann hast du meistens auch ein paar Objekte darauf (zB Bäume oder auch Häuser also Levels wie oben beschrieben). Diese Objekte kannst du nun wiederum in einem Octree oder Quadtree unterteilen, so dass du nur die Knoten in denen du dich befindest durchsuchen musst. Auch Levels (Häuser oder ähnliches) kannst du in diesem Octree unterbringen, also ein Level sollte dann ebenfalls ein Bounding Volumen besitzen. Wenn du innerhalb des Bounding Volumen eines Levels kommst, so führst du mit diesem Level noch eine genauere Kollisionsabfrage (mit dem BSP-Baum, dem Octree oder was auch immer) durch. Obwohl dieses Problem weniger mit Kollisionsabfragen zusammen hängt möchte ich auch hier darauf hinweisen, dass du dir Gedanken über Höhlen und dergleichen machen solltest, denn wenn eine Höhle 2 oder mehr Ein/Ausgänge besitzt, dann ist es wohl eher schwierig das gesamte (Level-) Objekt Höhle auf deiner Heighmap zu platzieren. Hier bieten sich nun Portale an, wo du in deiner Landschaft nur die Ein/Ausgänge platzierst und durch diese Portale dann in die eigentliche Höhle gelangst.

Ist alles natürlich nur eine Variante das ganze zu lösen, aber ich hoffe ich konnte dir zumindest ein paar Probleme aufzeigen über die es sich lohnt nachzudenken bevor du drauf los programmierst.