Hi!

Ich finde einfach keine Formel zu Kolisionsberechnung.
Die Formel um die Höhe meiner y Koordinate auf einem dreieck auszurechnen habe ich schon fertig, das andere bekomm ich nicht auf die Reihe, kann mir einer Helfen?
Ihr habt doch bestimmt schonmal soetwas gemacht oder?

Hab das Thema verschoben, da Kollisionserkennung nix mit der verwendeten API zu tun hat.

Aber sag mal genau was du willst? Im Normalfall brauchst du eine Funktion die dir dein Schnittpunkt zwischen einer Geraden und einem Polygon (Dreieck) liefert. Dann repräsentierst du den Spieler durch drei Geraden (für alle drei Achsen) und prüfst dann auf jeder Achse ob und auch wo diese mit einem Polygon kollidiert. Schon hast du eine fertige Kollisionserkennung.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ich meinte so durch mein Level laufen, falls schrägen sind hoch laufen usw. bin in der 10. Klasse, daher fehlen mir Algebra Kentnisse.
Das muss ich halt ausserhalb der Schule jetzt auch noch lernen, aber bis ich da durch steige müsste ich alles Anhalten.

Tja, hatte auch keine Vektormathematik auf der Schule (HH nur Wirtschaftsmathe, HBFS nur in Richtung Elektrotechnik) und habs mir auch mühselig in der Freizeit beibringen müssen. Aber das Prinzip einer Kollsions zwischen Linie und Polygon ist recht einfach : Zuerst prüfst du ob die Linie mit der Flächeentsprechung des Polygons intersektioniert, dann prüfst du ob die Intersektion "im" Polygon liegt. Ist das beides gegeben, so hasste dann den Intersektionspunkt zwischen der Linie und dem Polygon. Da du die drei Achsen des Spielers als Linien repräsentierst haste so direkt Kollisionen mit dem Boden (Y-Achse) und mit z.B. Wänden (X- und Z-Achse) abgedeckt. Auf sulaco gibts z.B. fertigen Code, der dir den Intersektionspunkt zwischen Polygon und Linie ausgibt. Durch die "Kollision" mit dem Boden haste dann also an jeder Stelle des Levels auch gleichzeitig die Höhe des Spielers.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ja siehst, hab ich kein Wort verstanden, ausser das ich mal auf der Webseite da schauen soll.

Wenn de kein Wort verstand hast, bringt dir auch die Funktion zur Ray-Triangle-Intersektion von sulaco auch nix. Am besten schnappste dir halt so wie ich das gemacht hab ein gutes Mathebuch und arbeitest dich durch die Vektormathematik mal durch, denn das Prinzip der Kollisionserkennung ist wirklich alles andere als komplex, man sollte halt nur wissen was dahinter auch abläuft. Wenn dem nicht so ist, wirds spätestens dann frustrierend wenn etwas nicht klappt. Ganz nebenbei sollte man so oder so in Sachen Vektoren (und Matrizen) gut bewandert sein, wenn man sich im Bereich 3D-Grafik bewegt. Da führt halt nunmal kein Weg dran vorbei.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ja, scheisse war...
Mh muss ichs halt mal einstellen, hab nämlich noch in der Schule Prüfungen *kotz neu eingeführt wir sind die ersten*
Schon schrecklich...
Nichts desto trotz (oder wie der spruch heißt) möchte ich mir das mal angucken. Wie immer ich finds nicht, nicht bei den Tuts sowie bei den OpenGL Downloads.

Es ist vieleicht einfacher om nicht direct auf polygon level zu suchen nach einer collision.
In meiner 3D engine nutze ich fur jedes object in der 3d welt ein bounding box (roteded objects sind schwer zu tun(Vektormathematik)). Der camera (der spieler siehe ich als einer sphere).

Dadurch kan ich das volgende nutzen:
if (sqrt(posz*posz) < (zsize/2)+1.7) and ( sqrt(posx*posx) < (xsize/2)+1.7) and (sqrt(posy*posy) < (ysize/2)+1.7) then collision

Vielecht das einfachste was du zuers probieren soltest is een sphere sphere collision.

Sorry for the bad german writing.

_________________
http://3das.noeska.com - create adventure games without programming

OpenGL, ungefähr Mitte, Titel "Line - Polygon Collision Detection".

P.S. : Noeska hat recht, evtl. reicht für den Anfang ne Kollisionserkennung mit AABBs, aber dann sind solche Sachen wie eine Schräge rauflaufen nur sehr bedingt möglich. Also nix für komplexe Umgebungen die eine genaue Kollisionserkennung benötigen.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Hi!

Your german issn't bad

Ich hab mir das Beispiel mal geladen, ist finde ich ganz gut, das ist ja ne eigene Unit. Damit kann ich das vielleicht sogar besser realisieren.

Danke euch.

PS: So ein Mathebuch müsste ich mir mal in der Bücherei ausleihen

Unter diesem Link (grade in google aufgestöbert) wir die Ray-Triangle-Intersection recht ausführlich (in Englisch) erklärt, ist also recht lesenswert.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ich würde das auf jeden Fall eine AABB zur Kollision benutzen, weil man sich damit eine Menge Probleme und Schwierigkeiten ersparen kann. Die AABB muß nicht, und darf auch nicht, bei Spielerbewegungen mitgedreht werden und man prüft bei der Kollision nicht gegen Flächen sondern gegen Brushes. Wenn man nur Flächen hat, dann kann man die ja durch Extrusion zu einer Brush erweitern. Eine Brush ist genauso wie bei Quake eine Liste von Ebenen die den Block einschließen. Falls eine der Ebenen der BBox der Brush nicht zur Brush gehört, dann muß man diese Ebene noch der Brush hinzufügen. Das ist für steile Kanten usw.. wichtig.
Der Vorteil von der AABB im Gegensatz zu reinen Linien besteht darin, daß der Spieler auch ein Volumen hat und man so absolut sicher gehen kann, das nichts in dieses Volumen hinkommt und man so eine sehr solide Kollisionserkennung hat die auch bei kleinen Kanten und Ecken funktioniert und nicht wesentlich aufwändiger als mit einer Linie ist.
Ich würde mir mal die Quelltexte der Quake Engines oder diesen Artikel:
http://www.devmaster.net/articles/quake3collision/ ansehen.

Für eine effiziente Kollisionserkennung, solltest du diese ohnehin hierarchisch gliedern: Quad/OctTrees um nur nahe Objekte zu überprüfen > Bounding Sphere Intersection > eventuell Bounding Box Intersection > und erst dann (wenn überhaupt noch benötigt) die exakte Kollision über eine Unmenge von Line - Triangle Intersections.

Wenn ich dich aber richtig verstanden habe, brauchst du eventuell gar keine "echte" Kollisionserkennung: wenn du z.B. nur auf einem Heightfield herumläufst, berechnest du zuerst die Position des Objekts in den zugrundeliegenden Daten und interpolierst dessen Höhe dann zurecht, was logischerweise viel schneller geht, als gegen die einzelnen Dreiecke zu testen.
Ein Zwischenschritt ist folgender: da du das Heightfield ja erstellt hast, weißt du ja ganz genau, wo sich die einzelnen Schnittpunkte befinden, wenn diese gleichmäßig verteilt sind (fast immer der Fall, ist ja im Prinzip ein 2-Dimensionales Vertexarray) - damit kannst du, Position des Objektes vorausgesetzt, die möglichen Dreiecke mit denen es kollidieren kann, auf zwei reduzieren, was Line-Triangle Intersection wieder sehr attraktiv macht, da dir das exakte Kollisionsdreieck über seine Normale automatisch die "Schräge" zurückliefert.
Wenn du's einfach haben willst, machst du's wie Sacrifice und nimmst diese Normale einfach als Y-Achse des herumlaufenden Objektes .

Je nach Anwendungsgebiet können aber auch unkonventionelle Methoden nützlich sein: Ich bin grad an einem World Builder (eine Geosphere deren Schnittpunkte über diverse Parameter nach außen/innen verschoben werden, und somit mit wenig Aufwand auch komplexe "Planeten" und "Asteroiden" erstellt) - und um auf denen dann herumzulaufen, nutze ich die Tatsache aus, dass diese durch rekursive Dreiecksunterteilung entsteht - daraus habe ich einen Quadtree zusammengebastelt, der nicht auf Vierecken sondern auf Dreiecken basiert (jeweils ein "großes" Dreieck enthält vier kleine) und kann somit jeden beliebigen Punkt mit 10 bis 20 Triangle Intersections auf die Oberfläche projizieren (je nach Komplexität der Geosphere).

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Ne, net so ganz.
Möchte das nicht mit einer Hightmap machen, sondern stell dir wie ein innenlevel vor. Oder aussen, naja auf jeden fall hab ich nen array in dem x,y und z von den dreiecken gespeichert ist. ich wollte einfach überprüfen ob mein Spieler von der x und z achse auf dem dreieck liegt und wenn ja, die höhe des Dreiecks bestimmen. Wenn ich die Höhe der Dreiecke bestimmt habe, gucke ich mir die alte Position an. Dann, wenn ich runter gefallen bin und ein Dreieck ist dazwischen, dann stell ich meine Figur auf das Dreieck drauf.
So wollte ich das realisieren, doch weiß ich nicht wie ich Prüfe ob mein spieler in dem Dreieck ist.

Habe mir das eine Beispiel angeschaut, das geht nur für ein Viereck oder?
Das ist halt doof, oder ich müsste mein Mapformat auf Vierecke umrüsten.

Hab es nämlich wegen der Frames, in Dreiecke unterteilt.

Das von Sulaco? Nein, die Funktion die dort verwendet wird ist doch auf beliebige N-Ecke ausgelegt, und erhält deshalb auch ein dynamisches Vertexarray.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)