OpenGL - Figur auf Landschaft bewegen

thekiller

Viceinator
Moin ;-)

ich möchte in meine 3D-Engine eine einfache Figurbewegung auf einer Landschaft integrieren. So wie es in den meisten Ego-Shootern oder Präsentationsmodi in CAT-Systemen zu finden ist. Dazu habe ich mir seit mehreren Tagen verschiedene Varianten von Kollisionsberechnungen angesehen und komme zu der Frage, welche Variante dafür denn am geeignetsten ist bzw. welche die einfachste Umsetzung wäre.

Für einen guten Rat wäre ich echt dankbar :)

MfG Manuel
 
Hi

ich hab zwar nicht den optimalsten Ansatz, aber könntest du vllt. ein paar Links posten, in denen was sinnvolles war?

Bin selber zurzeit mit sowas beschäftigt.
Hab zwar selber ein paar Ideen, die auch funktionieren werden, aber ob das performancemäßig so toll ist...?

Gruß
 
Hi sheel,

naja ich habe jetzt keine Links die was mit der Bewegung einer Spielfigur auf 3D Terrain zu tun hat. Nur der ganze Kollisionskram. Kollisionen erkennen mit Bounding Boxen oder Spheren, Polygonschnitterkennungen mit Strahlen oder anderen Primitiven etc.

Mir dem was ich so alles gelesen habe, habe ich mir folgende Methode gedacht.

Ich Speichere bei jedem Frame die aktuelle Bodenposition der Spielfigur (wo die Füße sind sozusagen) und beim folgenden Frame prüfe ich ob zwischen den beiden Koordinaten eine Kollision stattgefunden hätte. Wenn eine Kollision mit dem Boden stattgefunden hätte, berechne ich den Kollisionspunkt und verschiebe die Spielfigur an diese Stelle. Also dass wäre die erste Variante die mir dazu einfallen würde. Leider habe ich mit Kollisionsberechnung selber noch keine Erfahrung gemacht um einschätzen zu können, ob diese Methode praktisch und wenig Rechenintensiv ist.
 
Zuletzt bearbeitet:
naja ich habe jetzt keine Links die was mit der Bewegung einer Spielfigur auf 3D Terrain zu tun hat. Nur der ganze Kollisionskram.
Genau das meinte ich ja :D

...Kollisionen erkennen mit Bounding Boxen oder Spheren, Polygonschnitterkennungen mit Strahlen oder anderen Primitiven etc....prüfe ich ob zwischen den beiden Koordinaten eine Kollision stattgefunden hätte. ...berechne ich den Kollisionspunkt und verschiebe die Spielfigur an diese Stelle....selber noch keine Erfahrung gemacht um einschätzen zu können, ob diese Methode praktisch und wenig Rechenintensiv ist.

Dann haben wir ja ungefähr die gleichen Gedanken.
Erfahrung fehlt mir genauso, aber ich machs eben, wie es mir am besten erscheint.

Nur mal vereinfacht, dass die Spielfigur ein einzelner Punkt ist, denkt man sich eine Strecke von der Figur in die Bewegungsrichtung. Anfang Figur, Ende ist eben ein Punkt in der Richtung. Entfernung kann über die Geschwindigkeit ermittelt werden.

Wenn die Linie nirgends "durchbricht", alles ok, bewegen.
Wenn doch: Entfernung Spieler-Kollisionspunkt ermitteln und dorthin bewegen
Wenn mehrere Kollisionen: Die näheste zum Spieler.

Zum Kollisions-Überprüfen muss man alle Ebenen jedes Objekts durchgehen.
Optimieren kann man das Ganze schon einmal, in dem man alles "hinter" dem Spieler etc weglässt.
Oder nur das Achtel des Koordinatensystems überprüfen, in das er sich hinbewegt.
Oder...

Für alles bisherige lohnt es sich übrigens, eine gute Lektüre zur Vektorrechnung durchzunehmen.
Nicht nur das, was man in der Schule lernt, sondern mehr eben.
Da gibts ein paar nette Methoden, mit denen man sich viel umständliche Rechnerei erspart (und Performance gewinnt).

Was ich noch für sinnvoll halte: Nicht nur den Spielern und anderen beweglichen Sachen Boundingboxen verpassen, sondern auch der festen Welt: Und diese schachteln.

zB immer 4 Körper in eine BBox, dann immer 4 Boxen in eine BBox...bis nur noch eine Box übrigbleibt.
Das alles natürlich nicht ständig während der Laufzeit, sondern beim Laden etc.

Wenn man zuerst nicht weiß, wie die "Welt" aussehen wird:
Eine Möglichkeit wäre zB:
1) Ermitteln, wo die meisten unbearbeiteten Elemente sind.
zB den Durchschnitt aller Koordinaten als Punkt, und dort rundherum.
2) Mit dem Punkt als Mittelpunkt eine Box herumlegen.
Größe hängt zB ab, wie das Verhältnis zwischen Volumen und Anzahl der enthaltenen Elemente ist.
Hab da allerdings noch keine guten Erfahrungswerte dafür.
3) Die enthaltenen Elemente nimmst du aus der "Unbearbeitet"-Liste raus und fügst dazu die Box dazu.
Damit auch die Boxen wieder mitgeschachtelt werden können.

Gruß
 
Dann war ich ja doch nicht ganz auf dem Holzweg^^
Dein Weg ist ja echt fast genau derselbe wie meiner.

Um noch etwas Performance zu sparen könnte man ja auch noch einen bestimmten Bereich um die Figur prüfen. Ach ich bin so schlecht im Erklären^^
Also ich mein nur für die Polygone eine Kollisionsberechnung durchführen die in einem bestimmten Abstand zum Bewegungspfad befindlich sind. So ein Terrain kann ja schonmal etwas größer sein und da muss man ja nicht alle Polygone berechnen.

Aber du hast mir auf jedenfall geholfen danke =)

MfG Manuel
 
Also ich mein nur für die Polygone eine Kollisionsberechnung durchführen die in einem bestimmten Abstand zum Bewegungspfad befindlich sind. So ein Terrain kann ja schonmal etwas größer sein und da muss man ja nicht alle Polygone berechnen.
Ich denke, wenn man wirklich die ganzen BBoxen schachtelt wie beschrieben, dann erledigt sich das von selbst.
Wenn sich der Zielpunkt der Bewegung in keiner der (sehr wenigen) äussersten BBoxen befindet, kann man den Rest schon lassen.
Das sind vielleicht 3 oder 4 Verleiche von xyz-Koordinaten

Aber du hast mir auf jedenfall geholfen danke =)
Kiene Ursache :)
Bin zurzeit sowieso der Materie drin.

Gruß
 
Ich habe selbst eine Spielengine bei der auch das von euch angesprochene Thema eingebaut ist. Dabei habe ich folgenden Ansatz implementiert:
1. Voraussetzung: Mein Terrain ist in viele kleine logische Abschnitte unterteilt.
2. Wenn sich der Spieler bewegt wird diese Bewegung zuerst nur 2-dimensional ausgeführt. Sprich, es wird Schrittweite * Schrittrichtung berechnet.
3. Diese Bewegung wird dann gedrittelt und für jeden der 3 Punkte die Höhe berechnet.
4. Anschliessend wird jeweils so viel weg zurückgelegt, dass es der maximalen Schrittweite in diesem Frame entspricht

Das Berechnen der Höhe wird über mittels D3DXIntersect gemacht (DirectX, OpenGL hat sicher eine ähnliche Funktion) mit dem jweils passenden kleinen Teil des Terrains. Das ist sehr schnell und auch genügend genau.
 
Hallo Cromon,

deine Variante klingt auch recht interessant. Allerdings kann ich sie nicht ganz nachvollziehen.

Punkt 1:
Ist klar.

Punkt 2:
Man berechnet über die Richtung und der Schrittweite den Punkt auf der X und Z Ebene richtig? Wird die Drehung um die X-Achse dabei berücksichtigt?

Punkt 3:
Was genau wird gedrittelt? Die gerade auf der XZ-Ebene vom Start bis Endpunkt? Wozu die Einteilung?


MfG Manuel
 
Ich habe mal ein kleines Bild angehängt:
Der rote Punkt ist das Objekt, das sich bewegt. Der rote Pfeil gibt an, wie weit das Objekt sich bewegen könnte, wenn keine Steigung da wäre. Diese Strecke wird dann gedrittelt (oder einfach so geteilt, dass selbst bei der maximal erlaubten Steigung die Strecke pro Unterteilung nicht länger wird als die maximal erlaubte Distanz. Anschliessend nehmen wir so lange Weg von diesen drei Teilen bis wir die Schrittweite erreicht haben.
 

Anhänge

  • Moving.jpg
    Moving.jpg
    13,7 KB · Aufrufe: 23
Ah dass ist einleuchtend danke!
Man muss im grunde aber 4 mal die Höhe berechnen für die Endgültige Position oder?
Also nachdem man die 3 Unterteilten Schritte hat und dann über den "Pfad" die Endposition (XZ) mit der maimalen Schrittlänge pro Frame berechnet hat. Wenn Ein Höhenunterschied auftritt Zwischen Start und Endpunkt, dann ist die Distanz vom Startpunkt zum letztendlichen Endpunkt ja gerunger.
Ach man ich bin heute zu müde für das Thema glaub ich^^

Eine Sache interessiert mich allerdings noch.
Ich habe auf folgender Seite einen Algorithmus zum ermitteln eines Schnittes zwischen einem Dreickspolygon und einem Strahl gefunden.

http://www.softsurfer.com/Archive/algorithm_0105/algorithm_0105.htm#Segment-Triangle

In dem Textabschnitt finde ich folgende Formel

n = (V1-V0)×(V2-V0)

n soll ja der Normalenvector sein und V0, V1 und V2 die Punkte es Triangles.
Wie soll man z.B. V1-V0 verstehen? Wie soll man die genau Subtrahieren?
Die Vectoren enthalten ja schließlich die 3 Koordinaten X, Y und Z.
Muss man da einfach z.B.

V1.X - V0.X
V1.Y - V0.Y
V1.Z - V0.Z

rechnen?
Ich hab irgendwie noch nie bei diesen Formeln durchgesehen...

MfG Manuel
 
Zuletzt bearbeitet:
Zurück