# Wie funktioniert eigentlich Texture Mapping?



## Grizzly (17. Mrz 2005)

Hi,

mal 'ne allgemeine Programmier-Frage: Wie funktioniert eigentlich Texture Mapping?

Ich hab' auch mal im Internet gesucht und folgende Seiten gefunden:
flipcode - Featured Articles
The 3D Coding Blackhole

Dort stehen aber keine oder nur sehr unverständliche Infos.


----------



## Grizzly (17. Mrz 2005)

Hab' noch ein paar Tutorials darüber bei GameDev.net gefunden. Die haben mir aber auch nicht wirklich weiter geholfen.


----------



## Grizzly (20. Mrz 2005)

Keiner 'ne Ahnung?  Oder nur zu faul?


----------



## 0xdeadbeef (26. Mrz 2005)

Was willst Du denn genau wissen?
Soweit ich weiß (und meine eigenen Versuche vor 100 Jahren gediehen sind), benutzt man einen modifizierten Bresenham Algorithmus, um das projizierte Rechteck Zeile für Zeile zu zeichnen. Für jeden Punkt, den man zeichnet, schaut man dann, welcher Punkt der zu projizierenden Bitmap benutzt werden muß (Point sampling). Bei besseren Implementierungen berechnet man den Subpixel in der zu projizierenden Bitmap und mischt die Farbe gemäß den Abständen zu den naheliegendsten Punkten zusammen.


----------



## Grizzly (26. Mrz 2005)

0xdeadbeef hat gesagt.:
			
		

> Was willst Du denn genau wissen?
> Soweit ich weiß (und meine eigenen Versuche vor 100 Jahren gediehen sind), benutzt man einen modifizierten Bresenham Algorithmus, um das projizierte Rechteck Zeile für Zeile zu zeichnen. Für jeden Punkt, den man zeichnet, schaut man dann, welcher Punkt der zu projizierenden Bitmap benutzt werden muß (Point sampling). Bei besseren Implementierungen berechnet man den Subpixel in der zu projizierenden Bitmap und mischt die Farbe gemäß den Abständen zu den naheliegendsten Punkten zusammen.



Genau das mit der Projektion ist mein Problem. Bisher verwende ich zum Zeichnen der Flächen einfach die Funktionen der Klasse Graphics. Wenn ich eine Bitmap jedoch produzieren will, brauche ich wahrscheinlich eine eigene Linie-Funktion, die dann per Projektion die Farbe des jeweiligen Pixels bestimmt.

Jedoch ist mir die Berechnungsformel nicht ganz klar. Bspw. beschäftigt sich der Wikipedia-Artikel über den Bresenham-Algorithmus nur mit dem Zeichnen einer einfachen Linie. Ich habe auch schon C Quellcode gesehen, der diese Projektion durchführt. Aber aus den Listings konnte ich nicht die Formel herauslesen.



_EDIT:_ Ich habe noch eine Internet-Seite zum Thema Computergrafik gefunden. Aber da wird aber nur über die Grundlage des Texture Mapping gesprochen. Keine Formel und nix. Allerdings haben sie ein funktionierendes Applet dazu. Aber natürlich keinen Quellcode.


----------



## 0xdeadbeef (26. Mrz 2005)

Warum selber schreiben? Gibt's nicht in Java2D die Möglichkeit, eine Bitmap zu projizieren? 

Aber nochmal zum Bresenham. Mit dem läufst Du ja pixelweise durch jede Zeile des projizierten Rechtecks. Mathematisch gesehen mußt Du jetzt nur die Koordinaten des jeweilgen Zielpixels rücktransformieren (also quasi die inverse Projektion), um die Koordinate in der ursprünglichen Bitmap zu bekommen. Das ist natürlich ziemlich teuer, selbst wenn man sin/cos usw. tabelliert. Bin mir aber im Augenblick nicht sicher, ob es dafür wesentlich bessere Ansätze gibt. Mir fällt zumindest gerade keiner ein


----------



## Grizzly (26. Mrz 2005)

Java2D kann Bitmaps unterschiedlich zeichnen (Verziehen, Transparenz, ...). Müsste mal schauen, ob da auch so etwas dabei ist. Und vor allem wie performant das Ganze ist.

Das Software Texture Mapping in Java geht (also auch so, dass man nicht nur Standbilder hat), zeigt Scared von David Brackeen.


----------



## 0xdeadbeef (26. Mrz 2005)

Oder jpct von "unserem" Egon Olsen: http://www.jpct.net/

Abgesehen davon kann man ja per JOGL, LWJGL o.ä. auch auch OpenGL-Hardware zugreifen. Ist natürlich für Applets nicht so toll, wo man üblicherweise auf Software-Renderung beschänkt ist.


----------



## Grizzly (26. Mrz 2005)

0xdeadbeef hat gesagt.:
			
		

> Oder jpct von "unserem" Egon Olsen: http://www.jpct.net/


Jepp, das kannte ich auch schon. 



			
				0xdeadbeef hat gesagt.:
			
		

> Abgesehen davon kann man ja per JOGL, LWJGL o.ä. auch auch OpenGL-Hardware zugreifen. Ist natürlich für Applets nicht so toll, wo man üblicherweise auf Software-Renderung beschänkt ist.


Gut, mir geht's ja mehr um die prinizipielle Frage, wie das funktioniert.


----------



## Guest (26. Mrz 2005)

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.


----------



## EgonOlsen (26. Mrz 2005)

^-^ Das war ich...


----------



## Grizzly (26. Mrz 2005)

@EgonOlsen: Danke für die Erklärung.  Klingt ja ziemlich schwierig.  Darüber muss ich erstmal 'ne Nacht schlafen.


----------

