Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Rotiertes Objekt - Per Pixel Collision?

  • 1
  • 2

Werbeanzeige

Urprimat

Treue Seele

  • »Urprimat« ist der Autor dieses Themas

Beiträge: 91

  • Private Nachricht senden

1

26.05.2015, 16:33

Rotiertes Objekt - Per Pixel Collision?

Hallöle,
ich arbeitet gerade an einem Pong remake mit SFML. Ein Feature soll sein, dass man seine Schläger Rotieren lassen kann damit es nicht immer öde "einfallswinklel = ausfallswinkel" ist. Somit könnte man Theoretisch Zielen. Nun habe ich jedoch gerade bei den Kollisionen mit den schräg gestellten Schlägern ein Problem. Ich denke das hier die einfache Kollisions abfrage über die Bounce Boxen nicht mehr reichen wird. Ich hatte mir gedacht das ich einen unsichtbaren Kreis um die Texturen lege und dann über den abstand der Mittelpunkte der Texturen bestimme ob eine Kollision vorliegt (habe den namen der methode vergessen). Falls eine vorliegt geht man dann weiter in die Per Pixel Collision. Nur mit letzterem bin ich nicht ganz zufrieden, da ich eigentlich keine alzugroße Genauigkeit brauche und die Performance darunter leidet. Gibt es einen anderen Weg der mir soagr vielleicht etwas Performance schenkt? oder bleibt mir nichts anderes übrig?


Edit: ich habe wohl einen Denkfeher. Da der schläger ein sehr schmales Rechteck ist. würde der Kreis um dieses Objekt falschen Alarm geben falls der Ball geanu von Vorne kommt. bzw auf die Lange Seite des Rechteckes. und nun?

Grüße Urprimat
Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.

Linus Torvalds

Sacaldur

Community-Fossil

Beiträge: 2 301

Wohnort: Berlin

Beruf: FIAE

  • Private Nachricht senden

2

26.05.2015, 16:48

Statt einer "pixelgenauen Prüfung" solltest du die Formen deiner Objekte lieber mit geometrischen Formen (Rechteck und Kreis) annähern (Schläger durch ein Rechteck, Ball durch einen Kreis) und auf Überlappung dieser prüfen.
Die einzige Besonderheit ist hier, dass das Rechteck nicht an den Achsen ausgerichtet ist, aber das sollte kein zu großes Problem werden, oder?
Spieleentwickler in Berlin? (Thema in diesem Forum)
---

Zitat von »Jonathan_Klein«

Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].

TypeOverride

Treue Seele

Beiträge: 268

  • Private Nachricht senden

3

26.05.2015, 16:55

Einen pixelgenauen Ansatz würde ich auch nicht verfolgen.

Also du arbeitest nicht mit einer Physik-Engine, lese ich heraus.

Als NarrowPhase ist eine BoundingBox schon ok.
Dann kannst du ja den Schläger (mathematisches Konstrukt wäre ein Rechteck dann, zb) zerlegen in dessen Linien (Lines) und dann eine Schnittpunktberechnung (Intersection point) machen.
Und dann anhand der Normalen an dieser Stelle den Reflektionsverktor bestimmen.

Du brauchst nur den Schnittpunkt und die Normale.

Du kannst auch das Rechteck (Schläger) um den Ballradius größer machen und dann den Ball in den Space des Schlägers (Rechteck) transformieren um die Collsion zu berechnen. Dann ist dein Schläger nicht mehr schräg und du kannst wie gehabt das machen. Du must natürlich den Velocity-Vector auch in den Space transformieren.

Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von »TypeOverride« (26.05.2015, 17:07)

Checkmateing

Community-Fossil

Beiträge: 2 218

  • Private Nachricht senden

4

26.05.2015, 17:09

2D-Kollisionserkennung#Kollision_Rechteck-Kreis_.282D.29
:)
Die Eckpunkte kannst du recht einfach bekommen, erst holst du dir das "Grundrechteck" mit getLocalBounds, holst dir die Transformationsmatrix durch getTransform und applizierst die einfach darauf.

MfG
Check
Das gibt Übersicht! Stay gold.

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

5

26.05.2015, 17:20

Einfallswinkel = Ausfallswinkel stimmt übrigens trotzdem. Und das sollte dann auch schon ein Hinweis sein, wie du die Flugrichtung des abgeprallten Balls bestimmen kannst.
David Scherfgens Website | Konzentrationstest Polizei

Urprimat

Treue Seele

  • »Urprimat« ist der Autor dieses Themas

Beiträge: 91

  • Private Nachricht senden

6

26.05.2015, 21:15

Zitat von »Sacaldur«

Die einzige Besonderheit ist hier, dass das Rechteck nicht an den Achsen ausgerichtet ist, aber das sollte kein zu großes Problem werden, oder?

Naja ich dachte das genau das, das Problem ist.

Zitat von »Checkmateing«


2D-Kollisionserkennung#Kollision_Rechteck-Kreis_.282D.29
:)
Die Eckpunkte kannst du recht einfach bekommen, erst holst du dir das "Grundrechteck" mit getLocalBounds, holst dir die Transformationsmatrix durch getTransform und applizierst die einfach darauf.

MfG
Check

Leider verstehe ich nicht ganz was mr das bringen soll...

@TypeOverride: Somit soll die einzelnen Geometrichen Formen zerlegen in Lininen und anhand dieser Strecken die Kollision durchführen. Ich habe noch nie mit Lines gearbeitet, ich lese mich mal ein :thinking:

@David: das stimmt wohl. ich glaube aber es wurde verstanden was ich meinte. ;)
Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.

Linus Torvalds

Koschi

Alter Hase

Beiträge: 657

  • Private Nachricht senden

7

26.05.2015, 21:52

Ich weiß ja nicht, was du von SFML her nimmst aber mit Rect sollte es doch möglich sein zu Prüfen ob dein Ball dein Schläger berührt (auch wenn er rotiert ist).
Wer aufhört besser werden zu wollen hört auf gut zu sein!

aktuelles Projekt:Rickety Racquet

Urprimat

Treue Seele

  • »Urprimat« ist der Autor dieses Themas

Beiträge: 91

  • Private Nachricht senden

8

26.05.2015, 22:07

Ich habe noch keine Zeile Code für die Kollisionen geschrieben. Ich glaube ich geh das auch etwas zu Kompliziert an. Mir war so, dass man das vllt anders regelt als die Simple Collision.

Edit: :golly: Das war jetzt einfacher als erwartet... habe es mit der sf::FloatRect klasse regelt. Ganz wohl fühl ich mich dennoch damit nicht, da mit SFML fast alles abnimmt. :S Naja für den Anfang soll es erstmal so ok sein. Werde mich aber nochmal damit beschäftigen müssen.

Danke für den Link Check!

Urprimat
Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.

Linus Torvalds

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Urprimat« (26.05.2015, 23:05)

Checkmateing

Community-Fossil

Beiträge: 2 218

  • Private Nachricht senden

9

27.05.2015, 08:26

Ich nehme mal an, dass du zuvor nicht auf den Link geklickt hattest und deswegen womöglich nicht wusstest, was ich dir sagen will, andernfalls wäre ich unheimlich verwirrt, da ich mich nicht klarer ausdrücken könnte, sodass du es verstehen würdest.
Aber naja, scheint sich ja erledigt zu haben. Sei mal nicht "besorgt" sondern eher froh, was dir die SFML alles abnimmt, spätestens wenn es mal nicht mehr so "low-level" sein soll, also besonders töfte Bildeffekte und so etwas, wirst du dir vielleicht wünschen, dass sie dir das abnimmt. :P

MfG
Check
Das gibt Übersicht! Stay gold.

Urprimat

Treue Seele

  • »Urprimat« ist der Autor dieses Themas

Beiträge: 91

  • Private Nachricht senden

10

27.05.2015, 09:36

Doch au den Link habe ich geklickt, jedoch ist mir erst klar geworden was du mit Grundrechteck meinst, nachdem ich getLocalBounds in der Doku von SFML gefunden hatte :pinch:

Das mag durchaus stimmen, jedoch mag ich das einfach nicht, wenn ohne mein Verständnis mir arbeit abgenommen wird.
Ich werde mir gleich mal anschauen wie SFML das über intersection() regelt. :?:
Wie gesagt einfache Kollisionen mit achsenorientierten Rechtecken kriege ich ohne Probleme hin. Jetzt dachte ich es wäre eine Wissenschaft für sich, Kollisionen an Rotierten Objekten zu berechnen. :crazy:


Liebe Grüße Urprimat
Most good programmers do programming not because they expect to get paid or get adulation by the public, but because it is fun to program.

Linus Torvalds

Werbeanzeige

  • 1
  • 2

Ähnliche Themen