Hallöchen!

Kurzbeschreibung:
Ich benötige eine Funktion, welche mir durch einen Klick in meine gerenderte Szene ausgibt welche Texturkoordinaten getroffen wurden.
Und das selbe Spiel rückwärts: eine Funktion die ausgibt auf welche Fensterkoordinaten ein Punkt aus der 3D-Textur (projiziert) treffen würde.

Details:
Ich habe eine Ortho2D Projektion und ein Viewport irgendwelcher Größen (veränderbares Fenster), das Viewport nimmt nur einen Teil des Fensters ein, es bleiben also Ränder die mit 'glClearColor' gefüllt sind. Alles was ich rendern lasse ist ein Rechteck aus 4 Koordinaten einer 3D-Textur auf 4 Vertices die den Eckpunkten des Viewports entsprechen.
Die Textrurmatrix wird vor jedem Rendervorgang skaliert, rotiert und verschoben, damit das gewünschte Rechteck in der 3D-Textur erreicht wird. Die anderen Matrizen bleiben unangetastete 'Identity' Matrizen.

Was ich versuchte habe:
glu(Un)Project liefert mir keine korrekten Ergebnisse, was nicht weiter wundert, da es meine Texturmatrix nicht berücksichtigt. Ich dachte ich könnte einfach die mit Rotationen etc. 'beladene' Texturmatrix speichern und einfach einsetzen, naja, den Versuch war es wert =) da ich ja die anderen Matrizen nicht irgendwie transformiere. Die Texturmatrix einer 3D-Textur verhält sich offenbar anders - ist zumindest nicht in der erhofften Weise kompatibel, oder möglicherweise doch mit einem Trick?

Ich hoffe ihr könnt mir mit Rat und Tips weiterhelfen. Auch verrückte Ideen sind willkommen, solange ich keine 'manuelle' Projektion des Punktes vornehmen muss (es also 'zu Fuß' erledige, was der letzte Ausweg wäre), denn ich hab ja OpenGL und ich weiss OpenGL kann das, aber ich (noch) nicht =)

liebe Grüße!
Q

_________________
*WUSCH* meine Signatur ist unsichtbar!

Versuchs doch mal mit Geometrie:

Du triffst ja immerhin ein Dreieck in deiner Szene. Dieses Dreieck hat an jeder Ecke...logischerweise..2 Texturkoordinaten zwischen 0 und 1
Du kannst noch rausfinden anhand von Linie-Flächenschnittpunkt wo genau das Dreieck geschnitten wird, und somit auch wo genau im Teilbereich der Textur das Texturbild getroffen wird. Probiers mit: verhältnis links-rechts..und hoch-runter!

Weil genau das was du da haben willst hab ich selbst mal gebraucht...aber ich habs nach einigen missglückten Versuchen aufgegeben...besonders nachdem ich gemerkt habe das Blender genau das auch beherrscht und drum dachte ich mir....warum das Rad neu erfinden^^

Ein anderer Ansatz...die Kamera im rechten Winkel zur angeklickten Fläche hinsetzen....Richtung Dreieck gerichtet...und dann das Originaldreieck texturkoordinaten-mäßig-verzerrt auf die Textur anbringen und den entsprechenden Punkt berechnen.
Oder halt...äähm....also.....

_________________
Ich teile manchmal heimlich durch Null. - Alber Einstein

Danke für deine Antwort Ida!

Aber: ich rendere ja immer nur eine Fläche. Ich Transformiere ja lediglich die Texturkoordianten mit dem Effekt das sich in der Ansicht die Textur unter dem Rechteck hinwegdreht u. verschiebt etc. Die Kamera ist also immer Senkrecht zum gerenderten Reckteck. Und wo dieses Rechteck liegt ist also auch immer bekannt: es erfüllt den gesamten Bereich, die 4 Ecken des Viewports und wird somit immer getroffen.

Natürlich kann ich, da ich da vier Eck-Koordinaten habe, 2 Vektoren errechnen die parallel zu den entsprechenden X/Y-Kanten im Viewport sind und mit deren Hilfe von den Eckpunkten ausgehend meine Koordinaten bestimmen. (Indem ich diese Vektoren normalisiere und mit meinen ebenfalls normalisierten Fensterkoordinaten multipliziere (und umgekehrt)). Dies ist Vektorgeometrisch relativ banal, aber ich möchte dies OpenGL(bzw. der GraKa) überlassen, dazu isse ja da; zudem brauche ich diesen Vorgang bei sehr oft und sollte deshalb möglichst maximal-performant sein. Mit glu(Un)Project gibt es ja die gesuchte Funktionalität eigentlich.

_________________
*WUSCH* meine Signatur ist unsichtbar!

Auf der GPU lohnt sich das nur wenn die Anzahl der Worker entssprechend groß sein muss. Ansonsten ist der Weg "zu Fuß" wesentlich einfacher und auch schneller.

_________________
Meine Homepage

Was du benötigst sind die untransformierten Texturkoordinaten...also die Koordinaten die ein Vertex an der Cursorposition haben müsste. Das sollte sich leicht über Interpolation der Texturkoordinanten deiner vier Vertices erreichen lassen. Wenn cursor.xy zwischen 0 und 1 liegt etwa wie folgt, wobei links, rechts usw. die TexCoords der entsprechenden Vertices auf der entsprechenden Achse sind.
texCoord.x = links + cursor.x * (rechts-links);
texCoord.y = unten + cursor.y * (oben-unten);
Sollte diese Richtung auf der Grafikkarte gebraucht werden, macht der Rasterizer diese Interpolation für dich, du bekommst im Fragmentshader direkt die richtigen untransformierten Texcoords.

Die erhaltenen Texturkoordinaten musst du nun nur noch mit der Texturmatrix transformieren (Multiplikation von Matrix * Vektor). Sollte deine Texturmatrix eine Projektion enthalten musst du zusätzlich die perspektivische Projektion ausführen.


Du musst deine Texturmatrix invertieren. Wenn du nur eine 3x3-Matrix hast ist das relativ simpel, bei 4x4 (z.B. wegen Projektion) wird die sicher was aufwendiger. Im Zweifel besorgt dir den Code dazu aus CoolMath).
Nun multiplizierst du wieder die Matrix von links an deine TexCoords dran, dieses mal erhältst du aber die untransformierten Koordinaten. Die Invertierung der Matrix sorgt ja genau für die Umkehroperation. Diese Koordinaten kannst du leicht wieder auf den Cursor zurückrechnen indem du obige Interpolation umgekehrt ausführst.

Für optimale Performance lassen sich die Interpolations-Operationen für beide Richtungen natürlich auch in eine Matrix packen....Matrizen lassen sich kombinieren....entsprechend ist die ganze Aktion nur noch die Multiplikation von Matrix * Vector.

_________________
Yeah!

Danke für den Hinweis! Da hast Du recht, ich merke mir jetzt nach jeder Transformation der Texturkoordinaten die entsprechenden orthogonalen Vektoren die dieses Rechteck aufspannen (deren Länge gesetzt auf 1/PixelanzahlX_im_ViewPort (bzw. PixelanzahlY)). Diese benutze ich als Verschiebungsvektoren die ich ,mit der X/Y-Mauskoordinate multipliziert, auf die untere linke Ecke des Texturkoordinatenrechtecks anwenden muss.
(dies sind nur eine Handvoll arithmetischer Operationen und können bei jeder Pixelweiten Bewegung der Maus problemlos mitgerechnet werden (die Anwendung benötigt auch nicht 'viele Frames pro Sekunde' sondern nur ca. '1 Frame pro Benutzereingabe' ))

Der 'Weg zurück' stellt jedoch ein Problem dar: wie kann ich ebenso effizient bestimmen, welche X/Y-koordinaten ein Punkt im Viewport bekommt, wenn ich die Texturkoordinaten gegeben habe? Ich sehe da momentan keinen besseren Weg als die Texturmatrix auszulesen und diese auf jeden Punkt anzuwenden. Diese Methode ist jedoch recht aufwändig. Nicht nur weil sie ebenfalls bei jeder pixelweiten Mausbewegung berechnet werden muss, sondern auch weil es leicht einige zig bis hundert Punkte werden können. Eine Möglichkeit wäre diesen Teil einfach mit der Modelview Matrix zu lösen, da hier glu(un)Project funktioniert. Ich würde dann so verfahren als wäre die Modelview Matrix die Textur Matrix und dort die Daten einfach nochmal hineingeben und das ganze anschließend über die 3D Textur drüber rendern. Dies wäre aber sehr unschön, oder übersehe ich dabei etwas?

_________________
*WUSCH* meine Signatur ist unsichtbar!

Also ich weiß nicht was du genau machst, aber der Fragmentshader sollten Matrix-Vektor-Multiplikationen quasi im Schlaf hinkriegen. Du übergibst einfach die Texturmatrix bzw. die Inverse davon (je nachdem welche Richtung du brauchst) als Uniform-Variable. Im Shader sähe das dann ca. so aus:

_________________
Yeah!

Wofür genau brauchst du es denn, vielleicht machst du es dir ja viel komplizierter als es sein muss

_________________
Meine Homepage

@Coolcat

Danke für den Input! Das werde ich mir in der Art mal genauer ansehen, zumindest den 1. Teil. Eine Matrixinversion wollte ich, besser gesagt muss ich, um jeden Preis vermeiden, es sei denn es gibt da eine super-performante Möglichkeit, aber mir ist keine bekannt. Ich sehe mir aber auf jeden Fall die CoolMath an.

Ich werde berichten was sich so ergibt, und vor allem wie es mit der Performance ist. Aber lasst euch darum nicht von weiteren guten Einfällen abhalten

Nachtrag: hab die CoolMath bereits offen und die Inversion scheint auf den 1. Blick weit weniger komplex als erwartet. Ich werde berichten...



Mouse-to-Tex-Koords:
Es gibt einmal "den Mittelpunkt", um den die Rotation der Texturkoordinaten erfolgt und dieser wird per Maus an die gewünschte Stelle verschoben, dabei bewegt sich die Ansicht kontinuierlich mit.
Des weiteren soll per Mausklick die exakte Position des Punktes im 3D-Textur-Würfel bestimmt werden, damit sich anhand der unveränderten Bilddaten (Quelle für 3D-Textur) z.B. ein Pixel(farb)wert berechnet werden kann. Eine Reihe dieser Punkte wird benötigt um Strecken abzuzeichnen und einiges anderes.

Tex-to-Window-Koords:
ich hab angefangen zu erklären warum ich das brauche und dabei festgestellt, das es völlig unnötig ist, wie unangenehm =)
aber am besten lernt man wenn man versucht es anderen zu erklären, darum danke der Nachfrage, hat mir insofern extrem geholfen!!

Der Teil 2 (Tex-to-Window-Koords) hat sich somit (vorerst) völlig erledigt! Ich werde berichten wie ich es endgültig gelöst habe, wenn ich mit dem Input so weit (klar)komme =)

_________________
*WUSCH* meine Signatur ist unsichtbar!

Du musst die Matrix ja nur einmal pro Frame invertieren....nicht für jeden Pixel neu. Das sollte absolut kein Problem sein.

_________________
Yeah!

Huhu!

@Coolcat
ich habe deinen Vorschlag in etwa auf diese Weise umgesetzt (leicht modifiziert, zur Lesbarkeit etc.)
Danke nochmals, hab dabei wieder viel gelernt!



und dies funktioniert auch wunderbar und ich erhalte korrekte Werte für LVectorB....
leider aber nur solange keine Rotation in der TextureMatrix steckt...

ich habe die Matrix*Vektor-Berechnung nochmal überprüft und die Indizes sind m.E. korrekt
hier das zugehörige Array: (Anordnung entspricht Spalte1, Spalte2, ..., Spalte 4 enthält gut sichtbar eine Translation zur Mitte hin)
((1, 0, 0, 0), (0, 1, 0, 0), (0, 0, 1, 0), (0,5, 0,5, 0,5, 1))

was nun?

Edit:


Diese Option halte ich mir offen, wenn erstmal der 'Hinweg' klappt..Um eine ProPixelAktion würde ich aber nicht herumkommen, da sich die Matrix mit jeder Pixelbewegung der Maus ändert, also auch die Inverse. Es ist aber für eine andere Aufgabe interessant und werde ich ggf. später nochmal aufgreifen.

Edit 2: waren mir zu viele Rechtschreibfehler

_________________
*WUSCH* meine Signatur ist unsichtbar!

Ich sehe da so auf den ersten Blick auch keinen Fehler. Sicher das die Rotation richtig is?


Ach, die paar Mausevents, davon bekommst du vielleicht 30 pro Sekunde. Solange du nicht für jeden Bildschirmpixel bei einer Auflösung von 1920x1080 eine Inverse berechnest, also das ganze grob 2 Mio mal pro Frame ...nur damit klar ist was pro Pixel bedeutet

_________________
Yeah!

Das ist Wahr, aber die Benutzereingabe ist hochauflösend, d.h. z.B. bei der Winkeleinstellung kann durchaus jeder Pixel 'getroffen' werden und dazu kommt, dass dies pro Aktion vielfach ausgeführt wird (übertragen auf andere 3D-Texturen). Lange Rede: ich muss jede Anweisung für einen Fall ungefähr (mindestens) mal 12 nehmen. Das nur zur Info =) ist also durchaus relevant, ab einer gewissen Komplexität.
Edit:
Hab mich abermals ungenau ausgedrückt: natürlich wird nicht jeder Pixel getroffen, aber pro Pixel über den die Maus fährt geschieht ein Renderdurchlauf, das meine ich. Ein Winkel wird z.B. mit einem 'Hebel' eingestellt und am Drehpunkt bewegt sich dieser entsprechend langsam, so wird ein Pixel u.U. sogar mehrfach 'getroffen'. Das ist auch nicht viel genauer, aber ich muss das auch nicht 100%ig erklären oder? =) Würde auch zu sehr Offtopic werden, wichtig ist nur zu wissen, dass jeder Pixel den die Maus (nur) theoretisch trifft, dennoch einen vollen Renderdurchlauf erfordert.


Nunja, wie sicher kann ich da sein? =)
obiger Code verändert die TextureMatrix mit

glTranslatef(0.5, 0.5, 0.5);

bzw. mit

glTranslatef(LVectorB.X, LVectorB.Y, LVectorB.Z); [** s.u.]

wobei LVectorB anfangs mit (0.5, 0.5, 0.5) belegt ist

darauf folgt

glGetDoublev(GL_TEXTURE_MATRIX, @TextureMatrix[0]);


wenn ich nach der Translation

glRotatef( -90.0, 1.0, 0.0, 0.0);

aufrufe, erhalte ich diese Matrix:

((1, 0, 0, 0), (0, 0,0000000121679644138339, -1, 0), (0, 1, 0,0000000121679644138339, 0), (0,5, 0,5, 0,5, 1))

welche mit LVectorA Mulipliziert ergibt:
LVectorB mit (0,499553969669938, 0,500000000005427, 0,499553969669938)

was auch korrekt ist, wie ich jetzt feststellen muss, ....
[**]
Das Problem ist also, dass ich eine Art Zirkelbezug habe, und sich meine Mausbewegungen sozusagen potenzieren.
(Ich Bewege die Maus in eine Richtung, die Textur verschiebt sich in die entgegen gesetzte Richtung und die nächste Mausbewegung hat einen Effekt der doppelt so groß ist usw. Aber es sieht lustig aus =) )
Da muss ich also noch einen Zwischenschritt einbauen. Ich sag dann nochmal Bescheid, wenn es läuft (oder auch nicht), aber ich denke das Problem ist gelöst! Die Werte stimmen ja!

lieber Gruß!
Q

_________________
*WUSCH* meine Signatur ist unsichtbar!

Klingt so als würden deine Matrix Manipulationen relative Werte erwarten. Sprich wenn sich deine Maus von
(100,100) nach (200,100) verändert dann addierst du (200,100) anstatt (100,0). Müsstest also entweder die Matrix
zurück auf die Defaultwerte setzen oder deine Parameter anpassen.

_________________
Meine Homepage

Nein, leider ist es genau so wie ich sagte: Eine Änderung von +1px/+1px Richtung +X/+Y verschiebt die Textur (auf dem Bildschirm) um je 1px Richtung -X/-Y. Das soll auch so sein: Ich verschiebe den 'Mittelpunkt' 1px nach 'rechts-oben', dieser soll in der ViewPort Mitte liegen, also muss die Textur -1px nach 'links-unten'.
Das Problem ist jetzt, wenn ich nochmal 1px weitergehe ist die Distanz nun 3px, wobei sie erst 2px haben sollte. Diese Differenz wird logischerweise umso größer je weiter ich die Maus bewege. Ich hoffe das war verständlich...
Davon abgesehen liegt meine Maus bereits nach 1px schon nicht mehr über dem 'Mittelpunkt'; sozusagen sind alles andere nur Folgefehler. Um nicht zu sagen, dass das ganze Konzept überdacht werden will...
...da bin ich auch derzeit dran. Die Implementierung ist leider weitaus komplexer als es in den paar geposteten Codezeilen(s.o.) aussieht, darum dauert es so lange - wie schon gesagt werde ich Bescheid geben wenn ich eine Lösung gefunden habe die auch für andere interessant sein könnte, bin aber für Vorschläge und Ideen offen =)

Das Topic ist jedenfalls gelöst!
(ich erhalte in allen möglichen Fällen die korrekten Ergebnisse, der gepostete Code(s.o.) tut genau was er soll und was man erwartet, der Rest ist halt mein lokales Konzept-Design-Wirrwarr )

Der 'Weg-Zurück' ist mit der Inversen Matrix insofern auch beinahe banal, jedenfalls funktioniert das auch einwandfrei, wenn man erst mal die korrekte Inverse hat.

liebe Grüße!
Q

_________________
*WUSCH* meine Signatur ist unsichtbar!