Home | Lehre | Videos | Texte | Vorträge | Software | Person | Impressum, Datenschutzerklärung | Blog
HLSL und .fx
-
Wiederholung Vertex- und Pixel-Shader
-
fx-Dateien
-
wahlweise mehrere Techniques mit wahlweise mehreren Renderdurchgängen
(siehe Schleife in DirectX-Demoprogramm!), darin Shaderprogramme, Rendereinstellungen.
Obendrein Elemente mit GUI (Schieberegler usw.) und ohne GUI (z.B. Matrizen,
die von der Anwendungssoftware kommen sollen).
-
das Ganze dargestellt als reine Textdatei
-
So ists gedacht:
-
Programmierer bauen Materialien als .fx-Dateien.
-
Designer weisen die in 3D-Software (Demo: C4Dfx für Cinema 4D) den
Modellen zu und stellen die Parameter ein.
-
Die Game-Engine (oder das schlichte DirectX) benutzt die .fx-Dateien.
-
GUI-Elemente von .fx-Dateien, Annotationen, Standardwerte
-
Experimente mit mehreren Durchgängen z.B. Glüheffekte, Kombination
verschiedener Shader
-
Eingaben an den Vertex-Shader:
-
Vertex mit Attributen (Position, Normale, Texturkoordinaten, ...)
-
Matrizen: World, View, Projection, inverse und/oder transponierte Versionen
davon
-
Rechnung im Vertex-Shader: vor allem mit Matrizen
-
Vorsicht: DirectX behandelt Vektoren standardmäßig als Zeilenvektoren.
Die werden von links an Matrizen multipliziert. Produkte von Matrizen wirken
damit von links nach rechts -- anders als in der Mathematik üblich.
-
homogene Koordinaten: Rechnen mit vier Komponenten (x, y, z, w). Am Anfang
setzt man w = 1, am Ende wird alles durch w geteilt: (x/w, y/w, z/w). Vorteil:
Perspektische Projektionen lassen so sich als Matrizen schreiben (und nebenbei
geht das auch mit Verschiebungen). Eine einzige Matrix (nämlich das
Produkt World*View*Projection) beschreibt damit, wie ein Punkt aus dem
Koordinatensystem des Modells auf den Bildschirm zu transfomieren ist.
-
Wenn man die Ortskoordinaten mit der Matrix M transformiert, muss man den
Normalenvektor mit (MT)-1 = (M-1)T
bearbeiten (der inversen transponierten Matrix) und dann wieder auf die
Länge 1 bringen. Lange Begründung: Sind a und b zwei Kantenvektoren
eines Dreiecks, dann ist der Normalenvektor n ein Vielfaches von a x b.
Nach der Transformation hat man den Normalenvektor n' und die Kanten Ma,
Mb, also muss n' ein Vielfaches von Ma x Mb sein. Man weiß aber von
der Definition der Determinante und des Vektorprodukts, dass Mc . (Ma x
Mb) = det(M) c . (a x b) für alle a, b, c gilt. Wegen Mc . (Ma x Mb)
= c . MT(Ma x Mb) weiß man damit für alle a, b, c,
dass MT(Ma x Mb) = det(M) c . (a x b), also Ma x Mb = det(M)
(MT)-1(a x b). Der neue Normalenvektor n' ist also
ein Vielfaches von (MT)-1n.
-
Die View-Matrix V transfomiert die Kameraposition k in den Ursprung, also
(in DirectX-Reihenfolge) (k, 1)V = (0, 1). Also ist (k, 1) = (0, 1)V-1.
Die Kameraposition kann man damit aus der vierten Zeile der Matrix V-1
ablesen: viewInverse[3].xyz
-
Ausgaben aus dem Vertex-Shader, Eingaben an den Pixel-Shader
-
position*World*View*Projection muss ausgegeben werden, kann aber derzeit
nicht wieder im Pixelshader eingelesen werden.
-
Typischerweise gibt man Werte als Pseudo-Texturkoordinaten (TEXCOORD...)
vom Vertex-Shader an den Pixel-Shader. Diese Werte sind dann aber meist
keine echten Texturkoordinaten, sondern etwas anderes, z.B. Vertexpositionen
oder Richtungen.
-
Was der Vertex-Shader ausgibt, kommt nicht genau so am Pixel-Shader an,
sondern wird über die Dreiecksfläche linear interpoliert. (Aus
diesem Grunde wird man z.B. im Vertex-Shader normalisierte Vektoren zu
Beginn des Pixel-Shaders wieder normalisieren, wenn sie sich über
die Dreiecksfläche ändern.)
-
Rechnung im Pixel-Shader: nicht zuletzt Texturabfragen
-
tex1D, tex2D, tex3D
-
texCUBE: Cube-Map; z.B. für Umgebung; besser geeignet als Kugel (siehe
Cinema 4D)
-
Texturen zweckentfremden, um komplexe Funktionen vorzuberechnen
-
.dds-Texturdateien: z.B. Cube-Maps und MIP-Maps; Erzeugung z.B. mit DxTex.exe
aus DirectX-SDK
-
Ausgaben aus dem Pixel-Shader: eigentlich nur Farbe, ggf. mit Alpha