High-speed racing collisionen

    • GM 8

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • High-speed racing collisionen

      Ok, ich habe einfach aus kuriosität versucht zu schauen, ob man im GM nicht eine Engine umsetzen könnte, die ähnlich der Spiele
      wie Wipeout oder F-Zero ist. (Insbesondere F-Zero)

      Falls ihr noch nie F-Zero gesehen habt, hier ein Video der N64 Version:
      Spoiler anzeigen
      [video]http://www.youtube.com/watch?v=xf4cWDCnG8s[/video]
      Das ist noch eine verhältnissmäßig leichte (als auch simple) Strecke.

      Dieses video zeigt deutlich wie sich Streckenabschnitte praktisch auf den Kopf "stellen" können: (und es verdeutlich erst recht die hohe Geschwindichkeit...)
      Spoiler anzeigen
      [video]http://www.youtube.com/watch?v=WCjaipqG9Rs[/video]


      Meine Frage: Wie genau funktioniert deren Collisionsengine? Ich habe online mehrere Stunden gesucht, und kam auf keine Ergebnisse. (Vielleicht weil ich die falschen suchbegriffe verwendet habe.)
      Das Problem an der ganzen sache sind nicht nur die Strecken mit ihren drehungen, verzerrungen und verschiedenen formen (tunnel wo man an wänden fahren kann,etc...)
      sondern auch die hohe geschwindichkeit.

      Ich versuchte einfach mal eine Kollision eines 3D Fahrzeugs mit einer Strecke auf der xy ebene umzusetzen.
      Das Problem fing schon da an: Bei hohen geschwindickeiten, konnte der Spieler einfach durch die Sreckenabgrenzungen fahren, da die Kollissionsengine
      be ider hohen geschwindichkeit, die abgrenzung nicht mehr registriert hat.

      Was ich also machte, ist die P3DC Collisions DLL runterzuladen, und raycasting zu implementieren. Nun wird wirklich der Abstand vom Spieler bis zur nächstgelegenen Abgrenzung berechnet.
      Auf die art udn weise kann ich schauen, ob zwischen der aktuellen und der neuen Position des Spielers eine Wand ist. Wenn ja, dann findent eine Kollision statt. (Spieler stoppt vor der Wand.)

      Ich kann mittlerweile nahezu jede geschwindichkeit als Parameter übergeben. Selbst bei 10.0000 Pixeln pro Step, verlässt der Spieler nicht die Strecke.

      Nun kommt aber das Problem: das Rotieren der Strecke und die "hügel" auf der z-achse. Wie genau umgeht man dies? Mit der aktuellen Raycasting methode ist das meines wissens nach nur bedingt möglich.
      Ich kann das Fahrzeug natürlich anhand der Normals der strecke (P3DC unterstützt dies) ausrichten. Das Problem ist, dass wenn der Spieler schnell fährt, der Raycast nicht gebogen werden kann.
      Das bedeutet, dass ich beim Auftreffen eines Raycasts den Winkel der Steigung bzw rotation berechnen muss und dementsprechend einen 2ten Raycast in richtung der gebogenen Strecke nochmal
      "aussenden" sollte. Würde eigentlich funktionieren.

      ABER: Das funktioniert nur, wenn die Strecke eine "Steigung" besitzt. Wenn sie wieder "abfällt" (wie z.B: wenn man von der Spitze eines Berges runterschaut), kann man mit einem Raycast nicht registrieren, ob die Strecke endet oder nicht.
      Dabei war das ziel ja, das Fahrzeug an die Strecke so gut es nur geht zu "binden". Mit der Raycasting Methode wäre dass zwar möglich, aber nicht bie diesen hohen Geschwindichkeiten.

      Hat da irgendjemand eine Idee bzw einen Ansatz wie soch eine Engine eigentlich funktioniert?
      Konkret: wie berechnen sie die collissionen des Fahrzeugs sodass es nicht einfach aus der Strecke fliegt in Kombination mit deren Physics engine? (dass man immer an der Strecke haften bleibt...)

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von LEWA ()

    • Hey, ich habe vor kurzen eine solche Engine im Netz gefunden. Ich schau mal meine Browserhistorie durch und poste dir dann man einen Link^^
      Sieht dem auf dem Video nämlich sehr ähnlich.

      Ich habs ^^

      DOWNLOAD

      Könntest du dass irgendwo anders uploaden? Diese "Captcha" erkennung, hat bei mir rumgezickt und jetzt habe ich keinerlei download berechtigung mehr. X(
      (file-upload.net würde sich anbieten. da kannst du das file mithilfe eines Links auch später vom Server löschen.)

      Kannst doch anhand der FPS eine sichere Kollision berechnen. Gibt ja einige Beispiel für 2D Spiele.

      Das Wäre praktisch dasselbe Prinzip wie bei dem Raycasting was ich verwende. (Ich kann auch die FPS als auch die geschwindichkeit ändern > man fliegt nicht aus der Strecke.
      Funktioniert aber nur auf der xy ebene, ohne Hügel oder rotationen der Strecke.)
      Das hilft mir aber nicht weiter. Die Frage ist ja: Wie schaffe ich es bei hohen Geschwindichkeiten, das Fahrzeug auf der Strecke haften zu lassen und
      zugleich eine perfekte Kollission zu ermöglichen?
    • Ich kenne diese Engine.
      Das Spiel was auf dieser basiert nennt sich "Flying Scrap".

      Das Problem ist, dass es nicht genau diese Transformationen erlaubt die ich aber versuche umzusetzen. (Man kann die Strecke nicht um 90 oder 180 Grad rotieren und der Spieler hafte auf dieser.)
      Starke steigungen sind auch nicht möglich.
      Nebenbei: Wenn man ganz langsam fährt, bemerkt man dass das Fahrzeug zwischen den Polygonen auf und ab "hüpft".
      Perfekt ist das also nicht. Aber anke für den Download.
      Ich nehme blos stark an, dass die entwickelr von F-Zero andere technicken verwendet haben. Schaue mir aber die engine mal an.
    • famous's Ansatz ist der richtige (sofern er das gemeint hat was ich meine :D )
      Die Strecke legst du einfach anhand von Punkt-Paaren (Splines) an (linke und rechte Seite). Diese werden zu einem Band mit dem du jede nur erdenkliche Figur als Strecke machen kannst.
      Kollisionen mit dieser brauchst du aber nicht! Das Spiel läuft in Wirklichkeit nämlich normal entlang der x und y Achse ab. Darauf ist die Strecke horizontal (und gerade!), so dass du relativ einfach die Seiten berechnen kannst.
      Bevor das ganze auf dem Bildschirm kommt müssen nur noch die Koordinaten der Schiffe sowie dessen dreidimensionale Ausrichtung auf die entsprechende Position auf dem Band (der Strecke) addiert werden.
      Hast du z.B. die Punktepaare in einem Abstand von 50 Pixel in einem Array gespeichert, so kannst du leicht ausrechnen wo sich das Schiff auf der eigentlichen Strecke befindet anhand seiner Position auf der x-y - Geraden.
      Die Addition müsstest du über Matrizen erledigen. Eventuell sind GM's transformations-Funktionen exakt das richtige dafür. Kurz gesagt, das Schiff muss so gedrawt werden als sei die x-y Ebene unter ihm stattdessen die entsprechende Ebene auf der Strecke.

      Willst du auf diese Drachen und -eier klicken?
      Sie werden sich freuen ;)

      Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von DragonGamer ()

    • das wäre eine sehr interessante möglichkeit.
      Jedoch stimmt es nicht ganz, dass sich das Spiel auf einer kompletten gerade abspielt.
      Wenn man in den Splines eine Kurve einbaut, die nach links oder rechts geht, so muss das intern auch beachtet werden. Wenn nicht,
      würde das fahrzeug automatisch die kurve fahren, ohne dass der Spieler irgendetwas macht. Man muss aus den Splines dann also berechnen,
      wie stark die kurve auf der internen 2D ebene ist. (Damit der Spieler eben im internen 2D Bereich genauso um die Kurve fahren muss.)

      Das alles erfordert ein relativ breites wissen an Mathematik. (hin udn her transformieren der koordinaten,etc...)
      Schaffbar wäre das auf jedenfall, nur muss man wie eben gesagt relativ gut in Mathe sein. ^^'
    • LEWA schrieb:

      Schaffbar wäre das auf jedenfall, nur muss man wie eben gesagt relativ gut in Mathe sein. '
      Bist du das etwa nicht? :D Immerhin hast du das beste 3D spiel auf GM-D seit langem geschaffen :P

      Ja, mit deinem Einwand hast du recht. Dran habe ich nicht gedacht,
      Die Methdoe müsste aber trotzdem funktionieren. Bei der Umrechnung auf die eigentliche Strecke werden einfach sowohl die x als auch die y-Koordinaten des Schiffes übernommen und auf die Ebene der Strecke addiert. Befindet sich nun das Schiff nicht innerhalb der beiden Punkte, heisst das dass es die Bahn verlassen hat.
      EDIT2: Moment, das klappt so einfach auch nicht! >_> Sorry, mein 2D-->3D-Vorstellungsvermögen lässt mich im Stich... Da ist doch mehr Mathematik von Nöten.

      EDIT: Übrigens nehme ich stark an dass solch eine Methode auch beim n64 Spiel verwendet wurde. Eine richtige Kollisionsabfrage mit dem 3D Modell hätte mit der Leistung der Konsole ja kaum funktioniert...

      Willst du auf diese Drachen und -eier klicken?
      Sie werden sich freuen ;)

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von DragonGamer ()

    • Ich grabe hier mal rum^^

      Ich setze mich seit ein paar tagen auch mit der p3dc.dll auseinander; wenn du einen ray richtung der x bzw y achse, bzw der nase nach, aussendest, warum dann nicht auch entlang der z achse um zu sehen ob die Strecke noch unter dir ist, dann kannst du dei Höhe des Fahrzeuges immer an die Streckenhöhe anpassen, wenn jetzt ein Looping kommt dann wird die distanz von x zur strecke und z zur strecke geringer, daraufhin lässt du die z direction größer werden. Dann sollte sich das Fahrzeug immer parallel zum Boden bewegen. Mitunter musst du das auch für die y direction und achse anpassen.

      Ich habe aber auch eine Frage zu der DLL und ich habe nirgendwo eine gescheite Antwort oder ein Tutorial dafür gefunden; wie benutzt man das ray rotation script? bzw wie kann ich das Kollisionsmodell rotieren lassen, es kommt ja anscheinend immer mit den richtigen Koordinaten mit obwohl man im Step Event nichts anpassen muss, aber ich kapiere nicht wie man in die normale ray collisionsabfrage die rotation einbaut. Die Kommentierung des Scripts hilft dort leider nicht.

      GML-Quellcode

      1. /*
      2. P3DC (Precise 3D Collisions)
      3. V6.00
      4. ----
      5. NOTES:
      6. Check for a collision between a ray(3d vector) and a 3d model that can rotate
      7. ----
      8. ARGUMENTS:
      9. Arg0: model ID
      10. Arg1: model X
      11. Arg2: model Y
      12. Arg3: model Z
      13. Arg4: Ray x origin
      14. Arg5: Ray y origin
      15. Arg6: Ray y origin
      16. [Arg7-9]: Creates a vector that represent the rays direction
      17. Arg7: Vector X component
      18. Arg8: Vector Y component
      19. Arg9: Vector Z component
      20. ...For the vector that represents the models rotation
      21. use p3dc_set_modrot(<...>); <<<<den Teil verstehe ich nicht
      22. ----
      23. Returns the distance to the *closest* triangle that was hit. Returns 10000000 if no triangle was hit.
      24. */
      25. return external_call(global.p3dc_mrs,argument0,argument1,argument2,argument3,argument4,argument5,argument6,argument7,argument8,argument9);
      Alles anzeigen



      Ich weiß das hat nur mehr lose mit dem eigtl Thema zu tun, also Mods gebt bescheid wenn ich dafür einen eigenen Thread aufmachen soll.

      ancient-pixel.com
      youtube.com/user/SebastianMerkl <<< ich freu mich über einen Besuch ;)
    • Benutzer online 1

      1 Besucher