Re: Berechnung der Entfernung eines Punktes auf eine Gerade - Programmieren: Software-Entwicklung

Mit Zeichnung wäre es leichter ... so wie es sich es lese:

0.0 Spieler == Kamera == Bildschirm
0.1 Kamera-Transform ist bekannt (vgl. B vs. E)
0.2 Objekt-Transforms sind bekannt
0.3 Objekte und Spieler können als Punkte modelliert werden,
Bounding-Boxes und damit: Schnittpunkte auf Linien müssen nicht
ausgewertet werden (vgl. A, C).
0.4 Es Kollision detektiert werden, wenn eine Minimaldistanz zu einem
Objekt unterschritten wird.
0.5 Das in Z-Richtung der Kamera fokussierteste Objekt, soll
selektiert werden.

Varianten:

A) Wenn Dir librarymässig irgendwas zur Kollisionsdetektion zwischen
zwei Objekten vorliegt, kann man sich Gedanken machen, on eine
(unsichtbare) Bounding-Box um den Spieler formen könnte, sodass man
die Distanzunterschreitung damit modellieren könnte. Beispielsweise:
Spieler ist Kegelstumpf um seine Blickachse, und dann "mitzählen",
mit welchem Objekt zuerst kollidiert wird. Ist natürlich nicht ganz
das gleiche --- hilft Dir aber, per Hand mit Hüllen hantieren zu
müssen.

B.1. Nur Objekte beachten, die im Viewing-Volumen sind, letztlich
also auf dem Bildschirm. Dabei beachten, daß es Objekte geben kann,
deren Hülle im Volumen liegt, obwohl deren Transform ("Punkt")
außerhalb liegt.

B.2. Koordinatentransformation der Objekte in Kamerakoordinaten, also
Multiplikation der Objekt-Transforms mit der Kamera-Transform.
Relevant sind hier [0.3] natürlich nur die Ortsvektoren der Objekte,
aber schon der Skalierbarkeit wegen, kann man auch gleich die ganze
Objekt-Transform nehmen.
Wenn Du sie selber aufstellen musst:
www.3dsource.de/deutsch/3Dmathe.htm

B.3.1.a) Kollision mit abs( p_x, p_y, p_z ) < d
B.3.1.b) Kollision mit abs( p_z ) < d
B.3.1.c) etc.

3.2 Das Objekt mit dem kleinsten abs( p_x, p_y ) ist fokussierteste.
Wenn Du nicht nur unerheblich fandest, sie als "bekannt" anzugeben,
sondern Dir bei der Aufstellung der Kameratransform keine Angaben zur
Perspektive bereitstehen, dann ggf. nur näherungsweise --- sprich
Parallelprojektion (vgl E) kann dabei nicht in p_x, p_y ausdrücken,
wie "aufgeweitet" der Blick am jeweiligen p_z ist. Wenn Du ganau das
gar nicht haben willst, also keinen Blick-Kegel, sondern einen
Blickstrahl, gilt das Gegenteil: setze die Perspektive auf [0 0 0 1].

C) Mit Beginn um die Z-Achse der Kamera quasi raytracen bis zum
ersten Treffer unterhalb Kollisionsdistanz. Kann unter bestimmten
Szenenbedingungen und besonders bei Freiformhüllen unter Ausnutzung,
was in der Grafikkarte abgelegt ist, eventuell günstiger sein.
Gucken, ab welchem Radius nicht mehr Hintergrundfarbe ist, dann
anhand des Z-Buffers rausfinden, welches Objekt da liegt.

D) Wenn Geschwindigkeit das Problem ist, als Denkmodell: Beim
Szenenaufbau ein Raster über die Szene legen, in das z.B. eingetragen
wird, welches das nächste Objekt innerhalb Kollisionsdistanz zum
Rasterelement ist. Das Rasterelement, auf das der Spieler guckt (also
in das der Kameramittelpunkt fällt), braucht dann ohne weitere
Operationen nur ausgelesen zu werden. Scheitert in dieser einfachen
Form daran, daß hierbei die Blickrichtung wieder nicht ganz
berücksichtigt ist, vor allem das Objekt auch hinter dem Spieler
liegen kann. Man könnte aber daran denken, die Distanzvektoren zu
allen umliegenden Objekten innerhalb Kollisionsdistanz darin
abzulegen. Richtungsvektoren (mit Betrag 1) reichen hier bereits, was
Optimierungen erlaubt. So kann es zumindest zur Reduktion der
Echtzeitoperationen beitragen, welche Objekte überhaupt betrachtet
werden müssen. Anderes kann man sich ausdenken. Bewegte Objekte
müssen sich dann in Distanzkugel um sich selbst beim Raster an- und
abmelden. Hängt also von der konkreten Konstellation ab, ob damit ein
Gewinn zu erzielen ist. Zumindest kann es schon eine Hilfe bieten,
welche Objekte (vgl. B.1) überhaupt einer Selektionsbetrachtung
unterzogen werden müssen, wenn man in dem Raster ablegt, welche
Objekte in Kollisionsdistanz liegen.

E) Die Objekte transformieren, dabei die Kamera als
Parallelprojektion modelliert:

Für Bestimmung des kleinsten Winkels ist der eine Vektor [0,0,1], der
andere der transformierte Positionsvektor des Objekts --- also die
bereits die Differenz. Die Auflösung des Vektorprodukts vereinfacht
sich auf
winkel = arccos( p_z / abs( p_x, p_y, p_z ) )

E ist auch für Zentralprojektion dann günstiger als B, wenn der
arccos plus die Division billiger sind als abs( p_x, p_y ) --- und
genau dann ist rinderwahn-Variante noch günstiger, weil dann auch die
Matrixmultiplikation dann trotz ihrer Parallelisierbarkeit doch mehr
als nur eine quasi eintaktige Operation auf einer extra für diesen
Hauptzweck hartverdrahten GPU ist.

Sowie Du allerdings, was real erforderlich oder zumindest
wünschenswert sein dürfte, die Hüllen der Objekte mitberücksichtigst,
die auf Basis der Objekt-Transform definiert sind: Je Vertex sparst
Du mit den Varianten in Kamera-Koordinaten eine Transformation. Ich
würde dabei mit einer Mischung aus B, C, D arbeiten. Den Hüllenaufbau
in ein Raster hineinwachsen lassen, aus dem ich hinterher auslese,
welches Objekt selektiert werden soll. Klartext: die Szene in die
unter voller Ausnutzung der Graphikbeschleunigung in die Backplane
der Graphikkarte rendern, aber ohne Texturen etc., sondern mit planen
"Farben", die nichts weiter als Objektnummern sind, so wie eine
"politische" Landkarte. Das ist die korrekte Lösung für das Problem.