docs: add obsidian hwr docs

Grafik/Hackbarth/Hackbarth Einstiegsprojekt.md

@@ -0,0 +1,22 @@
+# Einstiegsprojekt in Visual Studio
+
+### Erstellung des Projekts
+- C++ Game erstellen auswählen (Win11 SDK wichtig!)
+- Desktop Installer Projekt erstellen
+- main.cpp als Entrypoint
+	- windows.h inkludieren für Windows API!
+	- Docs: [Windows API Docs](https://learn.microsoft.com/en-us/windows/win32/learnwin32/creating-a-window)
+
+```
+#include <Windows.h>
+
+int main(
+  HINSTANCE hInstance,
+  HINSTANCE hPrevInstance,
+  LPSTR     lpCmdLine,
+  int       nShowCmd
+)
+{
+	return 0;
+};
+```

Grafik/Hackbarth/Klausurthemen.md

@@ -0,0 +1,96 @@
+# Klausurvorbereitung
+
+- Es gibt keine Minuspunkte, aber halbe Punkte
+- Antwortlänge an Punkte pro Frage anpassen
+- Reihenfolgen und Sortierungsfragen auch werden auch dabei sein
+- Datentypen oder Enumwerte aus D3D9/D3D11 (z. B. WMQUITE, WMDESTROY, WMEXIT)
+- History-Inhalte aus den Folien aus den Folien kommt nicht
+
+**Transformation**:(Local Space) 
+- World
+- View
+- Projection
+
+**Zugelassen für Rechnungen**:
+- Taschenrechner (nicht programmierbar)
+- Windows oder Physisch
+
+### Themengebiete:
+##### Generell: 
+- Graphics C ++ (z. B. warum C++ benutzen)
+- Unterschied zwischen Pointer und Handle, Pointer-Pointer 
+- COM (Component Object Model von Windows)
+- generelle Graphics Programmingsachen
+##### Fenster: 
+- Fensternachrichten (Typen aus Vorlesungsfolien) 
+- Messagequeue
+- Wozu braucht man Nachrichten?
+- Messagequeue-Funktion: Window Prop
+##### Graphics -API:
+- Welche gibt es?
+- Direct 3D
+- Fixed Function vs. Programmable Pipeline
+- Elemente der Pipelines: Vertex, Mesh, Transformation, Spaces, Projektion, Primitive Types, Unterschied List vs. Strip, Texture Mapping (Was ist eine Normale?)
+- Homogenisierte Koordinaten und dessen Bedeutung
+- Berechnungen: Koordinaten, FPS, Deltatime, Größe von Strukturen 
+	- Beispiele:
+		- Indexbuffers -> kibiByte beachten -> Indices zählen
+		- Vertexbuffer berechnen (Umschrieben, nicht direkt gestellt)
+		- Texturebuffer berechnen
+		- Mipmapping (zählen der Stufen)
+- Textures: 
+	- UV-Mapping
+	- UV-Tiling (Address Modes)
+	- Bild von Modell und gefragt wie viele Verticies benötigt werden und welche
+- Lighting: 
+	- Sources, Lichtbestandteile (Ambient Light, Diffuse Light, Specular Light, Emission Light
+	- Vertex- vs. Pixel-Lighting
+- Stages: 
+	- Screen-Stage
+	- Rasterizer-Stage: Front faces /Back faces
+
+##### Direct3D/DirectX: 
+- Direct3D9 and Direct3D11
+- ID3D11 Device Context, IDirectDevice9
+- konkrete Datentypen aus Framework
+- ID3D11 Device vs. ID3D11 Device Context
+##### Shader: 
+- Shadertypen (6): 
+	- Vertex shade
+	- Hall Shader
+	- Domain Shader
+	- Geometry Shader
+	- Pixelshader
+	- Computeshader
+- zu jedem Shader Grundfunktionalitäten, wozu
+  sie da sind
+- Shader Ressources (Vertexbuffer, Indexbuffer, Constantbuffer)
+- HSL: High Level Shader Language, genereller Sinn von Semantiken in HSL
+
+
+##### Verticies berechnen: 
+- Ziel: Lichtberechnung und Texturierung
+1. Verticiesanzahl berechnen: Verticies = Ecken (4 pro Fläche)
+	- 4 Verticies * 6 Flächen = **24 Verticies**
+	- Eine Normale pro Fläche wegrn des Lichts, deswegen 24 Verticies statt 8
+2. Vertexgröße: 
+	- Position: 3 Floats (x,y,z)
+	- Normale: 3 Floats (x,y,z)
+	- UV-Koordinaten: 2 Floats
+	- 1 Float = 4 Byte
+	↳ 8 Floats. 4 Byles: **32 Byte pro Vertex**
+	- Verfexcolor: 4 Floats
+	- Grafikkarte ist auf Floats optimiert
+3. Vertexbuffergröße:
+	- 24 Vertexe * 32 Byte pro Vertex = **768 Byte**
+	- 2 Byle = 1 Word
+##### Indexbuffer berechnen: 
+- Primitive Type Lists: Triangle List (oder Linelist, Pointlist)
+- 6 Flächen, 2 Dreiecke pro Fläche
+- Mehrfachverwendung der Verticies
+- Zusatzinfos nötig für die Berechnung: Wie viele Flächen und welche Form haben die Flächen
+- wenn die Wahl frei steht: Triangle List (haben wir in der Vorlesung immer benutzt)
+- Bytegröße selbst wählen: Anzahl der Indicies muss in die Bytegröße passen
+- Berechnung: 
+	1. 12 Dreiecke * 3 Ecken = 36 Indicies
+	2. 36 Indicies * 2 Byte = **72 Byte**

Grafik/Hackbarth/Links & Lighting.md

@@ -0,0 +1,29 @@
+---
+share_link: https://share.note.sx/432fk0nz#QrHwi4GF8i8Br/2gDbauKzSsc3TUy6hNjn0oYBUNeUk
+share_updated: 2025-12-04T13:48:22+01:00
+---
+# Links & Lighting
+
+Stages & Pipeline: https://learn.microsoft.com/de-de/windows/win32/direct3d9/direct3d-architecture
+
+Strukturen: Vertices, Edges und Triangles
+
+Transformation: https://learn.microsoft.com/de-de/windows/win32/direct3d9/transforms
+World Transformation: https://learn.microsoft.com/de-de/windows/win32/direct3d9/world-transform
+View Transformation: https://learn.microsoft.com/de-de/windows/win32/direct3d9/view-transform
+Projection Transformation: https://learn.microsoft.com/de-de/windows/win32/direct3d9/projection-transform
+
+Camera Grenze: Near & Far Clipping Plane
+
+Licht:
+- Tiefen wahrnehmen -> Realismus
+- Zum Einbeziehen: Lichtquellen
+	- Directional Light
+	- Point Light
+	- Spot Light
+- Typen:
+	- Ambient Light
+	- Diffuse Light
+	- Specular Light
+	- Emission Light
+- Formel für eine Lichtquelle: Texturen * (Umgebung + Diffuse) + Specular + Emission

Grafik/Hackbarth/Tag1_Bericht.md

@@ -0,0 +1,400 @@
+Fundamentale Architektur: Ein umfassender technischer Leitfaden zu Windows-APIs und der DirectX-Grafikpipeline-Evolution (D3D9 zu D3D11)
+
+TEIL 1: Windows- und C++-Grundlagen für die Grafikanwendung
+
+1. Abstraktion und Ressourcenverwaltung in C++ und Win32
+
+1.1. Pointer versus Handle: Detaillierte Unterschiede, technische Implementation und Verwendungszwecke
+
+Die Unterscheidung zwischen Pointern und Handles ist ein grundlegender Aspekt des Windows-Architekturentwurfs, der die Sicherheit und Stabilität des Betriebssystems gewährleistet.
+
+Ein **Pointer** ist eine direkte, typisierte virtuelle Speicheradresse im User Space. Die Anwendung hat volle Kontrolle über den Speicher, auf den der Pointer verweist, und der C++-Typ (`T*`) definiert, wie der Compiler diesen Speicher interpretiert.[1] Pointer bieten Transparenz und ermöglichen direkten Zugriff, was sie jedoch gefährlich für kritische Systemressourcen macht.
+
+Im Gegensatz dazu ist ein **Handle** (z. B. `HANDLE`, `HWND`) eine **opake Referenz**, die nicht notwendigerweise eine Speicheradresse darstellt.[1] Ein Handle ist ein Pseudo-Pointer, oft als numerischer Wert oder als `void*` Alias implementiert.[2]
+
+**Technische Implementation und Sicherheitsmechanismen:** Handles dienen als Abstraktionsschicht für systemweite Ressourcen (wie Fenster, Dateien oder Device Contexts). Der Windows-Kernel verwendet den Handle-Wert als Index oder ID, um einen Eintrag in einer internen, prozessübergreifenden Handle-Tabelle nachzuschlagen.[3, 4] Dieser Eintrag im Kernel Space enthält die tatsächlichen Adressen und Statusinformationen der Ressource. Dies entkoppelt die Anwendung von der internen Kernel-Struktur.[1] Der entscheidende Vorteil dieser Opazität ist die **Kernel-Sicherheit**: User-Mode-Anwendungen können kritische Systemressourcen nur über gesicherte API-Funktionen, die den Handle validieren, manipulieren.
+
+**Gültigkeitsprüfung und Lebenszyklus:** Da Handles vom Betriebssystem verwaltet werden, ist das Konzept der **Typsicherheit** weniger relevant als bei C++-Pointern; der Typ wird implizit durch die aufrufende API-Funktion bestimmt.[2] Die Verwaltung des Handles durch den Kernel führt zu einem kritischen Problem: **Handle Recycling**. Wenn eine Ressource geschlossen wird (z. B. ein Fenster zerstört), kann der numerische Handle-Wert sofort einer neuen, völlig anderen Ressource zugewiesen werden. Daher ist die einfache Überprüfung eines Handles auf Ungleichheit mit NULL oder `INVALID_HANDLE_VALUE` unzureichend, da ein recycelter Handle scheinbar gültig sein kann, aber auf das falsche Objekt verweist.[5] Die Anwendung ist verpflichtet, den Lebenszyklus des Handles strikt zu verfolgen.
+
+|   |   |   |
+|---|---|---|
+|**Feature**|**C++ Pointer (RAW)**|**Windows Handle (HANDLE, HWND)**|
+|**Natur**|Direkte, typisierte Speicheradresse.|Opaque Reference (Pseudopointer/ID).[1, 3]|
+|**Verwaltungshoheit**|Userspace, manuelle Freigabe.|Kernel Space, Abstraktion von Systemressourcen.[4]|
+|**Typsicherheit**|Streng typisiert (z. B. T∗).|Generisch (void∗/HANDLE); Typ wird durch API-Kontext bestimmt.[2]|
+|**Gültigkeitsprüfung**|Risiko des Handle Recycling; erfordert striktes Lifecycle-Tracking.[5]||
+
+1.2. HWND und andere Windows-Handles: HDC, HINSTANCE, HMODULE
+
+Windows verwendet spezifische Handle-Typen, um verschiedene Ressourcen zu identifizieren:
+
+• **HWND (Handle to a Window):** Der primäre Bezeichner für ein Fenster oder ein Kindfenster-Steuerelement. Er dient als Ziel für Rendering-Operationen und als Adresse für das Windows Message System.[2, 6]
+
+• **HDC (Handle to a Device Context):** Repräsentiert die logische Verbindung zu einem bestimmten Zielgerät (z. B. Bildschirm). Es ist unerlässlich, um GDI- oder ältere Grafik-APIs an ein Fenster zu binden.
+
+• **HINSTANCE (Handle to an Instance):** Repräsentiert die geladene Instanz des Programms.[6] Es wird in der `WNDCLASS`-Struktur benötigt, um die Fensterklasse zu registrieren.[7]
+
+• **HMODULE (Handle to a Module):** Funktional oft identisch mit `HINSTANCE` in modernen Windows-Versionen; es bezeichnet die Basisadresse des geladenen Moduls (EXE oder DLL).
+
+1.3. Windows-Datentypen: DWORD, WORD, BYTE, LPARAM, WPARAM, LRESULT
+
+Die Win32-API definiert aliasierte Datentypen mit expliziter Größe, um die Kompatibilität zwischen 32-Bit- und 64-Bit-Architekturen zu standardisieren.[8]
+
+• **BYTE:** Ein Unsigned 8-Bit-Integer.
+
+• **WORD:** Ein Unsigned 16-Bit-Integer.
+
+• **DWORD (Double Word):** Ein Unsigned 32-Bit-Integer (Bereich: 0 bis 232−1, also 4.294.967.295).[8, 9]
+
+• **WPARAM / LPARAM / LRESULT:** Diese Typen dienen der Übertragung von Informationen in Nachrichten (Window Messages). Während in 16-Bit-Systemen `WPARAM` 16 Bit und `LPARAM` 32 Bit waren, wurden sie in modernen 64-Bit-Systemen auf 64 Bit erweitert. Dies geschieht, damit sie Zeiger (`PVOID`) oder große Werte speichern können, was für die Konsistenz und Zukunftsfähigkeit der API entscheidend ist.[8] `LRESULT` ist der Rückgabewert der Window Procedure.
+
+2. Component Object Model (COM)
+
+Das Component Object Model (COM) bildet das architektonische Rückgrat für Direct3D. Es ist ein binärer Standard, der die Sprache, in der ein Objekt implementiert wurde, abstrahiert.[10]
+
+2.1. Architektur, Interface-Konzept (IUnknown) und Bedeutung für DirectX
+
+**Architektur und Interface-Konzept:** Ein COM-Objekt (`Coclass`) implementiert eine oder mehrere Schnittstellen (`Interfaces`).[10] Jede Schnittstelle ist streng nach dem Prinzip der Vererbung von **IUnknown** abgeleitet. Interfaces sind V-Table-basierte Methodensammlungen. Diese binäre Standardisierung ist notwendig, um die **Application Binary Interface (ABI)** über verschiedene Compiler-Versionen und Programmiersprachen hinweg stabil zu halten.
+
+**Bedeutung für DirectX:** DirectX, beginnend mit Direct3D 8, basiert vollständig auf COM. Jedes kritische API-Objekt in Direct3D, wie beispielsweise `IDirect3DDevice9` oder `ID3D11Device`, ist ein COM-Interface. Dies ermöglicht es Microsoft, die Laufzeitumgebung (Runtime) und die zugrunde liegenden Treiber-Implementierungen zu aktualisieren, ohne dass bestehende Binärcode-Anwendungen neu kompiliert werden müssen.
+
+2.2. Reference Counting (AddRef/Release) und QueryInterface
+
+COM verwendet ein Reference Counting, um den Lebenszyklus des Objekts zu steuern.
+
+• **AddRef/Release:** Das `IUnknown`-Interface exponiert diese Methoden, die einen internen 32-Bit-Referenzzähler steuern.[11] Wenn ein neuer Zeiger auf eine Schnittstelle erstellt oder geklont wird, wird `AddRef` aufgerufen.[11] `Release` dekrementiert den Zähler. Sobald der Zähler Null erreicht, ist das COM-Objekt dafür verantwortlich, seinen eigenen Speicher freizugeben (`self-destruction`).[10] In C++ ist die Nutzung von Smart Pointers (`ComPtr`) die Best Practice, um diese Verwaltung automatisch und fehlerfrei über das RAII-Prinzip sicherzustellen.[10]
+
+• **QueryInterface:** Dies ist der Mechanismus für die dynamische Typerkennung und -navigation innerhalb eines COM-Objekts.[12]
+
+    ◦ Die Methode akzeptiert eine **IID** (Interface Identifier), die ein **GUID** (Globally Unique Identifier) ist.[13]
+
+    ◦ Wenn das Objekt die angeforderte Schnittstelle unterstützt, wird der Zeiger auf diese Schnittstelle zurückgegeben und sofort `AddRef` aufgerufen.[12] Dies ist notwendig, da der neue Zeiger die Lebensdauer des Objekts verlängert.
+
+    ◦ Andernfalls wird der Fehlercode `E_NOINTERFACE` zurückgegeben, was funktionell einem fehlschlagenden C++ DynamicCast entspricht.[13]
+
+2.3. HRESULT, GUID/IID und COM-Initialisierung
+
+• **HRESULT:** Der universelle 32-Bit-Rückgabewert aller COM-Methoden. Er signalisiert den Status des Aufrufs. Werte von Null oder größer (`S_OK`, `S_FALSE`) bedeuten Erfolg, während negative Werte Fehlerzustände darstellen.
+
+• **GUID/IID:** Die 128-Bit-Bezeichner (Global Unique Identifiers), die die Eindeutigkeit von COM-Klassen (`CLSID`) und deren Schnittstellen (`IID`) garantieren. Diese Uniqueness ist entscheidend für das dynamische Laden von Komponenten.
+
+• **COM-Initialisierung (CoInitializeEx):** Bevor ein Thread COM-Interfaces verwenden oder Komponenten instanziieren kann, muss er die COM-Bibliothek initialisieren, indem er `CoInitializeEx` aufruft.[14] Die Funktion ist pro Thread erforderlich. Der zweite Parameter (`dwCoInit`) legt das Threading-Modell fest:
+
+    ◦ **COINIT_APARTMENTTHREADED (STA):** Apartment Threading. Erfordert die Garantie, dass auf COM-Objekte nur über einen einzigen Thread zugegriffen wird, und setzt voraus, dass der Thread eine **Nachrichtenschleife** (`Message Loop`) besitzt.[14]
+
+    ◦ **COINIT_MULTITHREADED (MTA):** Multi-Threading. Erlaubt den Zugriff über mehrere Threads, erfordert jedoch eine komplexe Synchronisation.
+
+Die Anforderung, dass STA-Threads eine Message Loop besitzen müssen, schafft eine direkte kausale Verbindung zwischen dem Windows Message System und der korrigierten COM-Nutzung: wenn der Haupt-Thread einer Grafikanwendung als STA initialisiert wird (was üblich ist, da er das Fenster erstellt), muss die Message Loop (`GetMessage` oder `PeekMessage`) korrekt funktionieren, um auch interne COM-Synchronisationsnachrichten zu verarbeiten.[14]
+
+3. Das Windows-Nachrichtensystem (Message System)
+
+Das Nachrichtensystem ist der Kernmechanismus der Event-driven Programming in Windows und steuert den Lebenszyklus sowie die Interaktion der Anwendung.
+
+3.1. Window Creation: WNDCLASS, RegisterClass, CreateWindow, ShowWindow
+
+Die Erstellung eines Fensters folgt einer strikten Sequenz:
+
+1. **WNDCLASS/WNDCLASSEX:** Definition der Fensterklasse. Die Struktur enthält kritische Elemente wie das Handle der Anwendung (`hInstance`), den Klassennamen (`lpszClassName`) und, am wichtigsten, den Funktionszeiger zur **Window Procedure** (`lpfnWndProc`).[7]
+
+2. **RegisterClass/RegisterClassEx:** Registriert die definierte Klasse beim Betriebssystem.[7]
+
+3. **CreateWindow/CreateWindowEx:** Erstellt eine Instanz der registrierten Klasse und gibt das `HWND` (Handle to a Window) zurück.
+
+4. **ShowWindow / UpdateWindow:** Macht das Fenster sichtbar. `UpdateWindow` sendet die erste `WM_PAINT`-Nachricht, um den Client-Bereich zu zeichnen.
+
+3.2. Message Queue und Window Procedure
+
+Das System arbeitet über dedizierte Message Queues pro Thread.
+
+• **Message Loop:** Die Anwendung muss kontinuierlich Nachrichten aus ihrer Queue abrufen. Die Wahl der Abruffunktion ist entscheidend für die Anwendungsarchitektur:
+
+    ◦ **GetMessage():** Dies ist ein **blockierender** Aufruf. Wenn die Queue leer ist, hält der Thread an, bis eine Nachricht verfügbar ist.[15] Dies ist für traditionelle UI-Anwendungen geeignet, aber in Echtzeit-Anwendungen (Game Loops) unbrauchbar, da es keine Idle Processing (Rendern) zulässt.
+
+    ◦ **PeekMessage():** Dies ist ein **nicht-blockierender** Aufruf. Er kehrt sofort zurück, unabhängig davon, ob eine Nachricht in der Queue gefunden wurde.[15, 16] Wenn `PeekMessage` `FALSE` zurückgibt, kann die Anwendung sofort zur Real-Time-Rendering-Logik übergehen ("Idle Processing").[15]
+
+• **DispatchMessage und TranslateMessage:**
+
+    ◦ `TranslateMessage` verarbeitet virtuelle Tastatur-Codes und generiert `WM_CHAR`-Nachrichten.
+
+    ◦ `DispatchMessage` leitet die Nachricht an die Window Procedure (`WndProc`) des korrespondierenden `HWND` weiter.
+
+• **DefWindowProc:** Nachrichten, die die Anwendung nicht explizit behandelt, müssen an `DefWindowProc` zurückgegeben werden.[17] Diese Funktion stellt das standardmäßige, vom Betriebssystem erwartete Verhalten (z. B. Verschieben des Fensters, Minimieren) sicher.
+
+3.3. Windows Message System: WM_QUIT, WM_DESTROY, WM_CLOSE, WM_PAINT, WM_SIZE
+
+Die geordnete Behandlung von Fensternachrichten ist für die Stabilität von Grafikanwendungen fundamental.
+
+• **WM_CLOSE:** Eine höfliche **Anfrage** zur Beendigung, die gesendet wird, wenn der Benutzer auf das Schließen-Symbol klickt. Die Anwendung kann diese Anfrage ablehnen (z. B. um den Benutzer zum Speichern aufzufordern).[18] Die Standardreaktion ist der Aufruf von `DestroyWindow`.[18]
+
+• **WM_DESTROY:** Ein Signal, das an das Fenster gesendet wird, nachdem es vom Bildschirm entfernt wurde, aber bevor seine Ressourcen (einschließlich Kindfenster) freigegeben werden.[19] Dies ist der Zeitpunkt, an dem alle Direct3D-Ressourcen, die direkt dem Fenster zugeordnet sind (wie die Swap Chain), freigegeben werden müssen.[18] Für das Hauptanwendungsfenster wird hier typischerweise `PostQuitMessage(0)` aufgerufen.[17, 19]
+
+• **WM_QUIT:** Dies ist **keine Fensternachricht**; sie wird direkt in die Thread-Queue eingefügt und dient ausschließlich dazu, die Message Loop zu beenden. Wenn `GetMessage` diese Nachricht abruft, gibt es 0 zurück und terminiert damit die Schleife.[18]
+
+• **WM_SIZE:** Wird gesendet, wenn die Abmessungen des Client-Bereichs geändert wurden. Dies ist der kritische Hook, um die Rendering-Infrastruktur neu zu konfigurieren: die Viewport-Größe muss angepasst und die Swap-Chain (Backbuffer) muss neu dimensioniert werden.
+
+• **WM_PAINT:** Signalisiert einen ungültigen Bereich, der neu gezeichnet werden muss. `WM_SIZE` wird typischerweise von einem `WM_PAINT`-Aufruf gefolgt.[20] In einem Game Loop, der kontinuierlich rendert, wird `WM_PAINT` oft ignoriert, da das Rendern bereits im Idle Processing stattfindet.
+
+TEIL 2: Theoretische und Praktische Grafikpipeline-Architekturen
+
+4. Die Evolution der Rendering-Pipelines
+
+Die Entwicklung der Grafikhardware hat zu einem Paradigmenwechsel von der Fixed Function Pipeline (FFP) zur modernen Programmable Pipeline (PP) geführt.
+
+4.1. Fixed Function Pipeline (FFP)
+
+Die FFP, wie sie in älteren OpenGL- und Direct3D-Versionen (bis D3D9 im FFP-Modus) verwendet wurde, war eine starre Kette von Verarbeitungsstufen.[21] Ihre Logik war im Grafikprozessor (GPU) hartkodiert und konnte nur durch das Setzen von Render States konfiguriert werden.[22]
+
+**Stages und Limitierungen:**
+
+• **Vertex Processing und Lighting (T&L):** Die Geometrie-Transformation und die Beleuchtungsberechnungen (typischerweise Blinn-Phong-Modell) waren fixiert und erfolgten pro Vertex.[22] Die mangelnde Flexibilität bedeutete, dass keine benutzerdefinierten Beleuchtungsmodelle oder realistisches Per-Pixel-Lighting möglich waren.[23]
+
+• **Texture Stages (Combiner):** Anstelle programmierbarer Pixel Shader wurde ein komplexes System von Textur-Umgebungen und Combinern verwendet, um festzulegen, wie mehrere Texturen und Farben gemischt werden.[22]
+
+• **Steuerung:** Die Steuerung erfolgte über Tausende von API-Aufrufen, die den internen Zustand der GPU änderten, wie `IDirect3DDevice9::SetRenderState`.[24]
+
+• **Limitierungen:** Die größte Einschränkung war die Unmöglichkeit, neue Algorithmen zu implementieren. Anspruchsvolle Effekte erforderten ineffizientes Multi-Pass-Rendering und komplexe "Cubemap magic".[23]
+
+4.2. Programmable Pipeline (PP)
+
+Die Programmable Pipeline ersetzte starre Stufen durch Shader-Programme, die direkt auf der GPU ausgeführt werden.
+
+**Shader-basierte Flexibilität und Vorteile:** Die Einführung von Vertex Shadern (VS) und Pixel Shadern (PS) ermöglichte es Entwicklern, die Transformations- und Beleuchtungslogik vollständig neu zu definieren. Die Flexibilität erlaubt:
+
+1. **Per-Pixel Beleuchtung:** Deutlich realistischere Beleuchtung, die im Pixel Shader berechnet wird.[23]
+
+2. **Reduzierte Draw Calls:** Komplexe Materiallogik, die früher mehrere FFP-Pässe erforderte, kann in einem einzigen Shader zusammengefasst werden, was den Zustandwechsel-Overhead reduziert.[23]
+
+3. **Moderne Architekturen:** Die PP ist die Basis für Tessellation (Hull/Domain Shaders, ab SM 5.0) und GPGPU-Computing (Compute Shaders).
+
+**Shader-Kompilierung:** HLSL (High-Level Shading Language) wird von der Entwicklungsumgebung in einen hardwareunabhängigen Bytecode kompiliert. Die Grafik-Runtime (DirectX-Treiber) übersetzt diesen Bytecode zur Laufzeit in Maschinencode für die spezifische GPU-Architektur.
+
+4.3. Vergleich beider Pipelines
+
+Die PP ist nicht in jeder Hinsicht schneller als die FFP. Wenn ein Entwickler einen Shader schreibt, der exakt die gleiche einfache Beleuchtungslogik der FFP implementiert, könnte die FFP aufgrund ihrer extremen Hardware-Optimierung leicht überlegen sein.[23] Die wahre Leistungssteigerung der PP liegt in der Möglichkeit, komplexe Effekte in wenigen Durchgängen zu realisieren, die in der FFP nur durch viele Pässe oder gar nicht möglich wären.
+
+Tabelle 4.1: Vergleich von Fixed Function Pipeline (FFP) und Programmable Pipeline (PP)
+
+|   |   |   |
+|---|---|---|
+|**Kriterium**|**Fixed Function Pipeline (D3D9 Legacy)**|**Programmable Pipeline (D3D11)**|
+|**Flexibilität**|Gering, nur Konfiguration über Zustände.[21]|Sehr hoch, benutzerdefinierte Shader-Programme.[23]|
+|**Beleuchtung**|Per-Vertex, hartkodiert (z. B. Blinn-Phong).[22]|Per-Pixel, frei definierbar, hochrealistisch.[23]|
+|**Zustandsverwaltung**|Hoher CPU-Overhead durch viele `SetRenderState`-Aufrufe.[25]|Effizient durch Immutable State Objects und konstanten Datenaustausch.[26]|
+|**Use Cases**|Einfache 3D-Anwendungen, Legacy-Support.|Moderne Spiele, erweiterte Physik, GPGPU-Computing.|
+
+5. Geometrie-Verarbeitung und Transformation
+
+5.1. Vertex: Struktur, Attribute und Deklaration
+
+Ein Vertex ist die fundamentale Dateneinheit, die die Geometrie und deren Eigenschaften definiert.
+
+**Attribute:** Neben der **Position** (XYZ) im lokalen Raum gehören dazu:
+
+• **Normalen:** Richtungsvektoren, die für die Berechnung der Beleuchtung pro Vertex oder zur Interpolation für den Pixel Shader notwendig sind.[27]
+
+• **Tangenten und Binormalen:** Werden benötigt, um das lokale TBN-Koordinatensystem (Tangent, Binormal, Normal) für Effekte wie Normal Mapping zu definieren.[27]
+
+• **Texturkoordinaten (TexCoord/UV Sets):** Definieren, wie Texturdaten auf die Oberfläche abgebildet werden.[27]
+
+**Vertex Declaration und FVF:**
+
+• **FVF (Flexible Vertex Format):** In Direct3D 9 verwendete ein kompaktes Bit-Flag-Schema (`D3DFVF_XYZ | D3DFVF_NORMAL`), um den Inhalt eines Vertex zu definieren. Es war einfach, aber unflexibel für benutzerdefinierte Attribute.[28, 29]
+
+• **Input Layout (D3D11):** Im modernen Pipeline-Ansatz wird ein explizites `Input Layout` erstellt, das das Speicher-Layout des Vertex-Buffers mit der Eingabesignatur des Vertex Shaders (definiert durch Semantics wie `POSITION0`, `TEXCOORD1`) abgleicht.[29] Dies bietet eine präzisere und typsicherere Methode zur Datenübergabe.
+
+5.2. Mesh: Definition, Organisation und Index-Nutzung
+
+Ein Mesh ist die Organisation der Geometriedaten. Die effizienteste Organisation beinhaltet **Vertex-Sharing** durch die Verwendung eines **Index Buffers**.[30]
+
+• **Definition und Organisation:** Ein Mesh besteht aus einem Vertex Buffer (die eigentlichen Datenpunkte) und einem optionalen Index Buffer (die Reihenfolge, in der die Vertices verarbeitet werden sollen).[30]
+
+• **Index-Nutzung:** Anstatt die gleichen Vertex-Daten für mehrere benachbarte Dreiecke zu duplizieren (z. B. an einer Kante), enthält der Index Buffer nur die Indizes der Vertices, die das Dreieck bilden. Dies reduziert die Speichernutzung drastisch und verbessert die Effizienz des Post-Transform Vertex Cache auf der GPU, da Vertices, die bereits transformiert wurden, wiederverwendet werden können.[30]
+
+5.3. Transformation: Model-, View-, Projection-Matrix
+
+Die Grafikpipeline transformiert Vertices durch eine Reihe von Koordinatensystemen mithilfe von Matrizen.
+
+• **Model-Matrix (M):** Transformiert von Local/Object Space in World Space (Position, Rotation, Skalierung des Objekts).[31]
+
+• **View-Matrix (V):** Transformiert von World Space in View/Camera Space (Positionierung und Ausrichtung der Kamera).[31]
+
+• **Projection-Matrix (P):** Transformiert von View Space in den Homogenen Clip Space. Sie definiert das Sichtvolumen (Frustum) und wendet die perspektivische Verzerrung an.[31]
+
+**MVP-Matrix und Multiplikationsreihenfolge:** Die Gesamttransformation wird oft in einer einzigen Matrix, der MVP-Matrix (P×V×M), zusammengefasst. Wenn der Vektor V![](data:image/svg+xml;utf8,<svg%20xmlns="http://www.w3.org/2000/svg"%20width="0.471em"%20height="0.714em"%20style="width:0.471em"%20viewBox="0%200%20471%20714"%20preserveAspectRatio="xMinYMin"><path%20d="M377%2020c0-5.333%201.833-10%205.5-14S391%200%20397%200c4.667%200%208.667%201.667%2012%2053.333%202.667%206.667%209%2010%2019%206.667%2024.667%2020.333%2043.667%2041%2057%207.333%204.667%201110.667%2011%2018%200%206-1%2010-3%2012s-6.667%205-14%209c-28.667%2014.667-53.667%2035.667-75%2063-1.333%201.333-3.167%203.5-5.5%206.5s-4%204.833-5%205.5c-1%20.667-2.5%201.333-4.5%202s-4.333%201-7%201c-4.667%200-9.167-1.833-13.5-5.5S337%20184%20337%20178c0-12.667%2015.667-32.333%2047-59H213l-171-1c-8.667-6-13-12.333-13-19%200-4.667%204.333-11.333%2013-20h359c-16-25.333-24-45-24-59z"></path></svg>)local​ als Spaltenvektor multipliziert wird, lautet die korrekte Reihenfolge der Operationen: V![](data:image/svg+xml;utf8,<svg%20xmlns="http://www.w3.org/2000/svg"%20width="0.471em"%20height="0.714em"%20style="width:0.471em"%20viewBox="0%200%20471%20714"%20preserveAspectRatio="xMinYMin"><path%20d="M377%2020c0-5.333%201.833-10%205.5-14S391%200%20397%200c4.667%200%208.667%201.667%2012%2053.333%202.667%206.667%209%2010%2019%206.667%2024.667%2020.333%2043.667%2041%2057%207.333%204.667%201110.667%2011%2018%200%206-1%2010-3%2012s-6.667%205-14%209c-28.667%2014.667-53.667%2035.667-75%2063-1.333%201.333-3.167%203.5-5.5%206.5s-4%204.833-5%205.5c-1%20.667-2.5%201.333-4.5%202s-4.333%201-7%201c-4.667%200-9.167-1.833-13.5-5.5S337%20184%20337%20178c0-12.667%2015.667-32.333%2047-59H213l-171-1c-8.667-6-13-12.333-13-19%200-4.667%204.333-11.333%2013-20h359c-16-25.333-24-45-24-59z"></path></svg>)clip​=P×V×M×V![](data:image/svg+xml;utf8,<svg%20xmlns="http://www.w3.org/2000/svg"%20width="0.471em"%20height="0.714em"%20style="width:0.471em"%20viewBox="0%200%20471%20714"%20preserveAspectRatio="xMinYMin"><path%20d="M377%2020c0-5.333%201.833-10%205.5-14S391%200%20397%200c4.667%200%208.667%201.667%2012%2053.333%202.667%206.667%209%2010%2019%206.667%2024.667%2020.333%2043.667%2041%2057%207.333%204.667%201110.667%2011%2018%200%206-1%2010-3%2012s-6.667%205-14%209c-28.667%2014.667-53.667%2035.667-75%2063-1.333%201.333-3.167%203.5-5.5%206.5s-4%204.833-5%205.5c-1%20.667-2.5%201.333-4.5%202s-4.333%201-7%201c-4.667%200-9.167-1.833-13.5-5.5S337%20184%20337%20178c0-12.667%2015.667-32.333%2047-59H213l-171-1c-8.667-6-13-12.333-13-19%200-4.667%204.333-11.333%2013-20h359c-16-25.333-24-45-24-59z"></path></svg>)local​ Die Transformationen werden in der Reihenfolge M, dann V, dann P angewendet.[32] Während eine Vorberechnung der gesamten MVP-Matrix im Vertex Shader Rechenzeit sparen kann, erfordern die Transformation von Normalen oder Tangenten zusätzliche Matrizen (z. B. nur M oder V×M).[33]
+
+**Handedness (DirectX Left-Handed):** DirectX verwendet standardmäßig ein linkshändiges Koordinatensystem, bei dem die positive Z-Achse in die Szene hinein zeigt. Dies ist eine kritische Designentscheidung, die sich auf die Definition der View- und Projection-Matrizen sowie auf die Winding Order (für das Culling) auswirkt.
+
+5.4. Coordinate Spaces
+
+Die Transformationskette definiert die folgenden fünf kritischen Räume:
+
+1. **Local/Object Space:** Koordinaten relativ zum Ursprung des 3D-Modells.
+
+2. **World Space:** Koordinaten relativ zum globalen Ursprung der Szene (nach M).
+
+3. **View/Camera Space (Eye Space):** Koordinaten relativ zur Position der virtuellen Kamera (nach V).[31]
+
+4. **Clip Space (Homogeneous Coordinates):** Koordinaten im Bereich von (wobei W die perspektivische Tiefe ist) (nach P).[31] Clipping und perspektivische Division erfolgen hier.
+
+5. **Screen Space (Viewport):** Die endgültigen 2D-Pixelkoordinaten, nachdem die Viewport-Transformation die normalisierten Koordinaten (NDC, Normalized Device Coordinates, [−1,1]) in den tatsächlichen Bildschirmbereich konvertiert hat.[34]
+
+6. Primitive Assembly und Rasterization Stage
+
+6.1. Primitives: List, Strip, Fan und Effizienz
+
+Die Input Assembler (IA) Stage setzt die Vertices, unter Verwendung der Indizes, zu Primitiven zusammen.
+
+• **Point List, Line List/Strip:** Grundlegende Topologien.
+
+• **Triangle List:** Dreiecke sind voneinander unabhängig (z. B. V0​,V1​,V2​;V3​,V4​,V5​). Für N Dreiecke sind 3N Vertices erforderlich.
+
+• **Triangle Strip und Triangle Fan:** Diese Topologien maximieren die Vertex-Wiederverwendung und sind daher effizienter. Für N Vertices generieren sowohl Strips als auch Fans N−2 Dreiecke (N≥3).[35, 36]
+
+    ◦ **Triangle Strip:** Jedes neue Dreieck teilt sich die letzten beiden Vertices mit dem vorherigen. Ideal für zusammenhängende Oberflächen wie Geländebänder oder Zylinderseiten.[35]
+
+    ◦ **Triangle Fan:** Alle Dreiecke teilen sich den ersten Vertex. Ideal für konvexe Polygone oder Zylinderkappen.[35]
+
+6.2. Rasterizer Stage
+
+Die Rasterizer Stage (RS) ist der feste Teil der Pipeline, der Vektorgeometrie in rasterbasierte Fragmente (potenzielle Pixel) umwandelt.[37, 38]
+
+**Operationen:**
+
+• **Clipping:** Primitiven, die teilweise außerhalb des Sichtvolumens (Clip Space) liegen, werden zugeschnitten, während vollständig außerhalb liegende Primitiven verworfen werden.[37]
+
+• **Culling und Winding Order:** Back-Face Culling verwirft Dreiecke, deren Winding Order (Reihenfolge der Vertices, z. B. CW oder CCW) angibt, dass sie von der Kamera abgewandt sind. Dies reduziert die zu verarbeitende Geometrie frühzeitig.
+
+• **Viewport-Transformation:** Die 3D-Koordinaten werden in 2D-Bildschirmkoordinaten umgewandelt.[34, 38]
+
+• **Triangle Rasterization:** Algorithmen (z. B. Scan-Line oder Edge Functions) bestimmen, welche Pixel auf dem Bildschirm vom Dreieck bedeckt sind. Die **Top-Left Fill Convention** stellt sicher, dass benachbarte Dreiecke keine überlappenden Pixel erzeugen.[39]
+
+• **Interpolation von Vertex-Attributen:** Attribute (Farbe, UVs, Normalen, Tiefe) werden über die Fläche des Dreiecks interpoliert und dem generierten Fragment zugewiesen. Dies geschieht typischerweise mithilfe von **Barycentric Coordinates**, um eine perspektivisch korrekte Interpolation zu gewährleisten.[39]
+
+7. Output Merger (OM)
+
+Der Output Merger (OM) ist die letzte Stufe der Pipeline, die entscheidet, wie und ob das generierte Fragment die Zielpuffer (Framebuffers) beeinflusst.
+
+• **Screen Stage und Framebuffers:** Die Render-Ziele bestehen aus dem **Frame Buffer** (Farbe), dem **Depth Buffer** (Z-Buffer, Speicherung der Tiefe) und dem **Stencil Buffer** (logische Maskierung).
+
+• **Depth Buffer (Z-Buffer):** Speichert den Tiefenwert des nächstgelegenen Pixels. Der **Depth Test** vergleicht die Tiefe des eingehenden Fragments mit dem Wert im Depth Buffer. Wenn das Fragment den Test besteht (z. B. näher liegt), darf es fortfahren. Das Deaktivieren des Z-Buffer-Schreibens kann eine Optimierung sein, wenn sichergestellt ist, dass die Objekte in einer bestimmten Reihenfolge (z. B. Depth First) gerendert werden.[26]
+
+• **Stencil Buffer:** Wird für komplexe Maskierungseffekte, Portale oder Schattenvolumina verwendet. Der **Stencil Test** wendet benutzerdefinierte logische Regeln an.
+
+• **Blending:** Nach den Tests kombiniert der OM die Farbe des Fragments mit der bereits im Render Target vorhandenen Farbe (z. B. für Transparenz oder additive Effekte).[26]
+
+• **Multi-Render-Targets (MRT):** Ermöglicht das gleichzeitige Schreiben in mehrere Farbpuffer (Texturen) in einem einzigen Durchgang. Dies ist fundamental für Techniken wie Deferred Shading, bei dem Normalen, Tiefen und Materialeigenschaften in separate Texturen (G-Buffer) geschrieben werden.
+
+TEIL 3: DirectX-Versionsvergleich und API-Migration
+
+8. Direct3D 9: Die monolithische Ära
+
+Direct3D 9 (D3D9) war die vorherrschende API für über ein Jahrzehnt und zeichnete sich durch einen monolithischen Ansatz aus, der sowohl FFP als auch die frühen Shader Models (bis SM 3.0) unterstützte.
+
+• **Device-Konzept und Immediate Mode:**
+
+    ◦ Das gesamte API-Management war in der einzigen zentralen Schnittstelle, `IDirect3DDevice9`, gebündelt.[40] Dieses Device war für die Ressourcenerstellung, das Setzen von Zuständen und die Ausführung von Draw Calls verantwortlich.
+
+    ◦ Dieses Design erzwang den sogenannten **Immediate Mode**, bei dem Befehle sofort zur Ausführung an den Treiber gesendet wurden. Dies verursachte Engpässe auf modernen Multi-Core-CPUs, da alle API-Aufrufe notwendigerweise sequenziell auf einem einzigen Thread synchronisiert werden mussten.
+
+• **API-Struktur und Initialisierung:**
+
+    ◦ Die Initialisierung erforderte die Erstellung des `IDirect3D9`-Objekts (API-Zugriff), die Auswahl eines Adapters und den Aufruf von `IDirect3D9::CreateDevice` mit den `D3DPRESENT_PARAMETERS`, welche die Backbuffer- und Fenster-Einstellungen enthielten.[17]
+
+• **Pipeline-Steuerung und FFP-Zustände:**
+
+    ◦ Die Steuerung der Pipeline erfolgte über Funktionen wie `IDirect3DDevice9::SetVertexShader` und `IDirect3DDevice9::SetPixelShader`.
+
+    ◦ Die Fixed Function Pipeline wurde mittels `SetRenderState` konfiguriert (z. B. `D3DRS_LIGHTING`, `D3DRS_CULLMODE`).[24]
+
+• **Ressourcen-Handling:**
+
+    ◦ Buffers (`CreateVertexBuffer`, `CreateIndexBuffer`) wurden erstellt und der Zugriff vom CPU-Speicher auf den GPU-Speicher für Updates erfolgte über die Methoden **Lock und Unlock**. `Lock` war oft ein blockierender Aufruf, der erhebliche Performance-Stalls verursachen konnte, da er Synchronisation mit der GPU erzwingen musste.
+
+9. Direct3D 11: Moderne, Multithread-fähige Architektur
+
+Direct3D 11 (D3D11) führte eine tiefgreifende architektonische Umstrukturierung ein, um die Skalierbarkeit auf Multi-Core-CPUs zu gewährleisten und modernere Shader Models zu unterstützen.
+
+9.1. Trennung Device vs. Device Context
+
+Die wichtigste Neuerung war die funktionale Trennung der Verantwortlichkeiten:
+
+• **ID3D11Device:** Das Device ist thread-sicher und dient ausschließlich der **Erstellung von Ressourcen** (Buffers, Texturen, Views, State Objects) und der Abfrage von Hardware-Fähigkeiten.[40]
+
+• **ID3D11DeviceContext:** Der Context ist für die **Setzung des Pipeline-Zustands** (State Binding) und die **Generierung von Render-Befehlen** (`Draw Calls`) zuständig.[40]
+
+**Multithreading-Vorteile (Deferred Context):** Diese Trennung ermöglichte echtes Multithreading. Ein **Immediate Context** wird vom Haupt-Thread verwendet. Zusätzlich können **Deferred Contexts** auf Worker-Threads verwendet werden, um Render-Befehle und State-Bindungen parallel vorzubereiten. Die Ergebnisse dieser parallelen Arbeit werden in **Command Lists** gespeichert. Diese Command Lists können anschließend schnell vom Immediate Context eingereicht werden, was die CPU-Last für das Rendering effizient über mehrere Kerne verteilt und die Framerate in CPU-gebundenen Szenarien verbessert.[41]
+
+9.2. DXGI und Feature Levels
+
+• **DXGI (DirectX Graphics Infrastructure):** Eine dedizierte API-Schicht, die von Direct3D entkoppelt wurde, um allgemeine Grafik-Infrastrukturaufgaben zu übernehmen. DXGI verwaltet Adapter-Enumeration, Multi-Monitor-Konfiguration und die **Swap Chain**.[40, 42]
+
+• **Feature Levels:** D3D11 führte Feature Levels (9_1 bis 11_1) ein, um die Komplexität der Hardware-Erkennung zu standardisieren.[41, 43] Ein Entwickler kann `D3D11CreateDevice` aufrufen und den maximal benötigten Feature Level anfordern (z. B. 11_0). Die Runtime wählt das höchste unterstützte Level auf der Hardware. Dies bedeutet, dass D3D11-Code auf D3D9-Hardware laufen kann (z. B. Feature Level 9_3), wobei automatisch die entsprechenden Einschränkungen (z. B. Shader Model 3.0, keine Geometry Shader) beachtet werden.[41]
+
+9.3. Ressourcen-Management und Views-Konzept
+
+D3D11 implementiert ein striktes, auf Views basierendes Ressourcen-Binding-System.
+
+• **Ressourcen und Views:** Die zugrundeliegenden Ressourcen (Buffers, Texturen) müssen über eine explizite **View** an die Pipeline gebunden werden.[40]
+
+    ◦ **SRV (Shader Resource View):** Lesezugriff in Shadern.
+
+    ◦ **RTV (Render Target View):** Schreibzugriff in der Output Merger Stage (Farbe).
+
+    ◦ **DSV (Depth Stencil View):** Zugriff auf Tiefen- und Stencil-Puffer.
+
+    ◦ **UAV (Unordered Access View):** Ungeordnete Lese-/Schreibzugriffe (für Compute Shaders).[44, 45]
+
+    ◦ **Konfliktvermeidung:** Das System verhindert, dass dieselbe Ressource gleichzeitig als Lese- (SRV) und Schreib-Ressource (RTV/UAV) an dieselbe Pipeline-Stufe gebunden wird.[45]
+
+• **Input Assembler (IA) und Input Layout:** Die IA-Stage ist verantwortlich für das Binden des Vertex- und Index-Buffers. Das **Input Layout** ist dabei die zwingend notwendige Metadaten-Beschreibung, die festlegt, wie die Bits des Vertex-Buffers dem Vertex Shader zugeordnet werden (Ablösung des FVF-Systems).[28]
+
+10. Detaillierter Vergleich und Migrationspfad (D3D9 vs. D3D11)
+
+Der Übergang von D3D9 zu D3D11 stellt einen bedeutenden architektonischen Wandel dar.[46]
+
+10.1. API-Calls und Initialisierung-Unterschiede
+
+|   |   |   |
+|---|---|---|
+|**Merkmal**|**Direct3D 9**|**Direct3D 11**|
+|**API-Initialisierung**|Multi-Schritt-Prozess: `Direct3DCreate9` → `CreateDevice`.|Einzelfunktion: `D3D11CreateDevice` (erstellt Device und Context).[40]|
+|**Swap Chain**|Implizit im Device-Objekt enthalten.|Gemanagt durch separate DXGI-Schnittstelle.[40]|
+|**Draw-Calls**|`IDirect3DDevice9::DrawPrimitive`.|`ID3D11DeviceContext::Draw` (über Context aufgerufen).|
+
+10.2. State-Management (State Objects vs SetRenderState)
+
+Dies ist der tiefgreifendste Paradigmenwechsel.
+
+• **D3D9 (Zustands-Imperativ):** Der Entwickler setzte Zustände (Culling, Blending, Tiefentest) dynamisch zur Laufzeit mithilfe zahlreicher `SetRenderState`-Aufrufe. Jede dieser Änderungen war ein API-Aufruf, der potenziell hohen Treiber-Overhead verursachte, da die GPU-Pipeline-Konfiguration häufig neu berechnet werden musste.[25]
+
+• **D3D11 (Zustands-Deklarativ / State Objects):** Alle fixen Pipeline-Zustände werden in unveränderlichen Objekten (`ID3D11RasterizerState`, `ID3D11DepthStencilState`) gekapselt und einmalig erstellt.[40] Zur Laufzeit bindet der Context diese Objekte als Ganzes. Dies ermöglicht dem Treiber eine bessere interne Voroptimierung und reduziert den Aufwand für Zustandswechsel im Rendering-Loop drastisch.
+
+10.3. Shader-Handling und Ressourcen-Binding
+
+• **Shader Model 3.0 vs 5.0:** D3D9 war auf SM 3.0 beschränkt, was keine Tessellation oder Compute Shaders unterstützte. SM 5.0 (D3D11) fügte diese modernen Stufen hinzu und erhöhte die Komplexität und Größe der Shader-Programme erheblich.[41]
+
+• **Constant Buffers vs Constants:** Anstelle der begrenzten, einfachen Konstantenregister von D3D9 verwendet D3D11 **Constant Buffers (C-Buffers)**. Dies sind strukturierte Ressourcen, die effizient über `ID3D11DeviceContext::Map`/`Unmap` von der CPU aktualisiert werden können, was das Daten-Streaming zur GPU verbessert.
+
+10.4. Migration-Aspekte
+
+Der Wechsel von D3D9 zu D3D11/D3D10 ist ein signifikanter Bruch, da die grundlegenden Annahmen über State Management und Datenfluss sich ändern.[46]
+
+• **Architektonische Vorbereitung:** Experten empfehlen, die D3D9-API-Aufrufe so früh wie möglich durch eine eigene Abstraktionsschicht zu isolieren. Dies minimiert den Umfang der Code-Änderungen, wenn Konzepte wie Input Layout und State Objects eingeführt werden müssen.[46]
+
+• **Performance-Implikationen:** Die primäre Performance-Steigerung bei der Migration zu D3D11 wird oft durch die verbesserte CPU-Skalierung (Multithreading via Deferred Contexts) und die effizientere Zustandsverwaltung (State Objects) erzielt.[47]
+
+• **Deprecations:** Das Flexible Vertex Format (FVF) und die Fixed Function Pipeline wurden in D3D11 vollständig abgeschafft. Anwendungen müssen die FFP-Logik in Shader-Code (Vertex und Pixel Shader) portieren.
+
+• **HLSL-Syntax-Unterschiede:** Während HLSL in seiner Basis ähnlich bleibt, erfordert D3D11 die Verwendung von Puffer-Semantiken und konstanten Puffer-Definitionen, die in D3D9 nicht existierten.
+
+Schlussfolgerung
+
+Die evolutionäre Analyse von Windows-Grafikprogrammierung, von den Win32-Fundamentals bis zur Direct3D-Architektur, zeigt einen klaren Trend: die Verschiebung von einer **imperativen, CPU-zentrierten Steuerung** hin zu einer **deklarativen, GPU-zentrierten Programmierung**.
+
+In der Windows-Grundlagenarchitektur dient die Opazität von Handles und die Struktur des Component Object Model (COM) der Durchsetzung der Kernel-Integrität und der binären Stabilität der API. Die korrekte Interaktion mit dem Message System, insbesondere die Wahl zwischen `GetMessage` und `PeekMessage`, ist der notwendige Mechanismus, der es der Anwendung ermöglicht, sowohl auf Events zu reagieren als auch Echtzeit-Idle-Processing (Rendering) durchzuführen.
+
+Der Wandel von der Fixed Function Pipeline zu den programmierbaren Shadern in Direct3D 11 ist die Antwort auf die Notwendigkeit flexiblerer und realistischerer Grafikeffekte. Die D3D11-Architektur löst die Performance-Probleme von D3D9, indem sie die monolithische Steuerung in separate Device- und Context-Objekte zerlegt. Diese Trennung und die Einführung von Immutable State Objects sind die technologischen Voraussetzungen für die Skalierbarkeit des Rendering-Workloads über moderne Multi-Core-CPUs. Entwickler, die von D3D9 migrieren, müssen diese architektonischen Verschiebungen – von dynamischem State Management zu deklarativen State Objects und von FVF zu Input Layouts – vollständig adaptieren, um die Performance-Vorteile der modernen Hardware voll auszuschöpfen.
+
+![[TTS/Tag1_Bericht - Dec 16 2025 14-25.mp3]]
+
+![[TTS/Tag1_Bericht - Dec 16 2025 14-32.mp3]]

Grafik/Hackbarth/Tag2_Bericht.md

@@ -0,0 +1,200 @@
+Detaillierte Analyse der GPU-Pipeline in DirectX: Shader, Beleuchtung und Texturierung
+
+Dieser Bericht dient als umfassende Lernressource und prüfungsrelevante Aufbereitung der Kernkonzepte des Real-Time Renderings in Direct3D. Er beleuchtet die Architektur programmierbarer Shader-Stufen, die Implementierung physisch basierter Beleuchtungsmodelle und die Optimierung von Textur-Streaming und Qualität.
+
+TEIL 1: Erweiterte Shader-Programmierung in DirectX
+
+Die programmierbaren Shader-Stufen bilden das Rückgrat der modernen DirectX-Pipeline und ermöglichen eine hochgradig flexible und parallele Verarbeitung von Geometrie und Pixeldaten.
+
+1.1 Die Sechs Programmierbaren Shader-Typen
+
+Die Pipeline in Direct3D ist modular aufgebaut und bietet sechs programmierbare Stufen, die jeweils spezifische Aufgaben in der Datenverarbeitung von den initialen Vertices bis zum finalen Pixel übernehmen.
+
+1.1.1 Vertex Shader
+
+Der Vertex Shader ist eine obligatorische Stufe in der minimalen Rendering-Pipeline. Er wird einmal pro Vertex ausgeführt und ist primär für die räumliche Transformation zuständig. Die Hauptaufgabe des VS besteht darin, die lokale Koordinatenposition des Vertex unter Anwendung der World-View-Projection Matrizen in die homogene Clip-Space-Position zu überführen. Dieser obligatorische Output muss die System Value Semantik SV_Position tragen. Darüber hinaus transformiert der VS alle für spätere Stufen benötigten Attribute wie Normalen, Tangenten und Texturkoordinaten in den erforderlichen Raum, meist Weltraum oder Sichtraum, und leitet sie zur Rasterization weiter. Die Input-Daten für den VS stammen aus dem Vertex Buffer und werden durch User Semantics wie POSITION0, NORMAL0 oder TEXCOORD0 gebunden.
+
+1.1.2 Tesselation Stages: Hull Shader und Domain Shader
+
+Die Tessellation ermöglicht die dynamische Generierung geometrischer Details auf der GPU, was die LOD-Verwaltung deutlich vereinfacht.
+
+Hull Shader: Diese Stufe, auch bekannt als Tessellation Control Stage, verarbeitet einen Input-Patch, eine Gruppe von Kontrollpunkten zwischen 1 und 32, und generiert neue Kontrollpunkte sowie Patch-Konstanten. Die wichtigste Ausgabe sind die Tessellation Factors, numerische Werte, welche die Dichte der Unterteilung der Patch-Kanten und des Inneren für die nachfolgende fixe Tessellator-Stufe definieren. Eine wichtige Optimierung liegt in der Möglichkeit, den gesamten Patch zu verwerfen, also Culling, indem der HS die Tessellation Factors auf 0 oder NaN setzt.
+
+Domain Shader: Der Domain Shader wird einmal pro Ausgabekoordinate des Tessellators aufgerufen. Er fungiert als Evaluator, indem er die vom Tessellator bereitgestellten Koordinaten, zum Beispiel baryzentrische Koordinaten, sowie die Kontrollpunkte des HS-Outputs nutzt, um die exakte 3D-Position der neuen, hochauflösenden Vertices zu berechnen. Im Prinzip führt der DS die Transformationen des ursprünglichen Vertex Shaders für die neu generierte Geometrie durch und liefert die transformierte Vertex-Position an den Rasterizer.
+
+1.1.3 Geometry Shader
+
+Der Geometry Shader arbeitet auf Primitiven: Punkten, Linien oder Dreiecken. Im Gegensatz zum VS, der 1:1 Vertices verarbeitet, kann der GS die Topologie manipulieren, indem er Primitiven entfernt oder neue Geometrie erzeugt, zum Beispiel aus einem Punkt ein Quad generiert. Ein zentrales Feature des GS ist Stream-Out, das es ermöglicht, verarbeitete Geometriedaten direkt zurück in einen GPU-Buffer zu schreiben, anstatt sie dem Rasterizer zuzuführen. Dies ist fundamental für Rückkopplungsschleifen, wie sie in Partikelsimulationen oder komplexen LOD-Systemen benötigt werden.
+
+Architektonische Implikation: Aufgrund seiner sequenziellen Natur und der Schwierigkeit, seine Ausführung effizient zu parallelisieren, gilt der GS als Performance-Engpass. In Direct3D 12 Ultimate wird er daher durch die effizienteren, GPU-gesteuerten Mesh Shaders ersetzt. Es ist bemerkenswert, dass der Mesh Shader den Stream-Out-Mechanismus in seiner ursprünglichen Form nicht fortführt, was auf einen Paradigmenwechsel in der Geometrieverarbeitung hindeutet.
+
+1.1.4 Pixel Shader
+
+Der Pixel Shader, oder Fragment Shader, ist die zweite obligatorische Stufe. Er wird pro Pixel oder Fragment ausgeführt, das vom Rasterizer als abgedeckt identifiziert wird. Der PS erhält alle vom VS, oder DS/GS, ausgegebenen und vom Rasterizer über die Oberfläche des Primitivs interpolierten Attribute, zum Beispiel interpolierte Normalen, UV-Koordinaten und Weltposition. Seine Hauptfunktion ist die Berechnung der endgültigen Farbe, oft basierend auf Beleuchtungsmodellen und Textur-Sampling. Die finale Ausgabe des PS muss über die Semantik SV_Target erfolgen, die den Farbwert in den gebundenen Render Target Buffer schreibt. Der PS kann optional die Screen-Space-Position, also Pixelkoordinaten X/Y, als Input über SV_Position empfangen, was für gewisse Post-Processing-Effekte nützlich ist.
+
+1.1.5 Compute Shader
+
+Der Compute Shader ist technisch gesehen kein Teil der klassischen Rendering-Pipeline, sondern ermöglicht General Purpose GPU Computing, GPGPU. Er bietet hochparallele Rechenleistung für beliebige, nicht-grafische Aufgaben, wie Physik-Simulationen, Raytracing-Beschleunigung oder komplexes Culling. Compute Shader greifen typischerweise über Unordered Access Views, UAVs, auf Ressourcen zu, die wahlfreien Lese- und Schreibzugriff erlauben.
+
+1.2 Shader-Ressourcen: Buffer und Speichermanagement
+
+Shader-Ressourcen werden in Buffern organisiert und dienen der Bereitstellung von Geometrie-Input oder konstanten Uniform-Daten.
+
+1.2.1 Vertex und Index Buffer
+
+Vertex Buffer: Speichert die Kernattribute der Geometrie: Position, Normale, UV und Farbe.
+
+Index Buffer: Enthält eine Liste von Indizes, die definieren, welche Vertices aus dem VB zur Konstruktion von Primitiven verwendet werden sollen. Die Nutzung des Index Buffers ist ein entscheidender Performance-Vorteil, da sie die Menge der zu speichernden Duplikate von Vertices reduziert. Darüber hinaus verbessert die Verwendung von Indizes und eine gute Indexreihenfolge die Vertex-Cache-Effizienz auf der GPU, da oft dieselben Vertex-Daten schnell aus dem Cache abgerufen werden können, was die Gesamtgeschwindigkeit des Renderings erhöht.
+
+1.2.2 Constant Buffer
+
+Constant Buffers, CBs, speichern Daten, die für alle Invocations eines Shaders konstant bleiben, jedoch häufig von der CPU aktualisiert werden, zum Beispiel Transformationsmatrizen oder Lichtparameter. CBs sind für den Transfer kleiner, oft aktualisierter Datensätze optimiert.
+
+HLSL Packing Rules: Um eine effiziente Ausrichtung und Übertragung von Daten zwischen CPU und GPU zu gewährleisten, wendet HLSL strenge Packing-Regeln an, die Daten in 16-Byte-Vektoren gruppieren. Variablen werden so angeordnet, dass sie keine 16-Byte-Grenze überschreiten. Dies verhindert unnötigen Overhead beim Hochladen von Daten.
+
+Packing-Beispiel und Effizienz: Ein float4 belegt genau 16 Bytes. Wenn man innerhalb eines cbuffer kleine Datentypen ungeschickt platziert, entsteht Padding. Wenn die Struktur nicht optimiert wird, führt dies zu einer unnötig großen Datenmenge, die bei jedem Aufruf des Constant Buffers von der CPU zur GPU übertragen werden muss. Eine bewusste Organisation der HLSL-Strukturen, um die Vektor-Packing-Regeln auszunutzen, ist daher eine kritische Optimierungsstrategie für Rendering-Architekten.
+
+1.3 HLSL und Semantiken
+
+HLSL ist eine C-ähnliche Sprache. Sie verwendet Basistypen wie float, int, und deren Vektorvarianten float2 bis float4 sowie matrix.
+
+Semantiken als Pipeline-Schnittstelle: Semantiken sind Bindungsnamen, die dem Compiler und der Hardware mitteilen, welche Daten wohin fließen sollen. Sie sind in zwei Hauptkategorien unterteilt:
+
+1. User Semantiken: Werden zur Identifizierung benutzerdefinierter Datenströme verwendet, hauptsächlich Input-Attribute aus dem Vertex Buffer: POSITION, NORMAL, TEXCOORD.
+    
+2. System Value Semantiken: Spezielle Semantiken, die von der Pipeline selbst verarbeitet werden. SV_Position: Obligatorischer Output des Vertex Shaders, definiert die transformierte 4D-Position im Clip Space. Kann auch als optionaler Input im Pixel Shader verwendet werden, um die Pixelkoordinaten im Screen Space zu erhalten. SV_Target: Obligatorischer Output des Pixel Shaders, definiert die endgültige Farbe, die in das Render Target geschrieben wird.
+    
+
+1.4 Shader-Pipeline-Flow
+
+Die Rendering-Pipeline ist sequenziell. Der minimale Flow besteht aus Vertex Shader und Pixel Shader. Die optionalen Stufen, HS, DS, GS, werden eingefügt, um spezifische Effekte wie Tessellation oder Geometrie-Manipulation zu erzielen.
+
+TEIL 2: Lighting, Beleuchtung
+
+Die Beleuchtung in DirectX wird durch die Implementierung von lokalen Beleuchtungsmodellen in den Shadern, typischerweise im Pixel Shader, realisiert, wobei die Intensität des reflektierten Lichts durch die Art der Lichtquelle und die Materialeigenschaften bestimmt wird.
+
+2.1 Lichtquellen-Typen
+
+Directional Light: Parallele Strahlen von unendlicher Entfernung, zum Beispiel die Sonne. Definiert nur durch Richtung L. Keine Attenuation, geringe Berechnung mit konstantem L.
+
+Point Light: Strahlt in alle Richtungen von einem Punkt P. Definiert durch Position und Radius. Attenuation nur abstandsabhängig, mittlere Berechnung mit Abstand d, L variiert.
+
+Spot Light: Kegelförmige Strahlenbündel. Definiert durch Position P, Richtung D und Winkel. Attenuation durch Abstand und Kegel-Form, hohe Berechnung mit Abstand d, L variiert und Cone-Test.
+
+2.2 Licht-Komponenten des Beleuchtungsmodells
+
+Das lokale Beleuchtungsmodell, häufig basierend auf Phong oder Blinn-Phong, setzt sich aus additiven Komponenten zusammen.
+
+Ambient: Simuliert indirektes oder gestreutes Licht. Es ist konstant und richtungsunabhängig.
+
+Diffuse: Simuliert die matte Reflexion. Die Intensität hängt von der Orientierung der Oberfläche zur Lichtquelle ab, Lambert'sches Gesetz. Diffuse ist proportional zu Maximum von N mal L, 0, wobei N die Normale und L die Lichtrichtung ist.
+
+Specular: Simuliert glänzende Highlights auf der Oberfläche. Die Intensität ist stark von der Blickrichtung V und der Oberflächenrauheit, Shininess, abhängig.
+
+Emission: Licht, das vom Objekt selbst ausgestrahlt wird, unabhängig von externen Lichtquellen.
+
+Die finale beleuchtete Farbe C Final wird durch die Summe dieser Komponenten bestimmt: C Final gleich Ambient plus Diffuse plus Specular plus Emission.
+
+2.3 Beleuchtungs-Berechnungen
+
+2.3.1 Blinn-Phong Specular
+
+Während das klassische Phong-Modell den Reflexionsvektor R und den Blickvektor V vergleicht, nutzt das Blinn-Phong-Modell den Halbvektor H. Dies ist rechnerisch effizienter.
+
+Der Halbvektor H wird als normalisierte Summe der Lichtrichtung L und der Blickrichtung V berechnet: H gleich L plus V geteilt durch die Norm von L plus V. Die spekulare Intensität wird dann berechnet als: Specular gleich C Specular mal Maximum von N mal H, 0 hoch n. Wobei n der Shininess-Exponent ist, der die Glanzstärke des Materials bestimmt.
+
+2.3.2 Attenuation, Dämpfung
+
+Die quadratische Attenuation ist das Standardmodell zur Simulation der realistischen Intensitätsabnahme von Point und Spot Lights mit der Entfernung d.
+
+Attenuation von d gleich 1 geteilt durch c const plus c linear mal d plus c quadratic mal d Quadrat.
+
+Der konstante, lineare und quadratische Koeffizient steuern, wie schnell und stark die Lichtintensität abfällt. Ein häufiger Fehler in HLSL-Implementierungen ist die fehlerhafte Priorisierung von Operatoren, zum Beispiel 1,0f geteilt durch d mal d statt 1,0f geteilt durch Klammer auf d mal d Klammer zu, was zu falschen oder fehlenden Dämpfungseffekten führt.
+
+2.4 Vertex Lighting versus Pixel Lighting, Gouraud versus Phong
+
+Die Wahl des Beleuchtungsorts, VS oder PS, stellt einen kritischen Trade-off zwischen Renderqualität und Performance dar.
+
+Vertex Lighting, Gouraud Shading: Die Beleuchtung wird einmal pro Vertex im Vertex Shader berechnet. Die resultierenden Farbewerte werden vom Rasterizer über die Fläche des Primitivs interpoliert. Dies ist sehr schnell, Performance proportional zur Anzahl der Vertices, führt aber zu unpräzisen Ergebnissen, insbesondere bei großen Polygonen oder kleinen, glänzenden Highlights, die zwischen den Vertices verschwinden können. Die Interpolation der fertigen Farbe kann zu sichtbaren Farbabstufungen, Mach Bands, führen.
+
+Pixel Lighting, Phong Shading: Die Beleuchtung wird für jeden Pixel im Pixel Shader neu berechnet. Hierbei werden die Normalenvektoren vom VS an den PS weitergegeben und über die Oberfläche interpoliert. Da die Beleuchtung pro Pixel erfolgt, ist die Qualität deutlich höher, die Highlights sind glatt und präzise, unabhängig von der Polygondichte. Der Nachteil ist der höhere Rechenaufwand, da die teure Beleuchtungsberechnung für potenziell Millionen von Pixeln durchgeführt werden muss, Performance proportional zur Anzahl der Pixel.
+
+Pixel Lighting, Phong Shading, ist der heutige Standard, da moderne GPUs die zusätzliche Last gut bewältigen können, um die notwendige visuelle Qualität zu gewährleisten.
+
+TEIL 3: Texturen, Mapping und Filtertechniken
+
+Texturen sind essentielle Datenquellen für Shader und erfordern spezielle Techniken für Adressierung, Sampling und Qualitätsoptimierung.
+
+3.1 UV-Mapping und Adressierungsmodi
+
+UV-Mapping: Definiert die Abbildung von 3D-Vertex-Positionen auf die 2D-Texturkoordinaten u und v. Der Standardbereich für Texturkoordinaten liegt in 0 bis 1 mal 0 bis 1. Ein einzelnes Bildelement in der Textur wird als Texel bezeichnet.
+
+Texture Address Modes, UV-Tiling: Diese Modi bestimmen das Verhalten des Samplers, wenn die übergebenen UV-Koordinaten außerhalb des Standardbereichs liegen.
+
+Wrap, Repeat: Die Textur wird wiederholt, indem nur der gebrochene Teil der Koordinate verwendet wird, zum Beispiel u modulo 1,0. Anwendung: Tiling von Oberflächen wie Wände und Böden.
+
+Mirror: Die Textur wird bei jeder ganzzahligen Grenze gespiegelt. Reduziert sichtbare Nähte bei Kachelung.
+
+Clamp: Die Koordinaten werden auf 0 bis 1 begrenzt. Die Farbe der Randtexel wird bis zur Grenze des Primitivs ausgedehnt, Smearing. Anwendung: Einzelobjekte, die nicht kacheln sollen, zum Beispiel UI-Elemente.
+
+Border: Außerhalb von 0 bis 1 wird eine definierte Border Color verwendet. Vermeidung von Smearing bei bestimmten Effekten.
+
+3.2 Texture Sampling und Filterung
+
+Sampling beschreibt den Prozess des Auslesens von Farbinformationen an einer bestimmten UV-Koordinate.
+
+Point Filtering, Nearest Neighbor: Wählt den Farbwert des Texels, dessen Zentrum dem Sample-Punkt am nächsten liegt. Resultiert in einer blockigen, pixelierten Optik.
+
+Linear Filtering, Bilinear: Interpoliert linear zwischen den vier nächstgelegenen Texeln auf der aktuellen Mipmap-Stufe, um einen glatteren Farbübergang zu erzeugen.
+
+Mipmapping
+
+Mipmapping ist eine Hierarchie von vorab berechneten, kleineren Versionen der Originaltextur, Level 0.
+
+Zweck: Mipmapping dient primär dazu, das Minifikations-Aliasing, Moiré-Effekte bei Texturen in der Ferne, zu reduzieren und die Performance zu steigern, da der GPU-Speicherzugriff, Bandbreite, stark reduziert wird, wenn weit entfernte Objekte kleinere Textur-Levels verwenden.
+
+Berechnung der Stufenanzahl L: Die Anzahl der Mipmap-Levels für eine Textur mit den Dimensionen W mal H wird berechnet als: L gleich Abrundung von Logarithmus zur Basis 2 von Maximum von W, H plus 1.
+
+Beispiel 1: 256 mal 256 ergibt Logarithmus zur Basis 2 von 256 plus 1 gleich 8 plus 1 gleich 9 Stufen.
+
+Beispiel 2: 1024 mal 1024 ergibt Logarithmus zur Basis 2 von 1024 plus 1 gleich 10 plus 1 gleich 11 Stufen.
+
+Speicher-Overhead: Der gesamte zusätzliche Speicher, der für alle Mipmap-Stufen benötigt wird, beträgt nur etwa 33% der Größe der ursprünglichen, größten Textur, Level 0. Dies macht Mipmapping zu einer sehr effizienten Methode.
+
+Trilinear und Anisotropic Filtering
+
+Trilinear Filtering: Verbessert das Bilinear Filtering, indem es nicht nur innerhalb eines Mipmap-Levels interpoliert, sondern zusätzlich linear zwischen den beiden Mipmap-Stufen, LOD A und LOD B, interpoliert, die dem optimalen Level of Detail am nächsten liegen. Dies verhindert das abrupte Umschalten zwischen Mipmap-Stufen, bekannt als Mipmap Popping.
+
+Anisotropic Filtering, AF: Dies ist die hochwertigste Filterung. Bilinear und Trilinear sind isotrop, filtern gleichmäßig. Bei schrägen Blickwinkeln, zum Beispiel bei Bodenflächen, führt dies zu Unschärfe, da das Aliasing in einer Achse stärker ist als in der anderen. AF wendet eine richtungsabhängige Filterung an, um die Texturdetails auch bei extrem schrägen Winkeln scharf und detailliert zu halten. Trotz der höheren Qualität hat AF auf modernen GPUs nur einen minimalen Performance-Einfluss und wird daher fast immer in den höchsten Stufen verwendet.
+
+3.3 Advanced Texturing Techniken
+
+3.3.1 Texture-Typen
+
+Cube Maps: Bestehen aus sechs 2D-Texturen, die die Seiten eines Würfels repräsentieren. Sie werden primär für das Environment Mapping, zum Beispiel Skyboxes oder Reflexionen, verwendet, um die Umgebung aus einem zentralen Punkt zu erfassen.
+
+Texture Arrays: Sammlungen von 1D-, 2D- oder 3D-Texturen, die es dem Shader ermöglichen, schnell auf verschiedene Texturlayer zuzugreifen, ohne die Shader-Bindings ändern zu müssen. Dies ist nützlich für Terrain-Layering oder das Verwalten von Textursätzen.
+
+3.3.2 Normal Mapping
+
+Normal Mapping ist eine Bump-Mapping-Technik, die mittels einer speziellen Textur, der Normal Map, detaillierte Oberflächenbeleuchtung simuliert, ohne die Geometrie zu erhöhen.
+
+Tangent Space: Da die in der Normal Map gespeicherten Normalenvektoren typischerweise relative Normalen sind, lokal zum Polygon, müssen die Beleuchtungsberechnungen im Tangent Space durchgeführt werden.
+
+TBN Matrix: Um die Normalen aus der Textur korrekt im Raum zu orientieren, wird eine Basis aus drei Vektoren definiert: der Tangente T, der Bitangente B und der geometrischen Normale N. Diese drei Vektoren bilden die TBN-Matrix, die es ermöglicht, die Beleuchtungsvektoren, Lichtrichtung L, Blickrichtung V, vom Weltraum in den Tangent Space zu transformieren, sodass sie mit der Normalen aus der Textur verglichen werden können.
+
+3.3.3 Parallax Mapping
+
+Parallax Mapping nutzt das Prinzip der Parallaxe, der scheinbaren Verschiebung von Objekten bei Änderung des Blickwinkels, um eine Illusion von Tiefe auf einer flachen 2D-Textur zu erzeugen.
+
+Funktion: Die Technik verwendet eine Höhenkarte, Height Map, ein Graustufenbild, wobei hellere Werte höhere Bereiche darstellen, und verschiebt die UV-Koordinaten des Texels abhängig vom Blickwinkel des Betrachters.
+
+UV-Verschiebung: Die Verschiebung Delta UV wird in Abhängigkeit von der Höhe H aus der Höhenkarte und dem Blickvektor V ts im Tangent Space berechnet. Wenn der Blickwinkel steiler ist, flacher Winkel zur Oberfläche, ist die Verschiebung größer, was die Tiefenillusion verstärkt.
+
+Erweiterte Formen: Einfaches Parallax Mapping berücksichtigt keine Selbstverdeckung. Techniken wie Parallax Occlusion Mapping, POM, nutzen iterative Verfahren, zum Beispiel Ray-Marching, gegen das Höhenfeld, um den korrekten Schnittpunkt zu finden und somit Selbstverschattung und präzisere Silhouetten zu ermöglichen.
+
+Schlussfolgerung
+
+Die Beherrschung der DirectX-Pipeline erfordert ein tiefes Verständnis der Interaktion zwischen programmierbaren Stufen und GPU-Architektur. Prüfungsrelevant sind insbesondere die Schnittstellen, Semantiken, die Optimierungsansätze, HLSL Packing und Vertex Caching durch Index Buffer, und die Trade-offs zwischen Qualität und Performance.
+
+Die evolutionären Schritte in der Pipeline zeigen eine klare Verschiebung hin zu mehr GPU-Kontrolle, Tessellation, Mesh Shaders als Ersatz für GS. Im Bereich Beleuchtung bleibt Blinn-Phong der Standard aufgrund seiner Balance zwischen Qualität und Leistung. Bei Texturen stellen Mipmaps und Anisotropic Filtering nicht nur Qualitätsverbesserungen dar, sondern sind fundamentale Mechanismen zur effizienten Bandbreitennutzung und Cache-Optimierung auf modernen GPU-Systemen. Die korrekte Anwendung von TBN-Matrizen und Parallax-Algorithmen ermöglicht es schließlich, visuelle Komplexität zu simulieren, die weit über die tatsächliche Geometriedichte hinausgeht.

Grafik/Hackbarth/Tag2_Themen.md

@@ -0,0 +1,84 @@
+Erstelle einen umfassenden, detaillierten Lernbericht zu folgenden DirectX-Berechnungsthemen für Grafikprogrammierung:
+TEIL 1: Vertices & Buffer-Berechnungen
+- Vertex-Struktur und Attribute:
+  * Position: 3D-Koordinaten (x, y, z), Datentyp float, Speichergröße
+  * Normale: Normalisierter Vektor (nx, ny, nz), Verwendung für Beleuchtung
+  * Tangente und Binormale: Für Normal Mapping, Speichergröße
+  * UV-Koordinaten: Texturkoordinaten (u, v), Wertebereich [0,1]
+  * Farbe: RGBA vs. ARGB, Byte vs. Float-Repräsentation
+- Vertex-Count-Berechnungen für verschiedene Geometrien:
+  * Würfel: Warum 24 Vertices statt 8? (4 Vertices pro Fläche × 6 Flächen)
+  * Quad/Plane: Vertex-Count mit und ohne Shared Vertices
+  * Zylinder: Berechnung basierend auf Segmenten (Seitenflächen + Deckel)
+  * Kugel/Sphere: Berechnung basierend auf Längen- und Breitengraden
+- Vertex-Buffer-Größenberechnung:
+  * Formel: Anzahl Vertices × Bytes pro Vertex
+  * Detaillierte Beispiele:
+    - Position (3 floats) + Normal (3 floats) + UV (2 floats) = 8 floats
+    - 8 floats × 4 Bytes = 32 Bytes pro Vertex
+    - Würfel: 24 Vertices × 32 Bytes = 768 Bytes
+  * Verschiedene Vertex-Formate und deren Größen
+  * Padding und Alignment-Regeln (16-Byte-Alignment)
+  * Beispielrechnungen mit verschiedenen Attribut-Kombinationen
+- Vertex-Buffer-Typen:
+  * Static vs. Dynamic vs. Staging Buffers
+- Praktische Übungsaufgaben:
+  * Berechne Vertex-Buffer-Größe für verschiedene Mesh-Typen
+TEIL 2: Index-Buffer-Berechnungen
+- Index-Buffer-Grundlagen:
+  * Zweck: Vertex-Wiederverwendung, Memory-Effizienz
+  * Index-Datentypen: 16-bit (WORD, 0-65535) vs. 32-bit (DWORD)
+- Triangle List Index-Berechnungen:
+  * Formel: Anzahl Dreiecke × 3 Indices
+  * Index-Buffer-Größe: 36 Indices × 2 Bytes (WORD) = 72 Bytes
+- Index-Count für verschiedene Primitive-Typen:
+  * Triangle List: N Dreiecke = 3N Indices
+  * Triangle Strip: N Dreiecke = N+2 Indices (Effizienz!)
+  * Triangle Fan: N Dreiecke = N+2 Indices
+  * Line List: N Linien = 2N Indices
+  * Line Strip: N Linien = N+1 Indices
+- Detaillierte Geometrie-Berechnungen:
+  * Würfel: 12 Dreiecke (Triangle List) vs. optimierte Strip-Varianten
+  * Quad: 2 Dreiecke, 6 Indices (List) vs. 4 Indices (Strip)
+  * Zylinder: Mantel + Deckel, Index-Berechnung
+  * Kugel: Segments × Rings × 6 Indices (bei Triangle List)
+TEIL 3: Transformationen und Koordinatensysteme
+- Coordinate Spaces im Detail:
+  * Local/Object Space: Mesh-eigenes Koordinatensystem, Origin am Pivot
+  * World Space: Globales 3D-Koordinatensystem der Szene
+  * View/Camera/Eye Space: Kamera am Origin, Blickrichtung -Z
+  * Clip Space: Nach Projection, homogene Koordinaten, [-1,1] oder [0,1]
+  * Screen/Viewport Space: 2D-Pixel-Koordinaten
+- Transformations-Pipeline:
+  * Reihenfolge: Local → World → View → Projection → Clip → Screen
+  * Matrix-Multiplikation: Vertex × Model × View × Projection
+  * Warum diese Reihenfolge?
+- Model/World Transformation:
+  * Translation: Verschiebung im Raum, Translation Matrix
+  * Rotation: Um X, Y, Z-Achse, Euler Angles, Rotation Matrices
+  * Scaling: Uniform vs. Non-Uniform, Scaling Matrix
+  * Kombinierte Transformation: Scale → Rotate → Translate (SRT)
+  * Matrix-Multiplikations-Reihenfolge und deren Bedeutung
+- View Transformation:
+  * Look-At Matrix: Eye Position, Target, Up-Vector
+  * Kamera-Position und Orientierung
+  * View Matrix Berechnung
+- Projection Transformation:
+  * Perspective Projection: FOV (Field of View), Aspect Ratio, Near/Far Plane
+  * Orthographic Projection: Left, Right, Top, Bottom, Near, Far
+  * Perspective, Orthographic Matrix Aufbau und Vergleich
+- Homogene Koordinaten:
+  * 4D-Vektoren (x, y, z, w) für 3D-Grafik
+  * Warum w-Komponente? Perspektivische Teilung, Translation in Matrix-Form
+  * Homogenisierung: Division durch w nach Projection
+  * w = 0 für Richtungsvektoren, w = 1 für Punkte
+  * Perspective Divide: (x/w, y/w, z/w)
+- Viewport Transformation:
+  * Clip Space [-1,1] → Screen Space [0, Width]×[0, Height]
+  * Viewport-Parameter: X, Y, Width, Height, MinDepth, MaxDepth
+  * Depth Buffer Mapping [0,1]
+- Praktische Transformations-Beispiele:
+  * Schritt-für-Schritt: Vertex durch alle Transformationen
+  * Numerische Berechnungen mit Beispiel-Matrizen
+  * Verständnis: Was passiert in jedem Space?
+Füge zu jedem Abschnitt hinzu: Schritt-für-Schritt-Berechnungen, Formeln in mathematischer Notation, konkrete Zahlenbeispiele, Visualisierungen (beschreibe sie textuell), häufige Rechenfehler. Strukturiere den Bericht so, dass Berechnungswege klar nachvollziehbar sind und sich für Karteikarten mit Rechenaufgaben eignen. Erstelle Übungsaufgaben mit Lösungen für jedes Thema.

Grafik/Hackbarth/Tag3_Themen.md

@@ -0,0 +1,86 @@
+Erstelle einen detaillierten Lernbericht zu Shader, Lighting und Texturen in DirectX. Fokussiere auf prüfungsrelevante Konzepte mit prägnanten Erklärungen und praktischen Beispielen:
+
+TEIL 1: Shader-Programmierung
+- Die 6 Shader-Typen (Grundfunktion, Input/Output, Verwendungszweck):
+  * Vertex Shader (VS): Vertex-Transformation, Position-Berechnung, Attribute-Weiterleitung
+  * Hull Shader (HS): Tesselation Control, Patch-Verarbeitung, Tesselation-Faktoren
+  * Domain Shader (DS): Tesselation Evaluation, neue Vertices generieren
+  * Geometry Shader (GS): Primitive-Manipulation, Stream-Out, zusätzliche Geometrie erzeugen
+  * Pixel Shader (PS): Per-Pixel-Farbe, Lighting, Texturing
+  * Compute Shader (CS): General Purpose GPU Computing, nicht in Rendering-Pipeline
+- Shader-Ressourcen:
+  * Vertex Buffer: Input für Vertex Shader, Vertex-Daten (Position, Normal, UV, etc.)
+  * Index Buffer: Definiert Primitive-Topologie, optimiert Vertex-Sharing
+  * Constant Buffer: Uniforme Daten (Matrizen, Lichtdaten, Material), updates per Frame/Object
+  * Unterschiede: Buffer-Typen, Binding-Slots, Update-Frequenz
+- HLSL (High Level Shading Language):
+  * Syntax: C-ähnlich, Datentypen (float, float2-4, matrix, struct)
+  * Semantiken: Bindings zwischen Pipeline-Stages (POSITION, NORMAL, TEXCOORD, SV_Position, SV_Target)
+  * Input-Semantiken: Was kommt rein? (z.B. POSITION0)
+  * Output-Semantiken: Was geht raus? (z.B. SV_Position für Vertex Shader)
+  * System-Value-Semantiken: SV_* (spezielle GPU-Werte)
+  * Shader-Kompilierung: .hlsl → Bytecode
+- Shader-Pipeline-Flow:
+  * Datenfluss durch alle Stages
+  * Welche Shader sind verpflichtend? (VS + PS minimal)
+  * Optional: HS+DS (Tesselation), GS
+TEIL 2: Lighting (Beleuchtung)
+- Lichtquellen-Typen:
+  * Directional Light: Parallele Strahlen, keine Position, nur Richtung (z.B. Sonne)
+  * Point Light: Strahlt in alle Richtungen, Position + Reichweite, Attenuation
+  * Spot Light: Kegelförmig, Position + Richtung, Inner/Outer Cone Angle, Attenuation
+  * Vergleich: Berechnungsaufwand, Anwendungsfälle
+- Licht-Komponenten (Beleuchtungsmodell):
+  * Ambient: Konstante Grundhelligkeit, keine Richtung, simuliert indirektes Licht
+  * Diffuse: Matte Oberfläche, Lambert-Reflexion, abhängig von Normal·Light-Direction
+  * Specular: Glänzende Highlights, abhängig von View-Direction, Shininess/Power
+  * Emission: Selbstleuchtende Objekte, unabhängig von Lichtquellen
+  * Formel: Final = Ambient + Diffuse + Specular + Emission
+- Beleuchtungs-Berechnungen:
+  * Lambert (Diffuse): max(N·L, 0)
+  * Phong Specular: (R·V)^n (Reflection Vector)
+  * Blinn-Phong: (N·H)^n (Half Vector, effizienter)
+  * Attenuation für Point/Spot: 1/(constant + linear*d + quadratic*d²)
+- Vertex Lighting vs. Pixel Lighting:
+  * Vertex Lighting: Berechnung im Vertex Shader, Interpolation, weniger präzise, schneller
+  * Pixel Lighting: Berechnung im Pixel Shader, pro Pixel, präziser, teurer
+  * Vergleich: Qualität, Performance, wann was verwenden?
+  * Gouraud Shading (Vertex) vs. Phong Shading (Pixel)
+TEIL 3: Texturen
+- UV-Mapping:
+  * Texturkoordinaten (u,v): 2D-Koordinaten [0,1] × [0,1]
+  * Mapping: 3D-Vertices → 2D-Textur
+  * UV-Layout, UV-Unwrapping
+  * Texel: Texture Pixel
+- Texture Address Modes (UV-Tiling):
+  * Wrap/Repeat: Textur wiederholt sich (u % 1.0)
+  * Mirror: Spiegelt sich an Grenzen
+  * Clamp: Letzte Texel-Farbe wird wiederholt
+  * Border: Definierte Border-Color außerhalb [0,1]
+  * Anwendung: Tiling von Oberflächen vs. einzelne Objekte
+- Texture Sampling:
+  * Sampler States: Filter-Modi, Address-Modes
+  * Point Filtering: Nächster Texel, blocky
+  * Linear Filtering: Bilineare Interpolation, smooth
+  * Anisotropic Filtering: Qualität bei schrägen Winkeln
+- Mipmapping:
+  * Zweck: Performance, Anti-Aliasing für Distanz
+  * Mipmap-Stufen: Jede Stufe ist halbe Auflösung
+  * Berechnung Anzahl Stufen: log₂(max(width, height)) + 1
+  * Beispiele: 
+    - 256×256 → Stufen: log₂(256) + 1 = 8 + 1 = 9 Stufen
+    - 512×256 → log₂(512) + 1 = 9 + 1 = 10 Stufen
+    - 1024×1024 → 11 Stufen
+  * Memory-Overhead: ~33% zusätzlicher Speicher
+  * Trilinear Filtering: Interpolation zwischen Mipmap-Stufen
+- Texture-Typen:
+  * 1D, 2D, 3D Textures
+  * Cube Maps: 6 Faces für Environment Mapping
+  * Texture Arrays
+- Advanced Texturing:
+  * Normal Mapping: Tangent Space, Detail ohne Geometrie
+  * Parallax Mapping: Tiefenillusion
+  * Multi-Texturing: Mehrere Texturen kombinieren
+Füge hinzu: Kernkonzepte, Formeln, Berechnungsbeispiele für Mipmaps, Code-Snippets in HLSL wo relevant, Vergleichstabellen, und prüfungsrelevante Details. Strukturiere für Karteikarten-Erstellung mit Fokus auf Verständnis und Anwendung.
+
+Erstelle mir bitte nur auf Grundlage der Quelle: ("Detaillierte Analyse der GPU-Pipeline in DirectX: Shader, Beleuchtung und Texturierung") Lernkarten zum ausführlichen Lernen der Inhalte und decke bitte alles ab.

Grafik/Hackbarth/Zeitplan.md

@@ -0,0 +1,85 @@
+# Zeitplan
+
+## Tag 1: Grundlagen, Fenster & Pipeline-Struktur
+
+**Ziel:** Das "Gerüst" verstehen (Windows, COM) und den Ablauf der Grafikpipeline verinnerlichen.
+
+### 1. Windows & C++ Basics (45 Min)
+
+- Verstehe den Unterschied zwischen Pointer und Handle sowie das COM (Component Object Model).
+- Lerne die Fensternachrichten (`WM_QUIT`, `WM_DESTROY`, `WM_EXIT`) und die Funktion der Messagequeue (`Window Proc`).
+- Frage dich: Wozu braucht man Nachrichten?
+
+### 2. Die Pipelines (1 Std.)
+
+- Vergleiche Fixed Function vs. Programmable Pipeline.
+- Lerne die Elemente der Pipeline auswendig: Vertex, Mesh, Transformation, Primitives (Unterschied List vs. Strip).
+- Schau dir die Stages an: Rasterizer (Front/Back Faces) und Screen-Stage.
+
+### 3. DirectX Versionen (30 Min)
+
+- Unterscheide Direct3D9 (Device) vs. Direct3D11 (Device Context vs. Device).
+
+---
+
+## Tag 2: Berechnungen (Der "Anwendungs"-Teil)
+
+**Ziel:** Die Rechenaufgaben sicher beherrschen. Der Taschenrechner ist erlaubt, also übe den Weg.
+
+### 1. Vertices & Buffer berechnen (1,5 Std.) – WICHTIG
+
+- Verinnerliche das Beispiel aus der Quelle: Ein Würfel braucht 24 Vertices (4 pro Fläche × 6 Flächen), nicht 8, wegen der Normalen.
+- Berechne die Vertexgröße:
+    - Position (3 Floats) + Normale (3 Floats) + UV (2 Floats) = 8 Floats
+    - 8 Floats × 4 Byte = 32 Byte pro Vertex
+- Gesamtgröße Vertexbuffer: 24 Vertices × 32 Byte = 768 Byte
+
+### 2. Indexbuffer berechnen (45 Min)
+
+- Verstehe die `Triangle List`: 6 Flächen × 2 Dreiecke × 3 Ecken = 36 Indices.
+- Rechnung: 36 Indices × 2 Byte (Word) = 72 Byte
+
+### 3. Transformationen (30 Min)
+
+- Lerne die Reihenfolge der Spaces: Local Space → World → View → Projection
+- Verstehe homogenisierte Koordinaten.
+
+---
+
+## Tag 3: Shader, Licht & Texturen
+
+**Ziel:** Die programmierbare Pipeline und visuelle Details verstehen.
+
+### 1. Shader (1 Std.)
+
+- Lerne alle 6 Shadertypen und ihre Grundfunktion: Vertex, Hull, Domain, Geometry, Pixel, Compute.
+- Was sind Shader Ressources (Vertex-, Index-, Constantbuffer)?
+- Was ist HLSL und wozu dienen Semantiken?
+
+### 2. Lighting (1 Std.)
+
+- Kenne die Lichtquellen (Directional, Point, Spot) und Lichtbestandteile (Ambient, Diffuse, Specular, Emission).
+- Unterschied: Vertex-Lighting vs. Pixel-Lighting
+
+### 3. Texturen (30 Min)
+
+- UV-Mapping und UV-Tiling (Address Modes) verstehen.
+- Mipmapping: Stufen zählen können.
+
+---
+
+## Tag 4: Wiederholung & Lücken füllen
+
+**Ziel:** Wissen festigen und Details prüfen.
+
+### 1. Datentypen-Check (1 Std.)
+
+- Gehe konkrete Datentypen aus dem Framework (D3D9/D3D11) durch.
+
+### 2. Simulation (1 Std.)
+
+- Rechne ein Beispiel für Vertex- und Indexbuffer mit anderen Werten durch (z.B. nur eine Fläche oder eine Pyramide), um sicherzugehen, dass du das Prinzip (Vertices pro Fläche zählen) verstanden hast.
+
+### 3. Review (30 Min)
+
+- Gehe die Liste in `Klausurthemen.md` noch einmal Punkt für Punkt durch. Alles abgehakt?