Problem mit 2d Kollisionsabfrage

W*lly

@mods
Könnte man hier ent so ne art ignore-funktion einbinden? dann wär tggc bestimmt bei fast allen forum usern auf der ignore list... :p

Aber nichts destotrotz (oder wie auch immer man das schreibt) hab ich mir tggc's tip zu herzen genommen und meinen gehirnschmalz benutzt :p :

Hab mal im mathebuch von der 9. klasse geguckt und hab gedacht das konnte man ja mit linearen funktionen lösen. also wenn nur ein eck im steinrect drin is, dann stellt der ne funktion linearefuntion auf. und checkt dann ob der "funktionsgraph" durch die linke/rechte oder obere/untere seite geht.
aber dann muss ich halt nur vom mittelpunt des balles ausgehen!? kann das so ähnlich funktionieren?

life

guck lieber im mathebuch der klasse 12-13 unter vektorrechnung nach

übrigens war TGGC nicht immer so arrogant und selbstgefällig Unter FAQ hat er nämlich nen paar tutorials zu total banalen Problemen geschrieben.. wirklich erstaunlich

otze

eine genaue kollision zwischen stein/kreis kriegst du nur, wenn du die strahlgleichung in die kreisgleichung einsetzt nach s auflöst,und dann für jede seite testest.
hier mal en bissl arbeit abgenommen:
(x_O+sx_D)-x_M)²+(y_O+sy_D)-y_M)²=r²
.
O ist der startpunkt eines strahls des rechtecks
D ist die steigung des Strahls
M ist der mittelpunkt des Kreises
s ist die stelle der Strecke, an der Der Kreis den Strahl trifft(es gibt 0,1,oder 2 lösungen).
um den echten treffpunkt rauszubekommen,brauchst du nurnoch s*D+O rechnen.

nu viel spaß beim umformen^^

Sgt. Nukem

life schrieb:

übrigens war TGGC nicht immer so arrogant und selbstgefällig Unter FAQ hat er nämlich nen paar tutorials zu total banalen Problemen geschrieben.. wirklich erstaunlich

Um ihm jetzt zuvor zu kommen...:

Er _IST_ es halt!!

life

otze schrieb:

eine genaue kollision zwischen stein/kreis kriegst du nur, wenn du die strahlgleichung in die kreisgleichung einsetzt nach s auflöst,und dann für jede seite testest.
hier mal en bissl arbeit abgenommen:
(x_O+sx_D)-x_M)²+(y_O+sy_D)-y_M)²=r²
.
O ist der startpunkt eines strahls des rechtecks
D ist die steigung des Strahls
M ist der mittelpunkt des Kreises
s ist die stelle der Strecke, an der Der Kreis den Strahl trifft(es gibt 0,1,oder 2 lösungen).
um den echten treffpunkt rauszubekommen,brauchst du nurnoch s*D+O rechnen.

nu viel spaß beim umformen^^

dann musste aber noch abfragen, dass s nicht größer als die länge der Strecke wird und nicht kleiner als 0..

einfacher, aber langsamer ist es, wenn du es so machst:

(Rect.x + n1 - Ball.x)² + (Rect.y + n2 - Ball.y)² <= r²
Und n1 und n2 dürfen nur Werte von 0-Rect.breite bzw 0-Recht.höhe annehmen. Müsste eigentlich auch funktionieren Das funktioniert dann übrigens auch wenn bei ihm der Ball mal wieder mit einem Zug mitten ins Rect fliegt
btw. musste dann bei meiner Variante das ganze mit ner doppelten for-schleife oder so durchgehen..

edit: mit der performancesparenden Variante von otze bekomm ich übrigens mit derive folgendes für s heraus :D:

s = - (sqrt(r^2·(xd2 + yd^2) - xd^2·(ym2 - 2·ym·yo + yo^2) + yd·(xm - xo)·(2·xd·(ym - yo) - yd·(xm - xo))) + xd·(xo - xm) + yd·(yo - ym))/(xd^2 + yd^2) s = (sqrt(r^2·(xd2 + yd^2) - xd^2·(ym2 - 2·ym·yo + yo^2) + yd·(xm - xo)·(2·xd·(ym - yo) - yd·(xm - xo))) + xd·(xm - xo) + yd·(ym - yo))/(xd^2 + yd^2)

W*lly

So...gtu ich glaub das projekt hat sich dann schon für mich erledigt... bin jetzt grad mal in der zehnten klasse und hab von euren gleichungen net wirklich ne ahung. so'n dreck... naja ich schau mal ob ich's irgendwie gebacken krieg. wenn noch irgendwer n tip hat, wär ich trotzdem dankbar.

otze

ich bin auch in der 10. who cares?
ist das ein grund, eine einfache quadratische gleichung nicht auflösen zu können? oder mal im internet nach kreisgleichung oder strahlengleichung zu googlen?

@life jo und nu stell dir das mal im 3d raum vor,dann weiste, was ich da für ne arbeit hatte^^

spl*t

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.

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.

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.

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.

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.

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.

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