Moin!
Ich habe ein Problem. Und gebe euch jetzt dein einmalige Gelegenheit, euch bei der Lösung des Problems einzubringen und dadurch zu profilieren.

Was ist meine Situation?
Gegeben sein ein Rechteck ABCE. Dieses Rechteck wird beschrieben von einem Rechteck-Ursprung A und zwei Vektoren AB und AC. Ein Punkt liegt im Rechteck, gdw. es eine Vektoraddition A+c*AB+d*AC gibt, mit c und d Element aus dem Intervall [0;1].
Über dieses Verfahren lässt sich sehr leicht ein beliebiger Punkt in dem Rechteck konstruieren.

Was ist mein Problem? (I)
Gegeben sei nun ein Punkt TARGET, wie kann ich algorithmisch bestimmen, ob dieser Punkt im Rechteck liegt?

Was ist mein Problem? (II)
Angenommen, TARGET sei außerhalb des Rechtecks ABCE. Dann soll nun folgender Punkt D gefunden werden:
Gegeben sei ein weiterer Punkt POS innerhalb des Rechtecks. Der Schnittpunkt der Verbindungsstrecke von POS und TARGET mit der Rechtecks-"grenze" sei D.

Wie kann man das nun herausfinden?

Ich habe schon ein paar Ideen, aber nichts, was mich wirklich weiter bringt. Wichtig ist natürlich, dass die Lösungsansätze algorithmisch umsetzbar sind.
Aber auch Lösungsansätze sind natürlich gerne gesehen.

Ich weiß, man könnt das relativ einfach mit Geradengleichungen lösen, ich würde das aber gerne anders lösen.

Hier habt ihr noch mal eine Grafik dazu:
[img]https://dl.dropboxusercontent.com/u/63428639/Bilder/nofollow.png[/img] is not a valid Image.

Greetz,
Fettboy

Transformation des gesamten Systems in ein rechtwinkliges KOS (simple Drehmatrix), welches sich an AC(->y-Achse) und AB(-> x-Achse) orientiert mit anschließendem Check, ob beide Koordinaten von TARGET innerhalb des gegebenen Intervalls [0,1] liegen? Falls nicht -> außerhalb

Bestimmung von D -> Du weißt, dass in deinem neuen KOS der Punkt D immer y = 1 gilt. N bisschen interpolieren und du hast auch die andere Koordinate.


Sollte immer der gleiche Ablauf sein.

Das mit der Transformation habe ich mir auch überlegt, aber da diese Berechnung insgesamt sehr, sehr oft passieren wird, hielt ich das für zu heftig.

Aber wenn man das bei der Initialisierung macht, sollte das möglich sein.

Naja, das ist eine 2 dimensionale Drehmatrix. Das sollte eigentlich recht schnell gehen.

Aber ich hab von der Umsetzung in was-auch-immer keine Ahnung

.sqf

Achso, der Shit ist für Arma?
Naja, 20 Zeilen Code für die Drehmatrix...
Kann dir meine Funktion dafür geben.

->

Ich weiß ja nicht ganz genau, was du machen möchtest, Li...

Aber für (I) könntest du auch einfach n Trigger erstellen mit den Daten, die du hast. Und dann guckste, ob TARGET in der Triggerarea ist.

Naja, die oben genannte Drehmatrix benötigt 0,02ms... kannste also locker perFrame ausführen, wenn du willst.

Problem 1:

Entfernung zu allen 4 Eckpunkten bestimmen, wenn Entfernungen kleiner als Diagonale dann innerhalb des Rechtecks (lässt sich mit ArmA built-in Funktionen schnell ausführen). Ist sehr wahrscheinlich noch effizienter lösbar, kleinere Entfernungen als Diagonale oder nur 3 statt 4 Eckpunkte betrachten etc. aber da mach ich mir jetzt keinen Kopf zu.

Problem 2:

Lässt sich vermutlich ähnlich lösen. Erstmal bestimmen welche Rechteckkante relevant ist (auch wieder mit Entfernungen zu Eckpunkten bestimmen). Gibt aber hässliche Ausnahmefälle in denen Pos eng im Schatten anderer Ecken liegt wodurch evtl. der Schnitt gerade so wo anders sein kann als auf der so bestimmten Kante. Das lässt sich umgehen wenn man auch miteinfließen lässt zu welchen Ecken Pos nahe is.

Alles weitere ist Schnittpunkt zweier Geraden was sich relativ effizient und einfach mit Gaußschem Eliminationsverfahren, O(n*m), lösen lässt. Klingt komplex is aber in der Anwendung easy weil unsere Matrix hier 3 Spalten hat und 2-3 Zeilen (je nach gewünschter Dimensionalität des Rechtecks (ich vermute mal hier ist 2-dim gewünscht)). Naja also eine 2x3 Matrix und das geht ja wunderbar flott zu lösen.
Eventuell, aber ich weiss nich ob, könnte man auch drüber nachdenken die Geschichte in C auszulagern aber ich weiss nicht wie groß der Overhead hier ist und das lösen von 2x3 mit Gauß is wirklich keine Welt.

Eventuell lässt sich der Schnittpunkt auch noch approxmiert statt exakt berechnen aber da fällt mir grad nix ein.