Original erstellt von DonRodi
@aths:
Ja.
G00d. Dann weißt du vermutlich, dass Matrizen als Abbildungsvorschriften aufgefasst werden können. Diese umzusetzen, wird "transformieren" genannt. Das ist erst mal allgemein zu sehen. (Und das Transformierte mit der Inversen der Matrix multipliziert ergibt dann wieder das Original.)
Die Drehung eines Punktes im Raum um eine Achse kann man noch "zu Fuß" mit Sinus und Cosinus machen. Will man um 2 oder 3 Achsen drehen, geht das nicht mehr (jedenfalls nicht mehr so einfach.) Man berechnet also für jede Achse die Transformationsmatrix (wo natürlich Sinus und Cosinus wieder auftreten.) Diese Matrizen multipliziert man, und mit der Ergebnismatrix hat man dann eine Matrix, die man mit dem Vektor multiplizieren kann. Der Ergebnis-Vektor ist dann entsprechend transformiert. Auch Skalierungen und Verschiebungen kann man damit umsetzen, nicht nur Rotationen.
Normalerweise ist ein Objekt um den Koordinaten-Ursprung gedacht. Hat man nur ein Objekt, ist es praktisch gleich, ob man das Objekt oder die Kamera-Position transformiert. Sobald man mehrere Objekte hat, muss die Kamera unabhängig behandelt werden. In praxi fasst man das dann natürlich wieder zusammen, da jedes Objekt aus mehreren Vertices (also Eckpunkten) besteht.
Die T&L-Unit nach DX7 transformiert nun alle ankommenden Vertices mit der vorher auf dem Chip gespeicherten (aber von der CPU berechneten) Transformationsmatrik. Aus Effizienzgründen gibt es auch einen kleinen Vertex-Cache, und man kann (indizierte) Vertices direkt auf die Grafikkarte laden, um die Geometrie-Last über den AGP-Bus zu senken.
Ein Vertex Shader 1.1 kann mehr: Statt nur einer Matrix, lässt sich ein "Programm" auf den Chip laden. Dieses darf bis zu 128 Schritte umfassen. Sprünge und Programmverzweigungen sind nicht erlaubt. Es gibt aber die Möglichkeit, über Umwege in gewissen Grenzen ein "if" quasi zu simulieren.
Jeder Eckpunkt kann nun mehrere Normalen und Material-Farben bekommen. Das lässt sich nutzen, um zusätzliche Informationen dem Vertexshader-Programm zu übergeben, welcher dann diese Variablen je nach dem Shader speziell auswertet. Die CPU kann hier von echter Arbeit befreit werden, zumal auch, was die Beleuchtung angeht, komplexere Dinge möglich sind. (So richtig gut wird das aber erst im Zusammenspiel mit dem Pixelshader, welcher ja auf bestimmte Werte, die aus dem Vertexshader rauskommen, zurück greift.)
Praktisch ist das alles etwas aufwändiger, der Vertex Shader kann mit Vektoren (mit 4 Komponenten) und Skalaren (einzelnen Zahlen) umgehen. Sinus kennt erst der Vertex Shader 2.0. Um einen Sinus auf VS.1.1 umzusetzen, wird mit einigen Befehlszeilen die Taylorsche Reihe angenähert, womit sich ganz gut Näherungswerte berechnen lassen. Der VS.2.0, der Sinus (und Cosinus) nativ unterstützt, hätte hingegen die Möglichkeit, per Lookup-Table (am besten mit 2 Werten, und nachfolgender Interpolation) einen Sinus deutlich schneller zu berechnen, ganz exakt ist dieses Verfahren aber auch nicht. (Vorberechnete Matrizen können nach wie vor durchaus noch von der CPU kommen.)
