Hallo!

ich hab eher ein mathematisches Problem:
und zwar hab ich irgendein Quad. Und ich würde gerne anhand der 4 Koordinaten des Quads, die 4 Koordinaten der Textur ausrechnen.

Wenn ich einfach die TexturKoordinaten gleichsetze wie die Quad-Koordinaten, dann funktioniert das für alle Flächen, die parallel zur x2-x3-Ebene sind. Gehen die Quads aber in die Tiefe, dann stimmts nicht mehr, und sobald die Quads schräg sind, hab ich keine ahnung mehr, wie das Funktionieren soll...

Außerdem weiß ich nicht, ob ich dazu die Funktion TexCoord2d oder TexCoord3d benutzen soll. Denn TexCoord2d sollte doch eigentlich ausreichen, oder?

Ich hoffe, ihr kennt das Problem und könnt mir weiterhelfen...
Vielen dank im Voraus!

Grüße
Simon

Edit:
Ich möchte zu dem Thema jetzt nicht unbedingt einen kompletten Code. Ein Ansatz, wie ich das Problem angehen soll, würde mir schon weiterhelfen...

Hi,
also erstmal: gltexCoord2f sollte ausreichen.

Wenn dein Quad schief im Raum liegt, dann ist das nicht so einfach mit dem TexturCoordinaten selbst ausrechen.
Aber vielleicht kann ich dir weiterhelfen:
Für irgendeinen Vertex musst du die Textur ausrichten. Sagen wir mal für deinen 1. von 4 Verticen: der hat dann die Koordinaten 0|0.
Jetzt schaust du dir den zweiten Vertex im Umlaufsinn (CCW) an (hast ja die 3d Position des Vertex), und rechnest folgendes:

Das Ergebnis ist jetzt die Länge von der Strecke Vertex1_Vertex2. Das teilst du noch durch einen Skalierungsfaktor (wieviele OGL einheiten sollen eine Textureinheit sein) und hast somit die T-Koordinate von V2 (S-Koordinate=0): 0|T
Somit machst du weiter mit allen anderen Punkten.

Ich weiß jetzt nicht, ob das klappt, war so meine erste Idee, ich hoffe ich konnte dir (etwas) weiterhelfen.

_________________
http://texelviews.delphigl.com

Hallo!

Genau den Ansatz hab ich inzwischen auch (nachdem ich n bisschen rumprobiert hab).
Ich hab ein Quad bzw. Triangle im Raum und ich muss das jetzt nun so drehen und verschieben, dass es zb auf der x2x3-Ebene liegt.
Die längen auszurechnen ist eigentlich ganz leicht. Ich nehm einfach Wurzel((Punkt2.X1-Punkt1.X1)²+(Punkt2.X2-Punkt1.X2)²+(Punkt2.X3-Punkt1.X3)²). Somit kann ich alle drei Längen des Dreiecks ausrechnen und hab eigentlich schon ziemlich viel. Das Problem ist jetzt nur, dass ich wissen muss, wie das Dreieck im Raum liegt. Das bedeutet, die Drehung des Dreiecks muss auch stimmen...
Und da wirds dann schwer.
Mein Problem war bis jetzt, dass ich gestern die ganze Zeit rumgerechnet und ausprobiert hab, jedoch war schon mein Beispiel falsch, mit dem ich es ausprobiert hab. Und deshalb bin ich nie auf das richtige Ergebnis gekommen...
Das bedeutet, ich werd jetzt mal weiterprobieren und hoff dass es diesmal mit dem richtigen Beispiel etwas effizienter wird

Aber Falls mir jemand noch n paar Tipps hat, die sind immmer erwünscht!!!

Kann es sein, dass glTexGen das schon kann und die TexturKoordinaten selbst errechnet?

Hallo,
Das mit glTexGen weiß ich nicht. Aber:
wenn Du bei Deinem Dreieck alle drei Punkte kennst, BIST Du schon über seine Lage im Raum informiert. Das Dreieck spannt durch seine drei Punkte eine Ebene im Raum auf. Mit diesen drei Punkten kannst Du die Normale der Ebene mittels Kreuzprodukt berechnen (hat Lars Middendorf vor kurzem gepostet). Das Kreuzprodukt gewährleistet, dass das Ergebnis (also die Normale) automatisch nach vorne zeigt. Allerdings müssen die Vektoren richtig eingesetzt werden.

Dieses Dreieck musst Du jetzt in die XY-Ebene drehen, z.B. indem Du seinen Schwerpunkt in den Ursprung verschiebst und dann alle seine Punkte so drehst, dass es eben parallel zur XY-Ebene liegt. Das kann man realisieren, indem man die Normale des Dreiecks mit der Normale der XY-Ebene vergleicht und entsprechend dreht. Was noch passieren kann, ist, dass es nach der Drehung nicht gänzlich aufrecht steht, nämlich dass die Seite A->B nicht parallel zur X-Achse ist. Hier müsste man noch um die Z-Achse drehen.

Dafür braucht man:
-------------------------------------
1) Verschiebung aller drei Punkte mit dem Vektor [Schwerpunkt -> Koordinatenursprung] mit glTranslate. Der Schwerpunkt ist der Mittelwert der drei Punkte.

2) eine Rotations-Achse (Vektor), um die gedreht wird, das ist das Kreuzprodukt zwischen den beiden Ebenennormalen (die Normale zur XY-Ebene ist [0/0/1]), das sind ungefähr drei Zeilen Code, eine Funktion dazu gibts in der Geometry.pas, das im DGLSDK enthalten ist unter "VectorCrossProduct"

3) einen Rotationswinkel, das ist der Winkel zwischen den beiden Ebenen-Normalen, berechnet mit dem Skalarprodukt ("VectorDotProduct" siehe ebenfalls Geometry.pas), auch drei Zeilen Code. Die Drehung realisiert man dann einfach mit glRotate, wo man einfach Rotationswinkel und -Achse einsetzt und alle drei Punkte damit rotiert.

Das wars schon.


Aber eigentlich ist das alles nebensächlich. Das Wichtigste wäre, sich gedanklich von den 2D-Konzepten loszureißen, denn damit kommst Du hier nicht weiter. Versuch mal, dieses ganze Seiten-ausrechnen-Zeugs hinter Dir zu lassen, mach einfach die Augen zu und stell es Dir 3D-mäßig vor, auch die Ebenen-Normalen, und wie es sich langsam in die richtige Position dreht (ein bissl 3D-Vektorgeometrie ist allerdings schon notwendig ). Das Tolle dran ist, dass es auch möglich ist, dabei auf dem Bildschirm zuzuschauen, wenn die Drehung langsam gemacht wird. Man hat also eine visuelle Kontrolle, ob die Berechnung stimmt.



NACHTRAG: Achja, ich hab noch was vergessen: Du willst ja Texturkoordinaten. Dann musst Du das Dreieck am Ende natürlich skalieren, das heißt: verkleinern, bis es in ein Einheitsquad passt. Und es sollte so verschoben werden, dass der Punkt A (also der Punkt links unten) mit dem Koordinatenursprung zusammanfällt. Denn für die Drehung haben wir ja den Schwerpunkt in den Koordinatenursprung verschoben, nicht den Punkt A.

Vielen Dank für die ausführliche Antwort!

Ich will dich ja jetzt nicht enttäuschen, aber inzwischen hab ichs schon selbst hingekriegt...
(Das mit dem Kreuzprodukt hab ich ja gefragt )
Es hat zwar etwas gedauert, aber irgendwann bin ich auch auf die von dir beschriebene Idee gekommen und habs dann auch irgendwann geschafft das zu realisieren.

Die Frage war nur, ob OpenGl sowas, wie das was ich gemacht hab, schon anbietet. Weil dann hätte ich mir einige Mühe ersparen können...

Dazu kann ich nur sagen: Gratuliere!

Danke

Hätte ich nur von anfang an gewusst, dass die Rotation um einen bestimmten Winkel mit einer Rotationsmatrix so einfach ist...
Ich wusste von anfang an, das ich das ganze dreieck drehen muss, da sich das aber so kompliziert angehört hat, hab ichs auf eine andere art versucht hinzubekommen. Ich glaub es hat dann 2 Tage gedauert, bis ich gemerkt hab, dass ichs so net hinbekomm