Problem mit der Kollisionserkennung von einem sich schnell bewegenden ball mit einem Schläger gesteuert durch Maus

In der Einheit, ich habe einen Schläger soll um einen ball zu schlagen, und der Schläger wird direkt gesteuert durch die Maus, ich.e die Fledermaus wird mit der Maus verschoben mit der Maus Achsen und der Verwendung zu verwandeln.translate () - Funktion, bewegen Sie den Schläger.

Erwartete ich, dass Unity3d Physik nicht richtig übersetzen Sie die Schläger-Bewegung direkt die Maus und die Auswirkungen der ball entsprechend, und hätte ich etwas zu schreiben Brauch, und es stellte sich heraus, um wahr zu sein.

Aber der ball Kollision wird nicht richtig erkannt, wenn der Schläger bewegt. Wenn es immer noch ist, ist alles in Ordnung, und der ball verhält, wie ich möchte.

Nun ich ging so weit wie das schreiben eines benutzerdefinierten Physik script (ich nutze C# - scripting), in dem ich befestigt 4 raycasts der Länge 0.6 F auf den ball, und nachdem ich einige der komplexe Vektor-Berechnungen, die Berechnung der Geschwindigkeit des Balles nach dem Auftreffen auf den Schläger, und wenden Sie es direkt auf die Geschwindigkeit der ball mit Festkörper.Geschwindigkeit = calculateVelocity(). Jetzt ist es wieder gut, wenn der Schläger nicht bewegt, aber nicht wenn ich mich bewege den Schläger. Die genaue (Symptome) problem ist:

Verwendung der integrierten Physik-und Kollisions-Erkennung: Wenn der Schläger bewegt sich der ball manchmal pass quer durch den Schläger, und manchmal, verlangsamt es (zu unglaublichen Ebenen).

Mit meinem Skript zum berechnen der Geschwindigkeit: das problem ist Das gleiche, aber es lässt mich erkennen, was falsch ist, wenn ich drucken Sie die normale des collider (die Schläger). Manchmal geben die Recht normal, und irgendwann gibt das negativ des normalen-Vektor, was bedeutet, dass es geradeaus durch die Obere Oberfläche und die Erkennung der Treffer mit der Unterseite des collider (Schläger).

Die Dinge, die ich versucht habe:

  1. Erhöhung der Größe des collider (es funktioniert mit der breiteren box collider auf dem Schläger, aber dann offensichtlich den ball aus einiger Entfernung, Weg von den Schläger, und mein eigenes script hier funktioniert, Standard-Physik seltsame Ergebnisse, wenn Schläger bewegt wird), kurz gesagt ich bekomme nicht die Realität, die ich will.

  2. Verringerung der festen timestamp zu 0,001 deutlich verbessert, aber immer noch sehr sehr weit entfernt von dem Ergebnis, das ich will, und der ball ist wieder ganz oft die Kommissionierung der falschen Seite den ball.

  3. Ändern Kollisionserkennung zu kontinuierlichen dynamischen. Die nicht Dinge verbessern entweder.

Und zusätzlich auf die falsche Seite ausgesucht, bei der Kollision, ein weiteres problem, das ich beobachtet habe ist, dass nach dem abprallen der Schläger, der ball bewegt sich aber der Schläger schneller bewegt, es stattdessen, sich in einem kompletten Bogen oder Linie, irgendwie erscheint vor dem ball, was in zwei Treffern. Es ist eine Vermutung basierend auf dem, was sichtbar ist.

Es ist auch klar, dass die "Bewegung" Aspekt der Schläger ist nicht das vorlesen durch die Unity3d built-in Physik, was ein seltsames Verhalten, wenn Schläger bewegt sich mit der Maus trifft den ball.

Bin ich stecken geblieben, ich habe keine Ahnung, wo sich zu bewegen von hier aus. Bitte sagen Sie mir, was ich falsch mache.

InformationsquelleAutor SpeedBirdNine | 2011-09-09
  1. 8

    Wie andere haben darauf hingewiesen, das problem ist, dass der ball geht von einer Seite der pad in einem Bild und auf der anderen Seite in die nächste. Sich schnell bewegende Objekte neigen dazu, das zu tun, wenn die Barrieren sind zu schmal.

    Es gibt drei sehr einfache Lösungen für dieses problem:

    • Erhöhen Sie die Größe des Pads oder der ball, das ist, was passiert, wenn Sie geändert haben den collider Größe.
    • Etablieren, die eine maximale Geschwindigkeit für den ball, so dass es kann nie schnell genug gehen, durch die pads.
    • Erhöhen Sie die Häufigkeit, mit der die Einheit macht seine Physik-Berechnungen. Es kann geändert werden in Zeit-Manager, die Verringerung der Wert der Festen Zeitschritt. Hüten Sie sich vor der Verringerung dieses zu viel, oder die Physik-engine wird nicht in der Lage, um einen Anruf beendet haben, bevor die nächste Runde starten soll und es wird nie in der Lage sein, um aufzuholen mit dem Spiel.

    Einstellung einer Höchstgeschwindigkeit für das verschieben von Objekten ist etwas, das muss immer gemacht werden. Sie können nicht das Risiko ein, dass ein wichtiges Objekt die Höhe Schießen, während das Spiel und lassen alles in einen unkontrollierten Zustand.

    • Ich habe versucht, die Einstellung der Höchstgeschwindigkeit für beide die Schläger und den ball, kann mir vielleicht erhöhen Sie die Größe der ganzen Umgebung, mag das vielleicht eine bessere chance der Aufdeckung der rechten Seite der collider. Ich werde die Umsetzung der Lösung gegeben, die durch Justin808 und erhöhen Sie die Größe von allem.
    • Diese Sache funktionierte so hervorragend, dass ich doppelt so groß alles, und jetzt es fehlt nicht eine Kollision. Ich habe immer noch das andere problem, die Justin808 davon gesprochen, dass die Schläger in einem moment ist vor dem ball und dem nächsten Bild ist es hinter dem ball, aber zumindest bin ich zu sehen, zwei verschiedene Kollisionen, die behandelt werden können mit code! Vielen Dank! Es dauerte nur 2 min zu tun. Nun bin ich dabei, zu implementieren, Justin Lösung zwei Kollisionen. Von dieser Zeit, wenn jemand eine andere Erklärung, bitte teilen Sie es auch!
    • Ok problem gelöst, ich hatte nicht um einen raycast zwischen der vorherigen und der nächsten position der Kugel, wie jetzt die collider der Schläger fehlt es nicht an den ball. Andere Sache ist, dass Schläger der Bewegung durch die Maus nicht übersetzen, um zusätzliche Kraft auf den ball. Ich hatte zu schreiben, das Teil selbst, und legen Sie istrigger gilt für Schläger collider, so dass die ursprüngliche Physik nicht stören. Aber jetzt gab es ein problem zu schlagen, mehrmals, löste ich es mit einem flag, das wird falsch, wenn Sie getroffen ersten mal, und wahr wieder nach 1 Sekunde, oder wenn der ball trifft ein anderes Objekt. Dieser funktioniert!
    InformationsquelleAutor Elideb
  2. 5

    Was ich denke passiert, ist, dass jedes Intervall, das passiert den ball/Schläger bewegt werden und dann überprüft eine Kollision. Das Problem ist, dass der ball/Schläger bewegen zu weit in ein einzelnes Intervall und miss die Kollision. 

    1) Ball before racquet 
2) Ball after racquet 

not

1) Ball before racquet 
2) Ball touching racquet

    Also, was Sie tun müssen, ist in Ihrem FixedUpdate () - Methode des ball GameObject ist, werfen Sie einen Strahl von der aktuellen ball Position, um den vorherigen ball Lage. Wenn es etwas gibt, zwischen diesen beiden Punkten aufweisen sollte, getroffen wurde (also der Schläger) den ball bewegen, zurück zu den gemeldeten Treffer-Punkt auf dem Strahl. Dies löst Ihre bestehende collision-detection Zeug.

    Den Grund der Erhöhung der Größe der collider funktioniert so gut, weil der ball ist nicht das überspringen der lager-collider. Dies hat die Nachteile, die Sie in Ihrer Frage erwähnt. Die ray-casting vermeidet dieses Problem und ermöglicht den ball/Schläger zu bewegen, so schnell oder langsam wie Sie benötigen.

    InformationsquelleAutor Justin808
  3. 3

    Dies ist keine vollständige Antwort, aber ich erinnere mich an den Umgang mit einem problem, wie dies vor vielen Jahren auf langsameren Maschinen.

    War das problem mit sprite-basierende Kollisionserkennung; sich auf Pixel, die für den sprite und Hindernis gerendert, an den gleichen Koordinaten. Wenn die frame rate ist so niedrig, dass sich das sprite bewegt sich mehr als die Hindernis-Größe in einem Rahmen, werden Sie in Situationen, in denen es (zum Beispiel) Links von dem Hindernis in einen frame und rechts das Hindernis in das nächste Bild, ohne jemals besetzen die gleichen Pixel.

    In diesem Fall sprite-basierte Kollisionen nicht funktioniert, Sie müssen base-Kollisionen auf Vektoren. Anstelle der überprüfung jedes sprite-pixel für Kollisionen, erfassen Sie die position und die konvexe Hülle der sprite. Nach jedem frame, berechnen Sie einen Vektor von der alten position an die neue position und schneiden Sie es mit der konvexen Hülle jedes Hindernis.

    Gibt es mehrere Verknüpfungen, die Sie machen können, wie der Vergleich nur gegen die bounding-Boxen im ersten und die Berechnung der Rumpf nur dann, wenn der Vektor schneidet eine bounding-box, aber das ist die Grundidee. Viel Glück.

    • Die Idee scheint ein guter Ausgangspunkt, aber keine Idee, wie es umzusetzen in Unity3d mit so viel von den eingebauten Sachen wie möglich (ist optimiert). Und über langsamen Rechnern, die ich getestet habe, es auf einem core i7 Rechner mit 6 GB DDR3 RAM und 1 GB ATi Radeon HD5890 Grafikkarte, und sinkt die FPS nie unter 70. Und bitte erklären Sie, welche sprite-based collision detection und ist es das, was Unity3d verwendet? Da bin ich mit Unity3d, ich glaube nicht, dass ich in der Lage zu kontrollieren, die Besonderheiten von collision-detection-Mechanismus, um das Ausmaß
    • Sorry, habe nicht verwendet Einheit. Sprite-basierte Grafik verwenden Sie die tatsächliche frame-buffer für die Berechnungen; wenn Sie mit OpenGL oder ActiveX-Sie sind wahrscheinlich nicht mit sprites. Die Vorstellung der überprüfung der Vektoren gegen die konvexe Hülle für Kollisionen gelten für retained mode-Grafik. Ich kann mir vorstellen Einheit hat eine Möglichkeit zu sehen, wenn ein Vektor schneidet ein Rumpf.
    • Dieser Ansatz ist nicht möglich, wenn Sie 3d-Elemente in der Einheit, wie Kollisionen berechnet werden mit der internen engine PhysX. Aber es ist ein gutes system, das bereits umgesetzt, in den meisten Physik-engines.
    InformationsquelleAutor Dour High Arch
  4. 0

    Ich habe auf einer 3d-pong-Spiel als gut, und haben, laufen Sie in exakt die gleichen Probleme. Ich werde versuchen, vergrößert alles wie Sie Jungs haben. Als für das Paddel hinzufügen von Geschwindigkeit und spin auf den ball, ich war verblüfft über diese, bis ich merkte, dass die änderung der position der Paddel ändert nicht seine Geschwindigkeit. Wenn das Paddel wurde bei einer Geschwindigkeit von null, bevor es verschoben wurde, wird es auf null gesetzt, wenn die Physik-engine sieht es nächsten frame. Un-überprüfung ist kenimatic und Steuern das Paddel direkt über den velocity-Eigenschaft das problem behoben. Es verursacht die Paddel, um jitter, wenn die Wände schlagen, aber ich fest, dass durch das entfernen der Wände von der Paddel-Ebene und der Umgang mit Grenzen manuell in LateUpdate. Auch, wenn Sie aktualisieren Sie die Geschwindigkeit, erste store der neuen gewünschten Geschwindigkeit, in der Aktualisierung, so dass die Kontrollen reibungslos funktioniert, dann übernehmen Sie die änderungen in FixedUpdate.

    InformationsquelleAutor user3495617
Schreibe einen Kommentar