Merkwürdige Abfrage von Collisions

    Guten Abend Freunde!

    Vielleicht wird das hier ein interessantes Diskussionsthema bezüglich "Collisions, Gravity und Speed".


    Meist sitzt ja der Bug bekanntlich hinter dem Bildschirm und Computersysteme und deren Programme führen eben nur das aus, worauf sie Programmiert sind. Halten wir das schon mal fürs Protokoll fest.


    Jetzt gibt es aber etwas, was ich nicht ganz verstehe. Ich wollte mir eine Murmel Programmieren, die sich möglichst realistisch verhält. In vielen Spielen fallen Charactere und/oder Gegenstände meist sehr langsam zu Boden. Fast wie in Zeitlupe, könnte man meinen. Das hat mich schon immer gestört. Um eine möglichst realistische Gravitation zu erzeugen, habe ich in den World-Settings die Gravity auf -5000 gestellt. Das scheint für meine Stahlmurmel der richtige Wert zu sein. Sie fällt schön schnell runter, wie bei mir Zuhause, wenn ich eine Murmel aus meiner Hand fallen lasse. Blueprints für die Steuerung habe ich ebenfalls gebastelt. Sie kann sich also in alle Richtungen Bewegen, Springen und Boosten. Als nächstes habe ich mir ein kleines Test Spielfeld aufgebaut mit Cubes. Einen nach dem Anderen aneinander gereiht und bin los gerollt.


    Dabei ist mir aufgefallen: Je schneller meine Murmel rollt, desto mehr kommt sie in Versuchung über Kanten Springen zu wollen, die gar nicht existieren. Ich kann mir gut vorstellen, dass es an den aneinandergereihten Cubes liegt aber diese liegen punktgenau aneinander. Ohne eine millimetergroße Lücke oder ähnlichem. Demnach müsste das eine 100%ig glatte Oberfläche sein, über die es nichts zu Springen gibt. Warum passiert dies trotzdem und wie kann ich das verhindern? Die Gravity habe ich zurück auf Default gestellt aber das ändert rein gar nichts. Warum ist die Unreal Engine4/5 da so pingelig?

    Könnte man da mit "Step Hight" entgegenwirken? Wenn ja, die baue ich dies als Blueprint? Ich frage deswegen, weil meine Murmel kein "Character" sondern ein "Pawn" ist, da gibt es so etwas scheinbar nicht als "CharacterMovement". Oder kann man mit "Damping" dagegenwirken? Ich bin echt Ratlos.

    • Offizieller Beitrag

    Ich vermute, dass liegt an der Interpolation der Kollisionserkennung. Selbst wenn deine Würfel sehr nahe beieinanderliegen, kann es zu Ungenauigkeiten (Rundungsfehlern) kommen.

    1. Ich glaube nicht, dass sich das Problem durch den "Step Height" beheben lässt, da der "Step Height" eine ganz andere Berechnung betrifft und dein Problem offensichtlich mit der Physik zu tun hat und nicht mit dem Überwinden von Hindernissen.
    2. Eine wichtige Rolle spielt möglicherweise das Damping (Reibung). Das Damping ist quasi der Reibungswiderstand deiner Kugel. Keine Ahnung, wie du das Damping gelöst hast, aber wenn dieser Wert bremst und du die Kugel gleichzeitig durch Drücken einer Taste beschleunigst, könnte es unter Umständen zu solchen Problemen kommen. (Das ist nur eine Vermutung.) Ich halte das jedoch eher für unwahrscheinlich.
    3. Suche nach der "Collision Detection Tolerance" (Kollisionserkennungstoleranz). Damit wird die Kollision bei höherer Geschwindigkeit genauer. Ich glaube, du findest sie in den Projekteinstellungen unter "Physics" oder "Collision". Ich bin mir nicht mehr ganz sicher.
    4. Auch das Substepping wäre eine Möglichkeit. Damit wird die Kollisionserkennung in kleinere Schritte unterteilt, wodurch die Kollision genauer wird. Du müsstest diese Einstellung ebenfalls in den Projekteinstellungen finden.
    5. Ich weiß nicht, welchen Collider du für deine Murmel verwendest. Du könntest hierbei ein Mesh als Collider verwenden, das nicht deinem 3D-Mesh entspricht. Die Topologie könnte anders oder besser oder einfacher sein. Ich glaube, es wäre auf jeden Fall einen Test wert, einen anderen Collider zu verwenden. Vielleicht kannst du auch testen, den Collider etwas größer als das Mesh zu machen und beobachten, ob das Problem dadurch besser wird?
    6. Hat es einen Grund, warum du als Boden Cubes verwendest? Vielleicht aus ästhetischen Gründen? Warum verwendest du nicht als Boden Collider einen unsichtbaren Collider, auf dem die Kugel rollt? Dann hättest du eine flache Oberfläche. Als riesige Plane oder du könntest auch eine Collider-Plane unter der Kugel spawnen, die für den Spieler unsichtbar ist und auf der die Kugel rollt. Dieser Collider bewegt sich immer mit der Kugel mit. Wie eine Regenwolke die dem Charakter folgt ^^


    Ich kann nur vermuten, dass das an der Kugel liegt. Denn die Kollisionsbox der Kugel ist ja niemals glatt rund, egal wieviele Unterteilungen der Kollisionsrahmen hat. So mag deine Kugel zwar grafisch glatt und wie eine Kugel aussehen, aber von der Kollisionsbox her sieht sie, wenn ich es mal übertreibe, eher wie ein 20-seitiger Würfel aus einem Pen & Paper Rollenspiel aus, vielleicht ein wenig detaillierter.

    Ich schätze einfach mal, dass es diese Kollisionskannten sind, die dazu führen, dass sie anfängt zu springen.

    Sleepy


    Zu 1.)
    Ich glaube auch nicht daran, es war nur eine Vermutung, wie man dagegenwirken könnte.


    Zu 2.)

    Ich habe mich durch verschiedenste Damping-Einstellungen durchprobiert aber daran scheint es auch nicht zu liegen.


    Zu 3.)

    Das werde ich auf jeden Fall Testen, danke für den Tipp!


    zu 4.)

    Das werde ich ebenfalls Testen!


    zu 5.)

    Hier habe ich auch schon verschiedene Collider getestet aber immer das selbe Problem. Die Kugel hüpft immer nur über die Kanten zwischen den Cubes auf denen sie rollt.


    zu 6.)

    Ich möchte ein Murmelspiel Basteln, welches man aus einem damaligen Community-Projekt noch unter dem Namen "Coockie Rush" kennt. Vielleicht erinnert sich der Eine oder Andere noch daran. Dieses Projekt scheint mir für mich alleine umsetzbar. Hilfe wäre natürlich immer nett aber man findet nicht mehr so gut Hilfe, wie damals :)

    Jedenfalls habe ich hier auch schon unterschiedliche Collider ausprobiert. Immer mit dem selben Ergebnis.


    Tomarr


    Siehe Antwort 5 und 6 für Sleepy :)
    Sogar mit einer "Sphere Collision", die man auch für Reifen von Auto benutzt, funktionieren nicht. Sie sehen zwar Kantiger aus, wie du es mit dem Würfel-Prinzip erklärt hast, haben aber ne saubere Collision. Aber ich bekomme das Hüpfen einfach nicht raus bei erhöhter Geschwindigkeit.


    Ich werde auf jeden Fall Antwort 3 und 4 von Sleepy mal probieren.

    Danke erst mal euch Beiden!

    Ich habe Methode 3 und 4 Probiert aber das hilft leider auch nicht. Gleiches Problem.


    Wobei ich mir bei Methode 3 nicht sicher bin denn die Einstellung "Collision Detection Tolerance" habe ich nicht gefunden. Nur "Collision Margin Fraction" und da passierte auch nichts.

    • Offizieller Beitrag

    Ich glaube Tomarr könnte auch recht haben.

    Deine Kugel ist auf jedenfall nicht perfekt rund und somit ist der Collider der Kugel nicht perfekt rund.

    Wenn deine Kugel von einem Würfel auf einen anderen übergeht, gibt es entweder eine Kollision mit der Oberen Fläche des Würfelns oder mit der Seite des Würfels. Das dürfte davon abhängen wie deine Kugel auf den anderen Würfel aufschlägt.


    Deine Kugel könnte durch die seitliche Kollision abprallen aber du hast aber ne Vorwärtsbewegung was dazu führt dass deine Kugel nach oben fliegt aber auch die Bewegung nach vorne weiter führt.


    Das würde Problem mit dem Übergang der Cubes bestätigen. Wenn du statt Würfels eine Plane als Boden Kollision verwendest, sollte das Problem nicht mehr auftreten.

    Das Problem tritt dabei dann auch nicht mehr auf, wenn ich nur auf einer großen Plane herum rolle. Aber da die Landschafft nun mal aus Blöcken, Loopings, Kurven etc. besteht, komme ich um eine andere Lösung leider nicht drum herum :(

    Sleepy und ich hatten offensichtlich gleichzeitig an der Antwort geschrieben.

    Schalte deinen Viewport doch mal um, sodass dir die Kollisionen angezeigt werden. Vielleicht erkennst du a ja schon irgendeine Unebenheit.

    Ist es eigentlich so, dass deine Kugel auch wirklich rollt? Wenn ja, versuch doch mal, dass sie halt nicht mehr rollt und durchlaufe dann den Parcours. Wenn das dann funktioniert, könnte es durch die Form der Kollision zu einer, wie soll ich sagen, Resonanzgeschwindigkeit kommen, wo dann die Kannten halt doch wichtig werden.

    Die Kugel rollt tatsächlich. Das mit dem "durch Laufen" hatte ich mir auch schon überlegt und es scheint eine gute Idee zu sein nur wie bekomme ich es dann hin, durch einen Looping zu rollen?


    Für so eine Steuerung müsste ich mich mal mit Jemanden von euch im Discord zusammen setzen, wenn ihr da Ahnung habt. Aber das übersteigt schon wieder meine Kenntnisse :D

    Ja, das stimmt auch irgendwie. Aber, kann man die Kollision nicht irgendwie puffern oder so?

    Ich meine, als ich die Engine getestet habe und einige Versuche gestartet habe, da hatte ich zum Beispiel auch mal einen Paintballlevel ausprobiert, mit real großen Kugeln und realer Geschwindigkeit der Paintballs. Das Problem war halt, kleine Paintballs relativ schnell, mit physikalischer Flugkurve. Das führte dazu, dass die Kollision an einer Wand oder einem Objekt eher Glückssache war. Vielleicht kann man mit dem Wissen im Hinterkopf ja Unebenheiten dämpfen oder so.

    Was ich nur irgendwie lustig finde, wir reden hier gerade über ein Problem, welches viele umgekehrt zu lösen versuchten. Ich denke da an ein Tutorial, welches ich mal gesehen habe, wo jemand ein Fahrzeug über Bremshügel fahren lassen hat und es ein großer Aufwand war, dafür zu sorgen, dass die Räder eben bei diesen Hubbeln auch federten. Jetzt scheint es eher in die andere Richtung zu gehen, du willst halt, dass die Kollision zwar genau ist, aber die Kugel diese Hubbel eigentlich nicht beachten sollte.

    Ich versuche mal das Video wiederzufinden, ist leider schon mindestens zwei Jahre her, ist also nicht ganz so einfach. Aber vielleicht findet man ja etwas darüber raus, wenn das Video nicht sogar schon gelöscht ist oder so. In letzter Zeit scheinen viele YouTuber zu denken, dass Google ein Speicherproblem hat. ^^

    Das witzige ist ja, dass da keine Hubbel sind. Klar, es sind zwar aneinandergereihte Cubes und ich versteh auch, dass sich die Engine denkt, dass da Hubbel wären aber für mich als Laie macht das Null sinn. Ich weiß schon, je höher die Velocity in irgend eine Richtung geht, desto schwieriger wird es für die Engine herauszufinden, wo die Collision anfängt und aufhört und da denkt sie wahrscheinlich, dass die Murmel runterfällt aber dann ist da doch noch plötzlich ein weiterer Cube, über den man rollen könnte. Ist mein Gedanke richtig? So würde ich es mir zumindest erklären. Kann mir auch gut vorstellen, dass dieses Problem vielleicht auch abhängig von den FPS ist, wie das Tick-Event zB.

    Ja, also es gibt halt laut meinem Verständnis recht viele Möglichkeiten. Einmal halt der schon erwähnte Würfeleffekt. Und wenn dann die Murmel eine bestimmte Rotationsgeschwindigkeit hat und die Kollisionsabfrage dann halt ungünstig ist, dann schaukelt es sich vielleicht auf. Also quasi so eine bestimmte Resonanzfrequenz oder so.

    Das Andere ist, und das kann man vielleicht sogar lösen, dass die Kollisionskanten, so wie du sagst, aneinander stoßen und die Engine vielleicht gar nicht schnell genug merkt, dass die Kollision durchgängig ist und dann kurzzeitig die Kugel durchfällt und die Engine dann merkt, "halt stopp, da ist doch wieder eine andere Kollisionsbox", also Kugel muss oben bleiben. Das könnte man vielleicht damit bereinigen, dass man die Kollisionsboxen etwas überlappen lässt, zumindest was dann die Enden der Kugelbahn angeht.

    Das Dritte ist, du hast ja auch von Loopings geschrieben, mit Sicherheit auch kurven usw. Vielleicht hat die Engine ja auch Schwierigkeiten in dem Fall den Richtungswechsel schnell genug zu erkennen, also wohin die Kugel rollen soll. Weißt du, dass die Kugel vielleicht dabei ist, an einigen Stellen durch die Kollision zu drücken und die neue Berechnung sie dann erst in die gewünschte Richtung schiebt und das eben halt zu spät oder so. Da wüsste ich jetzt aber am wenigsten eine Lösung.

    Ich weiß allerdings auch, dass viele AAA-Titel unheimlich viel bei solchen Sachen tricksen. Vielleicht denken wir ja auch viel zu sehr in der realen Welt.

    Überlappende Collisions habe ich auch schon probiert - Genau das selbe Ergebnis, wie immer :)


    Ich habe auch schon daran gedacht, eine Fakephysick zu bauen aber da bin ich komplett raus. Da wird sicher viel mit Abfragen, Hits, Overlaps, Linetraces, Velocitys usw. gearbeitet. Ich bin froh, wenn ich es bisher soweit gebracht habe, dass man das Menü bedienen kann, die Murmel steuern kann, die Kamera und das sogar mit Gamepad.


    Also soweit ich das gesehen habe, drückt die Murmel nirgendwo durch. Die wird gut geblockt aber es gibt eben die Probleme, wenn sie von einer Collision auf eine Andere rollt.


    Die AAAs tricksen garantiert aber an solche Fähigkeiten komme ich als Normalsterblicher nicht ran :/

    Zitat von GameMakerXtreme

    Die AAAs tricksen garantiert aber an solche Fähigkeiten komme ich als Normalsterblicher nicht ran :/

    Ja, also auf YouTube sehe ich ab und zu jemanden in den Shorts, der solche Tricks "Aufdeckt". Ja, so als alleiniger Indientwickler würde das teilweise doppelten Aufwand bedeuten. Und wenn ich daran denke, dass ich schon seit fast 8 Monaten an meinem Spiel, mit dem in Ernst machen will, arbeite, und das nur für die Spielsteuerung, die aus ungefähr 680 (bisher allerdings noch nicht optimiert) Seiten Code besteht, wenn ich ihn ausdrucken würde, und das Spiel nicht viel mit Kollision oder schnellen Bewegungen zu tun hat, aber um so mehr mit logischen Verknüpfungen oder so, dann kann ich auf solche Extraarbeit auch gerne verzichten und bete jeden Abend, dass der normale Weg ausreichend ist.


    P.S.: Also das Video kann ich bisher nicht finden. Allerdings weiß ich auch nicht, welche Schlüsselworte ich damals eingegeben habe, für die Suche. Kann aber auch ein Zufallsfund gewesen sein. Aber ich halte die Augen mal weiter auf. Irgendwie muss man dein Problem ja lösen können.

    P.P.S.: Und wo ich gerade das P.S. geschrieben habe, kam mir noch der Gedanke, könnte dir nicht vielleicht ein Pinball-Tutorial weiterhelfen. Ich meine, wenn es um Kugelphysik geht, dann ja in einer Pinballsimulation.

    Wow, Respekt :) Bei C++ Codes kannst du mich gleich in die Ecke stellen. Ich bin froh, dass ich halbwegs verstehe, wie man mit "Visual Scripting" umgeht :D

    Eins meiner Projekte steckt auch seit über 2,5 Jahren in Entwicklung (Youtube Kanal in meiner Signatur: Brick Project Studio). Aber da hatten mir zwei Freunde geholfen, die nun mittlerweile leider keine Zeit mehr haben und ich mich jetzt kümmere, dass ich wenigstens mein Murmelspiel gestemmt bekomme. Ist nicht schlimm, wenn du das Video mit der Reifenphysik nicht mehr findest. Danke auf jeden Fall, dass du dir die Mühe gemacht hast.


    Pinball ist ein sehr gutes Stichwort, da hätte ich auch drauf kommen müssen. Ich werd' mich morgen mal näher damit beschäftigen. Vielleicht finde ich da etwas, dass mir weiterhilft.

    Zitat von GameMakerXtreme

    Bei C++ Codes kannst du mich gleich in die Ecke stellen.

    Na um Himmels willen. C++ habe ich größten Teils aufgegeben. Aber es gibt halt doch das eine oder andere Problem, wo dann BPs nicht ausreichen. Und wenn du erstmal eine C++-Klasse in deinem Projekt erstellt hast, dann kannst du den Rest des Sourcecodes auch in C++ umwandeln lassen, aber weiterhin BPs verwenden.

    Gibt auch irgendwo ein Tutorial dazu. Da kann man dann eine leere C++-Klasse erstellen und das Projekt dann über C++ kompilieren lassen. Daher weiß ich das. Und dann natürlich nur den entstehenden Sourcecode, den du geschrieben hast, anschauen. Einige machen das halt so, keine Ahnung, ob das Spiel dadurch am Ende schneller/optimaler oder was auch immer wird, bei mir passiert es halt notgedrungen, nur weil ich halt zwei Nodes in C++ selber geschrieben habe.