Eigentlich ist das ganz einfach. Du definierst für jeden Eckpunkt des Dreiecks die Texturkoordinaten u und v und interpolierst zwischen diesen. Problem dabei ist, dass die Interpolation im R3 (also dem "normalen" 3D-Raum) zwar linear möglich ist, im Screenspace, d.h. auf dem Bildschirm, aber nicht mehr..und da sind wir aber nunmal an dieser Stelle. Alte Spiele und auch die Playstation1 machten das trotzdem so. Das Ergebnis sind "wabbelnde" Texturen...sieht nicht schön aus, ist aber schnell. Um auch im Screenspace linear interpolieren zu können, nimmt man nicht u und v, sondern u/z und v/z. Die sind (analog zu den projezierten X und Y Koordinaten im R2) linear. Problem dann ist aber: Mit u/z und v/z kann man fürs Aufbringen der Textur direkt nichts anfangen. Also müssen wieder die eigentlichen u und v rekonstruiert werden. Aber auch das ist einfach, weil man üblicherweise sowieso z mitinterpoliert. Aber auch für z gilt: Nicht linear im Screenspace, weswegen man a/z mit a üblicherweise=1 nimmt. Also ist u dann (u/z)/(1/z)...und v analog. Das kann man nun für jeden Pixel einer Scanline machen, aber das wird in Software etwas viel. Deswegen macht man das üblicherwiese nur alle x Pixel (bei jPCT z.B. alle 16) und interpoliert dazwischen die errechneten u und v einfach wieder linear. Mathematisch ist das falsch, aber man sieht es kaum bis gar nicht.
Die Theorie ist eigentlich nicht wirklich wild...Problem ist, dass man das schnell genug hinbekommt.
