spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Sagen wir du "pickst" mit der Maus auf ein Bild was rotiert ist, um da die Farbe an dieser Position zu bekommen. Dann musst du die Mausposition in den selben "Space" bringen wie das Bild.
Dieses kannst du über "Transformationsmatrizen" ganz elegant lösen. Dann kannst du das Bild skalieren, rotieren oder translaieren wie du möchtest.

Du musst dir das so vorstellen. Es gibt einmal den Worldspace. Das ist im Prinzip das Koordinatensystem deiner Spielwelt. Dann gibt es den Cameraspace, dass ist ein Koordinatensystem welches den Ursprung im Zentrum der Kamera hat (die Kameraposition) und nach der Richtung der Kamera ausgerichtet ist. Das heißt, die Z-Achse geht in die Richtung in die auch die Kamera guckt, die Y-Achse zeigt aus der Sicht der Kamera nach oben und die X-Achse dann zur Seite. Und dann gibt es noch den Objectspace, das ist quasi für jedes Objekt ein lokales Koordinatensystem. Hier funktioniert es im Prinzip wie bei der Kamera auch, nur dass anstatt der Kamera jetzt eben Objekte betrachtet werden.
Das gilt für 3D. Für 2D hast du eine Achse weniger. Wenn du ein Objekt bewegst dann bewegst du das Koordinatensystem des Objektes mit. Rotierst du also dein Rechteck so rotierst du sein lokales Koordinatensystem mit.

Hier kannst du dir das ganze mal ansehen. Das rote Koordinatensystem ist der Worldspace, die blauen sind jeweils Objectspaces von Objekten.

Dein Rechteck ist in seinem eigenen Objectspace selbst nach den Achsen des Koordinatensystems ausgerichtet. Der Cameraspace fällt bei dir möglicherweise weg da du ja vielleicht gar keine Kamera oder vergleichbare Konzepte nutzt. Was du jetzt machen kannst ist einen Punkt aus dem Worldspace in den Objectspace zu übertragen. Das heißt du nimmst die Koordinaten den der Punkt im Koordinatensystem der gesamten Welt hat und rechnest die Koordinaten im Objectspace des Punkts auf. Mal dir das ganze mal auf und mal dir die Achsen der jeweiligen Spaces mit ein. Dann siehst du dass ein Punkt welcher im Worldspace zum Beispiel an Position (7, 39) ist, im Objectspace völlig andere Koordinaten haben kann. Quasi aus der Sicht des Objektes. Überträgst du den Punkt jetzt aber in das andere Koordinatensystem dann interessiert dich danach nicht mehr ob das jeweiligen Objekt skaliert, rotiert oder verschoben wurde. Aus Sicht des Objekts ist das nämlich völlig unerheblich.

Im Objectspace ist das Objekt selbst quasi Zentrum der Welt. Die Umrechnung dazwischen ist nicht so schwer. Such mal nach "world to object space" oder "camera to object space". Da solltest du einige Informationen finden.

http://www.austincc.edu/cchrist1/GAME134…edCollision.htm

Du hast ja sowas wenn beide im WorldSpace sind:
(Die Berechnungen werden dir schwer fallsen so)




Transformiertst du aber dein eines Bild in den ObjektSpace des anderen, sieht es so aus:
(Die Berechnungen sind schon einfacher nun)

Hier kannst du nun über eine Transformationmatrize bestimmen (beim Blauen), die Position jeden Pixel des blauenbildes wo er genau im Space des roten Bildes liegt.

Also kannst du mit einer for-schleife durch jeden diskreten Bildpunkt bei blauenbild laufen.

irgendwie so:


Hab mir den Link nicht wirlich durchgeguckt. Hatte ich über google Bilder gefunden. Aber ich sehe, der Code der da beschrieben wird ist ähnlich wie meiner hier.

Also so ganz falsch kann ich hier gerade nicht liegen.

Aber verwende lieber den auf der Seite. Meinen habe ich gerade so im müden Kopf zusammengeschustert.

Man kann auch irgendwie andersrum rechnen mittels einer inversen Matrix, so dass man sich glaube ich paar Berechnungen erspaart, wenn man nur das rote Bild durchiteriert und dann mittels einer inversen Matrix die blauen Pixel bestimmt.

Ich denke in dem Link wird das dann auch eher so gemacht. Befolge den Link am Besten. Meine Variante ist sicherlich falsch, in so fern.

Aber die Idee müsstest du jetzt haben denke ich. Must dich ein wenig mit beschäftigen denke ich. Ist nicht mal so eben.

Edit:
Hab noch ein wenig gegoogled für dich und habe eine Seite gefunden wo unten sogar ein Projekt drangeheftet ist. Ist aber mit XNA gemacht worden. Aber dennoch kannst da ja mal in den Code gucken.
http://xbox.create.msdn.com/en-US/educat…xel_transformed

Hier ein Video davon:


Hier ist nochmal eine Beschreibung:
http://www.silverlightshow.net/items/XNA…-detection.aspx

Sollte dazugehören.

Wenn man schon Per Pixel Collisionen macht, dann sollte das nicht so aussehen, wie auf diesen Bildern. Der Vorteil von Per Pixel Kollision ist, das Objekte genau dann kollidieren, wenn sich bei der Anzeige auch wirklich ueberlappen. Kein Monitor kann rotierte Pixel so anzeigen, wie du das aufmalst, es wird als wieder Faelle geben, wo sich Objkete optisch beruehren und die Kollision ausbleibt und/ oder umgekehrt. Wieso dann ueberhaupt per Pixel berechnen?

Zitat von »TGGC«

Der Vorteil von Per Pixel Kollision ist, das Objekte genau dann kollidieren, wenn sich bei der Anzeige auch wirklich ueberlappen.

Schwierig wird's aber dann, wenn du zur Darstellung der rotierten Sprites Texturfilterung benutzt (was ja heute üblicherweise getan wird). Dann wird ein Monitorpixel zugleich von z. B. 4 Pixeln von Sprite A und 4 Pixeln von Sprite B beeinflusst. Da müsste man sich überlegen, ab wann man eine Kollision meldet.

In einem anderen, ähnlichen Thema habe ich eine solche Antwort bereits gegeben:

Zitat von »Sacaldur«

Statt einer "pixelgenauen Prüfung" solltest du die Formen deiner Objekte lieber mit geometrischen Formen (Rechtecke und Kreise) annähern [...] und auf Überlappung dieser prüfen.

Spätestens bei unterschiedlichen Auflösungen, mit Animationen oder mit einer anderen Perspektive dürften noch weitere Probleme dazukommen.