Problem mit 2d Kollisionsabfrage

randa

Vielleicht ist es so etwas vertsändlicher:
du hast die zwei geraden, die seite(n) deines Steins und den vektor.
Die gerdanegleichung der seite deines Steins (wir nennen sie a):
a: ax+bx=0
und des vektors b:
b: dx+ex=0

Die Koordinaten des Schnittpunkts sind die, die bei den beiden obigen gleichungen gültige Werte erzeugen.
Setze die eine gleichung in die andere ein, und löse auf.

Soviel hab ich noch im kopf, ich bin mir nicht sicher obs im Detail stimmt, aber im großen und ganzen...

Sowas hat man übrigens bis zur zehnten schon gemacht, erinnere dich dunkel an funktionen (in der 8?) bzw. quadratische funktionen (9te?).
Du kannst ja auch deine(n) Mathelehrer(in) fragen.

life

spl@t schrieb:

ich versteh nicht ganz, wieso alle meinen Post ignorieren. Weil life irgendwelchen unpassenden Kommentare dazu gegeben hat?
Ich glaub ich mach doch folgendes:

life schrieb:

"Naja, hab ihn überflogen, weiß auch nicht wie ich gerade darauf gekommen bin dass die Richtungsänderung ein ungelöstes, und die Kollision ein gelöstes Problem ist... Sorry"

warum gehste dann nur auf die Kollision ein und nicht wie man rausfindet obs eine "x-Kollision" oder "y-Kollision" ist?

Ich bin auf die Richtungsänderung (Umkehrung des Vektors) eingegangen, nicht auf den entsprechenden Kollisionsalgorithmus zum bestimmen ob x-oder y-Kollision. Ich weiß wie geschrieben, dass das falsch war.

Klar bist du auf den Kollisionsalgorithmus eingegangen. Lies dir einfach mal deinen eigenen post durch

spl@t schrieb:

life schrieb:

"Aber wenn man das Spiel spielt, merkt man nicht viel von Problemen bei der Kollision."

Mit der Kollision nicht, aber mit der RIchtungsänderung...

Nein, die Richtungsänderungen stimmen, der Ball prallt ordentlich von den Wänden ab, die Kollision ist das Problem.

Die Erkennung, wie die Richtungsänderung genau aus sehen muss, ist das Problem. Diese hängt nämlich davon ab, welche seite ich vom rechteck treffe (oben/unten oder links/rechts). Die Kollision selber wird aber zuverlässig erkannt..

spl@t schrieb:

life schrieb:

"Wie würde es eigentlich aussehen, wenn du einfach immer annimmst, dass es sich um eine Kollision mit der Unter - bzw. Oberseite des Steines handelt, und immer den y-Vektor umkehrst? "

Warum löst er nicht einfach das Problem anstatt es zu ignorieren?

Das Problem wird nicht ignoriert sondern auf sehr einfache Art gelöst.

du löst es, indem du es ignorierst

spl@t schrieb:

life schrieb:

"das Problem, dass der Ball zu viele Steine hintereinander abräumt sollte auch gelöst sein"

nein?

Wenn er von der Seite kommt, würde er seine Richtung frühzeitiger ändern und eine Kollision mit der nächsten Schicht wäre nicht möglich.

er würde seine y richtung ändern und wenn unter dem getroffenen Stein wieder ein Stein ist, würde er wieder hochfliegen und damit gleich 2 reihen aufeinmal abräumen

spl@t schrieb:

life schrieb:

"und du kannst auf das Rechteck um den Ball verzichten und erreichst somit auch bei nem großen Ball pixelgenaue Kollision. "

Nein. Du legst auch ein Rechteck um den Ball..

Quatsch, wo denn ? Es wird der Radius des Balls mit benutzt (bezieht sich ja alles auf den Pseudocode von oben).
Übrigens hab ich selbst erst die Kollision bei einem Pingpongsspiel so realisiert, und wenn ich mit mehreren Bällen spiele, ist die Kollision der Bälle untereinander eindeutig pixelgenau (naja, fast ), selbst wenn diese den viertel Bildschirm ausfüllen.

ist sie nicht. Beispiel:

ypos des Balles: 100
xpos des Balles: 100
radius des Balles: 50
xpos vom rechteck: 200
ypos vom rechteck: 200
breite des rechteckes: 100
untere Ecke vom Rechteck ist damit bei 150/150 und damit NICHT im kreis (50^2 + 50^2 > 50^2)
Also eine Kollision darf hier eindeutig NICHT stattfinden. Mal sehn was dein Algorithmus dazu sagt:

"if yPos des Balls + Radius < yPos des Steins - halbe Höhe "
if(100+50 < 200-50) --> false
also weiter
"if yPos des Balls - Radius <= yPos des Steins + halbe Höhe "
if(100-50 <= 200+50) --> true
also weiter
"if xPos Ball + radius >= xPos Stein - Steinbreite/2 oder xPos Ball - radius <= xPos Stein + Steinbreite/2 "
(muss und heißen sonst machts eh keinen sinn daher: )
if(100+50 >= 200-50 und 100-50 <= 200+50) --> beides true also kollision

Soviel zu "pixelgenau"

spl@t schrieb:

Wo verdammt nochmal liegt das Problem? Ich sage ja nicht, dass es auf beschriebene Weise 100% gut aussehen muss, aber nen Versuch wärs wert.

naja.. dein Algorithmus löst nunmal nicht das eigentliche Problem. Warum sollte man einen Argorithmus ausprobieren, der mit dem Problem garnix zutun hat? oO

otze

achja, noch ne sache zu der gleichung oben:
um im endeffekt rauszubekommen, wie der ball abprallen muss, muss man den winkel des schnittpunkts in relation zur bewegungsrichtung kennen und dann einfallswinkel gleich ausfallswinkel gelten lassen.

life

otze schrieb:

achja, noch ne sache zu der gleichung oben:
um im endeffekt rauszubekommen, wie der ball abprallen muss, muss man den winkel des schnittpunkts in relation zur bewegungsrichtung kennen und dann einfallswinkel gleich ausfallswinkel gelten lassen.

das hatte er ja schon gelöst ..

otze

ich sollte echt mal den thread von anfang an durchlesên

aber ansonsten müssten alle klarheiten von uns erfolgreich beseitigt worden sein oder?

W*lly

randa schrieb:

Vielleicht ist es so etwas vertsändlicher:
du hast die zwei geraden, die seite(n) deines Steins und den vektor.
Die gerdanegleichung der seite deines Steins (wir nennen sie a):
a: ax+bx=0
und des vektors b:
b: dx+ex=0

Die Koordinaten des Schnittpunkts sind die, die bei den beiden obigen gleichungen gültige Werte erzeugen.
Setze die eine gleichung in die andere ein, und löse auf.

Soviel hab ich noch im kopf, ich bin mir nicht sicher obs im Detail stimmt, aber im großen und ganzen...

Sowas hat man übrigens bis zur zehnten schon gemacht, erinnere dich dunkel an funktionen (in der 8?) bzw. quadratische funktionen (9te?).
Du kannst ja auch deine(n) Mathelehrer(in) fragen.

ja genau! so in der art hab ich das ja auch gemeint. aber trotzdem müsste es
ax+by=0 und dx+ey=0 heißen. das macht man übrigens in der 9. klasse! und so würde das dann aber richtig funktionieren? seh ich das jetzt richtug?

aber da hab ich dann trotzdem noch ne frage...
du hast gemeint die gleichung der seite des steines wäre dann:
ax+by=0! aber das geht ja dann nur bei den seiten oben und unten!? bei den "seitlichen" seiten also links/rechts geht das ja gar nicht. das wäre ja dann gar keine funktion. der graph geht ja dann einfach nur senkrecht hoch und somit werden einem x wert mehrere y werte zugeordnet und das ist dann glaub ich ne relation (hab ich glaub ich mla irgendwo aufgeschnappt )! aber es ist 100% keine funktion...

otze

funktioniert aber trotzdem

life

? bei den waagerechten wäre die gradengleichung in normalform: y= Rect.y bzw y = Rect.y+ Rect.höhe und die senkrechten gradengleichungen wären: x = Rect.x bzw x = Rect.x+ Rect.weite >_<
Dann berechneste den Schnittpunkt mit der Gradengleichung vom Bewegungsvektor und guckst ob der Schnittpunkt auch im rect liegt. Dann weißte den genauen Kollisionspunkt und du weißt mit welcher Seite dein Ball kollidiert ist. Damit kannste dann die Position des Balls auf den Kollisionspunkt setzen (sofern es wirklich eine kollision gab) und kannst die Richtung des Balls entsprechen ändern. Damit wäre also alles gelöst oder? Ich glaub das ist jetzt so auch die beste und einfachste Lösung

TGGC

W@lly schrieb:

dann wär tggc bestimmt bei fast allen forum usern auf der ignore list...

Und nur noch wenige würden wirklich voran kommen.

Bye, TGGC \-/

randa

@W@lly: Ist es wirklich festgelegt, dass es dy heißen muss?
Eigentlich egal. Die Unterschiedlichkeit habe ich einfach durch a bzw b bzw d bzw e anzeigen wollen. du kannst ja auch ax und ay schreiben. ax und by wäre theoretisch falsch.

life

randa schrieb:

@W@lly: Ist es wirklich festgelegt, dass es dy heißen muss?
Eigentlich egal. Die Unterschiedlichkeit habe ich einfach durch a bzw b bzw d bzw e anzeigen wollen. du kannst ja auch ax und ay schreiben. ax und by wäre theoretisch falsch.

es heißt ax+by=0.

(a)     (x)     (a)    (x1)
( )  *  ( )  =  ( ) *  (  )
(b)     (y)     (b)    (y1)

<=> ax + by = a*x1 + b*y1

Wobei x1 und y1 ein Punkt auf der Geraden darstellen. Wenn die Gerade durch den 0 Punkt geht, ergibt das ax + by = 0

randa

TGGC schrieb:

Und nur noch wenige würden

...sich an dir stören

W*lly

also ich hab mir jetzt nochmal ein paar gedanken gemacht aber irgendwie krieg ichs net gebacken. des is jetzt auch zum ersten mal dass ich so "richtig" was mit kollisionsabfrage machen muss und vektoren usn so'n kram also bitte net wundern!
Hab da jetzt noch ein paar fragen:
also wegen den gleihcungen...dees heißt ja:
ax+by=c
dx+ey=f
und nicht =0! zumindest laut mathebuch und ist ja auch eigentlich klar... aber woher kenn ich die wrte c und f? bzw. wenn die 0 sind warum denn?
und außerdem: bei der vektoren gleichung; was ist da mein a und mein b? sind das einfach nur die vektoren für die verschiebung auf der x bzw y achse? und x und y is einfach unrn die aktuelle position vom ball?
wie gesagt ich mach jetzt zum ersten mal sowas also bitte net schimpfen!
ich hab auch schon rumgegooglet und so aber die guten seiten sind meist auf englisch uund oftz is es auch net was ich brauch. wär net wenn ihr mir weiter tips dazu geben würdet unnd vllt auchn link zu so kollisionsabfragen allgemein(eher 2d) dass ich mir das ganze theam auch nochmal alleine durch den kopf gehen lassen kann.

Thx im Voraus!

life

W@lly schrieb:

also ich hab mir jetzt nochmal ein paar gedanken gemacht aber irgendwie krieg ichs net gebacken. des is jetzt auch zum ersten mal dass ich so "richtig" was mit kollisionsabfrage machen muss und vektoren usn so'n kram also bitte net wundern!
Hab da jetzt noch ein paar fragen:
also wegen den gleihcungen...dees heißt ja:
ax+by=c
dx+ey=f
und nicht =0! zumindest laut mathebuch und ist ja auch eigentlich klar... aber woher kenn ich die wrte c und f? bzw. wenn die 0 sind warum denn?
und außerdem: bei der vektoren gleichung; was ist da mein a und mein b? sind das einfach nur die vektoren für die verschiebung auf der x bzw y achse? und x und y is einfach unrn die aktuelle position vom ball?
wie gesagt ich mach jetzt zum ersten mal sowas also bitte net schimpfen!
ich hab auch schon rumgegooglet und so aber die guten seiten sind meist auf englisch uund oftz is es auch net was ich brauch. wär net wenn ihr mir weiter tips dazu geben würdet unnd vllt auchn link zu so kollisionsabfragen allgemein(eher 2d) dass ich mir das ganze theam auch nochmal alleine durch den kopf gehen lassen kann.

Thx im Voraus!

also die gleichungen für die Rechtecke hast du ja (hab ich ja oben schonmal geschrieben). Um nun die Gradengleichung für den Ball zu bekommen, musst du zunächst den Normalvektor zum Geschwindigkeitsvektor bestimmen. Da das ganze 2D ist, ist das ganz einfach: Der (ein) Normalvektor zum Geschwindigkeit- / Richtungs- vektor [a,b] (das sind die "Veschiebungen auf der x-Achse (a) und y-Achse (b)" xD) ist [-b,a]. Nun haste schonmal den ersten Teil der Gleichung: -b*x+a*y = ???. Um das "???" rauszubekommen, multiplizierst du einfach den Normalvektor mit der aktuellen Position des Balls: [-b,a] * [Ball.x,Ball.y] = -b*Ball.x+a*Ball.y.
Also ergibt sich für die Geradengleichung des Balles beim Geschwindigkeitsvektor [a,b]:
-bx + ay = -b*Ball.x+a*Ball.y

Wenn der rechte Teil 0 ist, heißt das einfach, dass die Gerade durch den 0 Punkt geht, da dann die Ballposition ein vielfaches des Geschwindigkeits/Richtungsvektor (nenns wie du willst >_<) ist, und der Normalvektor * Ausgangsvektor immer 0 ergibt

TGGC

Also es sollte doch kein Problem sein, line-line-intersection bei google zu finden! Englisch, na und? Zeichnungen/Formeln/Code sind sowieso international.

Bye, TGGC \-/