mirror of
https://github.com/theoleuthardt/hwr-notes.git
synced 2026-06-05 23:51:09 +00:00
docs: add obsidian hwr docs
This commit is contained in:
theoleuthardt
parent
b2636f4b92
commit
850aa3455d
245 changed files with 30757 additions and 0 deletions
BIN
Grafik/.DS_Store
vendored
Normal file
BIN
Grafik/.DS_Store
vendored
Normal file
Binary file not shown.
BIN
Grafik/Hackbarth/.DS_Store
vendored
Normal file
BIN
Grafik/Hackbarth/.DS_Store
vendored
Normal file
Binary file not shown.
22
Grafik/Hackbarth/Hackbarth Einstiegsprojekt.md
Normal file
22
Grafik/Hackbarth/Hackbarth Einstiegsprojekt.md
Normal file
|
|
@ -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;
|
||||
};
|
||||
```
|
||||
96
Grafik/Hackbarth/Klausurthemen.md
Normal file
96
Grafik/Hackbarth/Klausurthemen.md
Normal file
|
|
@ -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**
|
||||
BIN
Grafik/Hackbarth/Klausurthemen.pdf
Normal file
BIN
Grafik/Hackbarth/Klausurthemen.pdf
Normal file
Binary file not shown.
29
Grafik/Hackbarth/Links & Lighting.md
Normal file
29
Grafik/Hackbarth/Links & Lighting.md
Normal file
|
|
@ -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
|
||||
400
Grafik/Hackbarth/Tag1_Bericht.md
Normal file
400
Grafik/Hackbarth/Tag1_Bericht.md
Normal file
|
|
@ -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]]
|
||||
200
Grafik/Hackbarth/Tag2_Bericht.md
Normal file
200
Grafik/Hackbarth/Tag2_Bericht.md
Normal file
|
|
@ -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.
|
||||
84
Grafik/Hackbarth/Tag2_Themen.md
Normal file
84
Grafik/Hackbarth/Tag2_Themen.md
Normal file
|
|
@ -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.
|
||||
0
Grafik/Hackbarth/Tag3_Bericht.md
Normal file
0
Grafik/Hackbarth/Tag3_Bericht.md
Normal file
86
Grafik/Hackbarth/Tag3_Themen.md
Normal file
86
Grafik/Hackbarth/Tag3_Themen.md
Normal file
|
|
@ -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.
|
||||
85
Grafik/Hackbarth/Zeitplan.md
Normal file
85
Grafik/Hackbarth/Zeitplan.md
Normal file
|
|
@ -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?
|
||||
BIN
Grafik/Kalki/Entropiecodierung.pdf
Normal file
BIN
Grafik/Kalki/Entropiecodierung.pdf
Normal file
Binary file not shown.
211
Grafik/Kalki/Hausaufgabe 1.md
Normal file
211
Grafik/Kalki/Hausaufgabe 1.md
Normal file
|
|
@ -0,0 +1,211 @@
|
|||
Name: Theo Leuthardt
|
||||
Datum: 09.09.2025
|
||||
|
||||
---
|
||||
#### Aufgabe 1:
|
||||
##### Definition und Grundverständnis:
|
||||
**Multimedia** bezeichnet die Integration verschiedener Medientypen (Text, Grafik, Audio, Video, Animation) in einem System zur gemeinsamen Verarbeitung und Präsentation über die Wahrnehmung des Menschen mithilfe seiner sechs Sinne.
|
||||
##### Verschiedene Sichtweisen und Aspekte:
|
||||
**Technische Perspektive:**
|
||||
- Verarbeitung verschiedenen Typen von Daten (Text, Bild, Audio, Video)
|
||||
- Herausforderungen bei Speicherung und Übertragung (Höhere Qualität = größere Speichernutzung z.B.)
|
||||
- _Problem:_ Hohe Hardwareanforderungen und Bandbreite
|
||||
|
||||
**Benutzerperspektive:**
|
||||
- Interaktive und ansprechende Benutzererfahrung bei einer Multimediaanwendung
|
||||
- Verschiedene Lerntypen werden angesprochen: z.B. visuell oder hörender
|
||||
- _Vorteil:_ Besseres Verständnis durch multiple Sinneskanäle und damit mehr Optionen zur Aufnahme von Informationen
|
||||
- _Nachteil:_ Mögliche kognitive Überlastung
|
||||
|
||||
**Historische Entwicklung:**
|
||||
- Von statischen Medien zu interaktiven Systemen über die zeitliche Entwicklung von Multimedia
|
||||
- Evolution von Medien auf CD-ROM zu Web-basierten Anwendungen für die Anzeige, Wiedergabe oder Spielbarkeit der Medien
|
||||
##### Kritische Bewertung:
|
||||
**Stärken:**
|
||||
- Erhöhte Informationsdichte durch die Ansammlung an Informationen in oben genannten Datentypen
|
||||
- Bessere Wissensvermittlung durch mehrere Möglichkeiten des Lernens für die verschiedenen Lerntypen
|
||||
- Zugänglichkeit für verschiedene Nutzergruppen: z.B. Barrierefreiheit für behinderte Menschen
|
||||
- Möglichkeit zum Erleben von Phantasiewelten in immer realer aussehenden Bewegbildproduktionen (Geschichten aus Büchern werden Realität in 4K/8K-Filmen mit Animationen oder Realverfilmungen)
|
||||
|
||||
**Schwächen:**
|
||||
- Ansteigende Komplexität in Entwicklung und Wartung multimedialer Anwendungen oder von Medien selber
|
||||
- Hohe Kosten der Produktionen (egal ob multimediale Anwendungen oder Filmproduktionen) und technische Anforderungen bei der Entwicklung
|
||||
- Abhängigkeit von technischer Infrastruktur je nach Typ des Mediums: z.B. Grafische Datenverarbeitung mithilfe der GPU bei der Erstellung eines Modells in Blender
|
||||
##### Fazit:
|
||||
Multimedia ist nicht nur eine technische Integration verschiedener Medientypen, sondern ein paradigmatischer Ansatz zur Informationsvermittlung, der sowohl große Chancen als auch erhebliche Herausforderungen mit sich bringt.
|
||||
|
||||
---
|
||||
#### Aufgabe 2:
|
||||
##### Entropiecodierung:
|
||||
- Versucht die theoretische Grenze der verlustfreien Kompression zu erreichen (Entropie)
|
||||
- Daten werden komprimiert durch Reduktion der Codierungsredundanz mithilfe der Symbolverteilung
|
||||
- Häufige Symbole erhalten kürzere Codes
|
||||
- Erhöhung der Informationsdichte für die effizientere Nutzung des Speicherplatzes
|
||||
- Beispiele: Huffman-Codierung, Arithmetische Codierung
|
||||
Quelle: https://link.springer.com/chapter/10.1007/978-3-322-92815-3_4
|
||||
##### Quellcodierung:
|
||||
- Erstellt eine Zuordnung von Symbolen zu Codewörtern zur Umwandlung von Daten in eine für die Kompression optimierte Form, um Redundanzen zu reduzieren
|
||||
- Nutzt Eigenschaften der menschlichen Wahrnehmung
|
||||
- Findung effizienterer Darstelltungen z.B. eine Codetabelle
|
||||
- Beispiele: DCT bei JPEG (Transformation), Prädiktive Codierung
|
||||
- Oft höhere Kompressionsraten als reine Entropiecodierung
|
||||
|
||||
---
|
||||
#### Aufgabe 3:
|
||||
##### Unformatierter Text (Plain Text):
|
||||
- Reine Zeichenketten ohne Formatierung
|
||||
- ASCII, UTF-8, UTF-16 (zeichenkettenkodiert), Unicode
|
||||
- Beispiel: .txt-Dateien
|
||||
##### Formatierter Text:
|
||||
- Enthält Formatierungsinformationen
|
||||
- Schriftart, -größe, -farbe, Ausrichtung
|
||||
- Beispiel: RTF (Rich Text Format)
|
||||
##### Strukturierter Text (Tagged Text):
|
||||
- Hierarchische oder logische Struktur zur Strukturierung des Textes
|
||||
- Markup-Sprachen (XML, HTML)
|
||||
- Metadaten und Tags
|
||||
##### Hypertext:
|
||||
- Verknüpfte Textdokumente
|
||||
- Navigation durch Links
|
||||
- Realisierungen: Webseiten, Wiki-Systeme
|
||||
|
||||
---
|
||||
#### Aufgabe 4:
|
||||
|
||||
##### Card Shark:
|
||||
Card Shark ist **kartenbasiertes System**, worin jede "Karte" eine Informationseinheit enthält. Die Navigation erfolgt zwischen Karten über Links, was dem Hypercard-Konzept ähnelt. Hierbei handelt es sich im ein statisches Informationsmodell zur textbasierten Darstellung von Informationen.
|
||||
##### Holly Scroller:
|
||||
Holly Scroller sind ein **scrollbasiertes System**, worin ein kontinuierlicher Informationsfluss herrscht mit vertikaler oder horizontaler Navigation. Durch die vertikale oder horizontale Darstellung wird eine dynamische Anzeige von Inhalten ermöglicht. Da es keine Informationen zugewiesen zu einer "Karte" gibt aus den Card Sharks, ist die Navigation weniger strukturiert.
|
||||
|
||||
---
|
||||
#### Aufgabe 5:
|
||||
|
||||
##### Strukturelle Links (Navigational Links):
|
||||
- Hierarchische Beziehungen (Parent-Child)
|
||||
- Sequenzielle Navigation (Next-Previous)
|
||||
##### Referentielle Links (Referential Links):
|
||||
- Verweise auf verwandte Inhalte
|
||||
- Querverweise, Zitate
|
||||
##### Organisatorische Links (Document Structural Links):
|
||||
- Gruppierung ähnlicher Inhalte
|
||||
- Kategorisierung
|
||||
##### Assoziative Links (Associative Links):
|
||||
- Thematische Verbindungen
|
||||
- Konzeptuelle Zusammenhänge
|
||||
##### Annotative Links (Annotation Links):
|
||||
- Kommentare und Ergänzungen
|
||||
- Erklärungen zu Begriffen
|
||||
|
||||
---
|
||||
#### Aufgabe 6:
|
||||
##### JPEG-Quantisierung: DCT-Transformation (Diskrete Cosinus-Transformation)
|
||||
Die DCT transformiert Bilddaten vom Ortsbereich in den Frequenzbereich und bildet den Mittelpunkt der JPEG-Kompression. Dabei wird das Bild in 8×8 Pixel-Blöcke aufgeteilt und jeder Block einzeln verarbeitet.
|
||||
Die DCT nutzt Cosinus-Funktionen als Basisfunktionen und jede Funktion kann als Summe von Cosinus-Funktionen dargestellt werden.
|
||||
Für eine N×N Matrix wird die DCT-Matrix wie folgt berechnet:
|
||||
- Für m=0: DCT[m][n] = √(1/N)
|
||||
- Für m>0: DCT[m][n] = √(2/N) × cos((2n+1)πm/(2N))
|
||||
###### Quantisierungsmatrix
|
||||
JPEG teilt jeden DCT-Wert durch einen Quantisierungsfaktor, der dann zur nächsten ganzen Zahl gerundet wird. Die Quantisierungsmatrix ist eine 8×8-Tabelle mit spezifischen Koeffizienten für jeden Frequenzbereich.
|
||||
|
||||
**Aufbau der Matrix:**
|
||||
- Kleinere Werte in der oberen linken Ecke (niedrige Frequenzen)
|
||||
- Größere Werte in der unteren rechten Ecke (hohe Frequenzen)
|
||||
- Kleine Koeffizienten für niedrige Frequenzen und große Koeffizienten für hohe Frequenzen
|
||||
|
||||
**Beispiel einer Standard-Quantisierungsmatrix:**
|
||||
|
||||
```
|
||||
16 11 10 16 24 40 51 61
|
||||
12 12 14 19 26 58 60 55
|
||||
14 13 16 24 40 57 69 56
|
||||
14 17 22 29 51 87 80 62
|
||||
18 22 37 56 68 109 103 77
|
||||
24 35 55 64 81 104 113 92
|
||||
49 64 78 87 103 121 120 101
|
||||
72 92 95 98 112 100 103 99
|
||||
```
|
||||
|
||||
###### Rundung und Informationsverlust
|
||||
Nach der Division durch die Quantisierungsmatrix werden die Ergebnisse zur nächsten ganzen Zahl gerundet. Dieser Schritt verursacht den charakteristischen Informationsverlust der JPEG-Kompression:
|
||||
- Nachkommastellen gehen unwiderruflich verloren
|
||||
- Kleinere DCT-Koeffizienten werden oft zu Null gerundet
|
||||
- Je größer der Quantisierungsfaktor, desto mehr Informationen gehen verloren
|
||||
###### Qualitätsfaktor
|
||||
Der Qualitätsfaktor skaliert die gesamte Quantisierungsmatrix und bestimmt das Verhältnis zwischen Kompression und Bildqualität:
|
||||
|
||||
**Funktionsweise:**
|
||||
- Niedrigere Qualitätswerte = größere Quantisierungskoeffizienten = mehr Kompression, schlechtere Qualität
|
||||
- Höhere Qualitätswerte = kleinere Quantisierungskoeffizienten = weniger Kompression, bessere Qualität
|
||||
- In Bildbearbeitungsprogrammen entspricht die "Qualitäts"-Einstellung der Modifikation dieser Koeffizienten
|
||||
|
||||
**Mathematische Beziehung:**
|
||||
Quantisierte Matrix = round(DCT Koeffizienten / (Quantisierungsmatrix * Qualitätsfaktor))
|
||||
|
||||
**Quelle:** https://dev.to/marycheung021213/understanding-dct-and-quantization-in-jpeg-compression-1col
|
||||
|
||||
---
|
||||
#### Aufgabe 7:
|
||||
##### Geschlechtsspezifische Unterschiede:
|
||||
- **Stimmfrequenzen**: Männer (85-180 Hz), Frauen (165-265 Hz)
|
||||
- **Formanten**: Unterschiedliche Resonanzfrequenzen in der Stimme
|
||||
##### Mögliche Optimierungen:
|
||||
- Angepasste Frequenzbänder-Aufteilung
|
||||
- Optimierte Bit-Allokation für relevante Frequenzbereiche
|
||||
- Geschlechtsspezifische psychoakustische Modelle
|
||||
- Adaptive Codierung basierend auf Sprecheridentifikation
|
||||
|
||||
Anhand dieser Ansätze wäre ein solches MP3-Codierungsmodell denkbar, jedoch muss auch die reale Nutzbarkeit beachtet werden, da eine automatische Geschlechtserkennung fehleranfällig wäre und gemischte Inhalte wie z.B. Duette zu Schwierigkeiten führen können. Außerdem besteht abseits davon ein Diskrimierungspotential bei automatischer Klassifizierung für nur marginale Verbesserungen aus technischer Sicht.
|
||||
|
||||
---
|
||||
#### Aufgabe 8:
|
||||
##### Intraframe-Codierung (I-Frames):
|
||||
- JPEG-ähnliche Kompression einzelner Bilder
|
||||
- DCT, Quantisierung, Entropiecodierung
|
||||
##### Interframe-Codierung (P-/B-Frames):
|
||||
- **Motion Compensation**: Bewegungsschätzung zwischen Frames
|
||||
- **Differenzcodierung**: Nur Unterschiede werden codiert
|
||||
- **Predictive Coding**: Vorhersage basierend auf vorherigen Frames
|
||||
##### Moderne Verfahren:
|
||||
- **H.264/AVC**: Advanced Video Coding
|
||||
- **H.265/HEVC**: High Efficiency Video Coding
|
||||
- **AV1**: Open-Source-Codec von Alliance for Open Media
|
||||
- **VP9**: Google-entwickelter Codec
|
||||
|
||||
---
|
||||
#### Aufgabe 9:
|
||||
##### Szenario A: MIT Beitragsservice (GEZ)
|
||||
**Struktur:**
|
||||
- ARD/ZDF bleiben zentrale öffentlich-rechtliche Anbieter
|
||||
- Pflichtfinanzierung sichert Grundversorgung
|
||||
- Private Streaming-Dienste als Ergänzung
|
||||
**Vorteile:**
|
||||
- Unabhängige, werbefreie Inhalte
|
||||
- Bildungsauftrag und Informationsqualität
|
||||
- Regionale/lokale Berichterstattung garantiert
|
||||
**Herausforderungen:**
|
||||
- Konkurrenzdruck durch Netflix, Amazon Prime
|
||||
- Generationswechsel zu Streaming-Plattformen
|
||||
- Legitimationsdruck bei jüngeren Zielgruppen
|
||||
##### Szenario B: OHNE Beitragsservice
|
||||
**Struktur:**
|
||||
- Vollständig privatisierte/kommerzialisierte Medienlandschaft
|
||||
- Abo-Modelle und werbefinanzierte Dienste
|
||||
- Marktbasierte Inhaltsproduktion
|
||||
**Vorteile:**
|
||||
- Marktorientierte, nachfragebasierte Inhalte
|
||||
- Keine Zwangsfinanzierung
|
||||
- Höhere Innovationsrate
|
||||
**Risiken:**
|
||||
- Verlust der Meinungsvielfalt
|
||||
- Kommerzialisierung aller Inhalte
|
||||
- Benachteiligung einkommensschwacher Schichten
|
||||
- Wegfall gesellschaftlich wichtiger, aber nicht profitabler Inhalte
|
||||
##### Lösung: Hybridmodell
|
||||
**Reformierter öffentlich-rechtlicher Bereich:**
|
||||
- Reduzierte, zielgerichtete Finanzierung
|
||||
- Fokus auf Nachrichten, Bildung, Kultur
|
||||
- Stärkere digitale Präsenz durch Apps und Webseiten
|
||||
**Ergänzung durch Privatanbieter:**
|
||||
- Entertainment und spezialisierte Inhalte
|
||||
- Innovative Distributionsformen
|
||||
- Internationale Zusammenarbeit
|
||||
6
Grafik/Kalki/White Lavender Review/Aufnahmen.md
Normal file
6
Grafik/Kalki/White Lavender Review/Aufnahmen.md
Normal file
|
|
@ -0,0 +1,6 @@
|
|||
# Aufnahmen
|
||||
- [x] Startsequenz ✅ 2025-11-28
|
||||
- [x] Walking Video ✅ 2025-11-28
|
||||
- [x] Dodge Roll ✅ 2025-11-28
|
||||
- [x] Fight ✅ 2025-11-28
|
||||
- [x] Look at Screen ✅ 2025-11-28
|
||||
68
Grafik/Kalki/White Lavender Review/Drehbuch.md
Normal file
68
Grafik/Kalki/White Lavender Review/Drehbuch.md
Normal file
|
|
@ -0,0 +1,68 @@
|
|||
---
|
||||
share_link: https://share.note.sx/70wu5aar#4yyPDdY8sVCpafWbQGK11IQo17686i7Qy9lQN8lPBiY
|
||||
share_updated: 2025-11-29T18:09:53+01:00
|
||||
---
|
||||
# Drehbuch
|
||||
|
||||
Review zum Spiel "White Lavender"
|
||||
|
||||
### Anforderungen:
|
||||
|
||||
###### 1. Was soll vermittelt werden:
|
||||
|
||||
- Grundlagen und Struktur von Soulslikespielen in Action-RPGs
|
||||
- Bewertung der Inhalte des Spiels "White Lavender"
|
||||
- Bewertung der technischen Anforderungen des Spiels
|
||||
- Fazit zum Spiel und Empfehlung
|
||||
- Ziel: Comedyreview (Mischung aus ehrlicher Analyse und witzigen Elementen)
|
||||
|
||||
###### 2. Zielgruppe:
|
||||
- Gamer, Streamer
|
||||
|
||||
### Styleguide/Design:
|
||||
- Startszene von Reviewern
|
||||
- Spiel im Full Screen
|
||||
- Gameplay im Hintergrund
|
||||
- Review in Audioformat
|
||||
|
||||
### Technischer Entwurf:
|
||||
- Videoformat: mkv, mov
|
||||
- Editor: Davinci Resolve
|
||||
- Audioaufnahme: Audacity
|
||||
- Audioformat: 48kHz, FLAC-Format, Stereo, 24Bit (verlustfreie kompression)
|
||||
- Geteilter Speicher für Audios/Videos: NAS-Speicher
|
||||
- Geteiltes Skript schreiben: Google Docs
|
||||
|
||||
### Skript:
|
||||
|
||||
| Szenen-Nr. | Titel | Inhalte | Bild | Audio/Kommentar | Dauer | |
|
||||
| ---------- | ---------- | --------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------- | --- |
|
||||
| 1 | INTRO | Energetischer Einstieg ins Review | Energetischer Einstieg | "Was passiert, wenn ihr Soulslikes nehmt, einen CRT-Filter drüberkippt und das Ganze aussehen lasst wie ein Fiebertraum aus den 90ern? Richtig – White Lavender! Heute schauen wir uns dieses bunte Indie-Soulslike an, das beweist, dass man nicht immer düster und ernst sein muss, um schwer zu sein. Spoiler: Es ist chaotisch, es ist bunt, und ja – es hat Bugs. Aber lohnt es sich trotzdem? Let's go!" | 0:00-0:20 | |
|
||||
| 2 | SOULSLIKES | Theoretische Erklärung mit Inhalten was Soulslikes ausmacht | B-Roll: Ausschnitte aus Dark Souls, Elden Ring, etc. | "Für die, die noch nie ein Soulslike gespielt haben – hier ein Crash-Course: Soulslikes sind Action-RPGs, die für ihre knallharte Schwierigkeit berüchtigt sind. Ihr seid ein Kämpfer in einer Welt voller Monster und Gefahren – das Ziel? Überleben und stärker werden. Präzises Timing, Ausdauer-Management, Bosskämpfe die euch an den Rand des Wahnsinns treiben, und wenn ihr sterbt? Dann dürft ihr schön zurücklaufen und eure Seelen einsammeln... falls ihr es bis dahin schafft. Die bekanntesten Vertreter? Dark Souls, Elden Ring, Bloodborne – Spiele die legendär dafür sind, dass Gamer ihre Controller an die Wand werfen. White Lavender nimmt diese Formel und dreht den Weird-Regler auf Maximum." | 0:20-0:45 | |
|
||||
| 3 | GRAFIK | Super einzigartiger retroartiger Grafikstil, sehr bunt, CRT-Filter, lustiges Charakterdesign, Rüstung sichtbar am Charakter | Gameplay von White Lavender mit Fokus auf Visuals, Heranzoomen an Charakter-Füße | "Optisch ist das Spiel einfach nicht so das, was man vom Genre kennt. Aber im guten Sinne! Der retro-artige Grafikstil mit dem CRT-Filter sieht aus, als würde man auf einem alten Röhrenfernseher zocken. Alles ist super bunt und poppig – das komplette Gegenteil von den düsteren Souls-Spielen, die am bekanntesten in dem Genre sind. Das Charakterdesign ist absolut goofy und liebenswert. Und das Beste: Eure Rüstung ist tatsächlich am Charakter sichtbar! Fashion Souls könnte man schon fast sagen. Aber schaut euch mal diese Füße an... die kleben förmlich am Boden. Das Movement ist ebenfalls... nun ja, auch echt speziell. Aber dazu kommen wir jetzt." | 0:45-1:15 | |
|
||||
| 4 | MOVEMENT | Movement des Spiels vorstellen | Movement-Showcase, Movement und Fähigkeiten am Anfang des Spiels zeigen | "Also, sprechen wir über Movement. Am Anfang fühlt sich euer Charakter an wie... naja, wie jemand der in Honig watet. Ihr habt die Basic-Bewegungen: Laufen, Rollen, Springen – aber es fühlt sich etwas schwerfällig an. Die Füße haben wirklich diesen 'klebe-am-Boden-Effekt', was dem Ganzen einen ungewollt komischen Touch gibt. Aber hey, sobald ihr ein paar Fähigkeiten freischaltet und euch an die Physik gewöhnt habt, wird's besser. Es ist anders, aber man gewöhnt sich dran." | 1:15-1:35 | |
|
||||
| 5 | ENEMIES | Combat gegen normale Gegner im Detail bewerten | Kampfszenen gegen normale Gegner, Hitbox-Problem zeigen, verschiedene Waffen zeigen | "Der Combat gegen normale Gegner macht grundsätzlich Spaß – aber er hat leider seine Macken. Timing-basiertes Angreifen, Ausweichen, Ausdauer-Management – das Soulslike-Package ist vollstens vorhanden. ABER: Gerade bei größeren Waffen merkt man den Animation Lock heftig. Einmal geschwungen, seid ihr committed – und dann kanns tödlich sein. Und dann die Hitboxen... besonders bei kleineren Gegnern gehen eure Angriffe manchmal einfach daneben. Das ist frustrierend, wenn ihr wisst, dass der Hit eigentlich sitzen sollte. Aber positiv ist: Das Spiel fördert echt das Waffenexperimentieren! Verschiedene Gebiete, verschiedene Gegnertypen – da lohnt es sich, mehrere Waffen auszuprobieren. Die Waffenvielfalt ist cool, von Standard bis komplett abgedreht." | 1:35-2:00 | |
|
||||
| 6 | BOSSE | Bossdesign und Schwierigkeit des Spiels bewerten | Boss-Kampf-Footage, Endboss-Kampf, Kampfszenen gegen verschiedene Bosse | "Und dann kommen wir zum Herzstück eines jeden Soulslikes, den Bossen... ein zweischneidiges Schwert in diesem Spiel. Das Bossdesign ist kreativ und jeder Boss sieht unique aus. ABER: Die Patterns sind manchmal echt simpel und langweilig. Nach ein, zwei Versuchen habt ihr die meisten Bosse durchschaut. Der Endboss ist im Vergleich zu den anderen Bossen extrem schwach. Wir haben sogar diesen Bug gefunden: [PAUSE] Wenn man direkt unter ihm steht, kann er euch nicht treffen. Da steht man dann und wundert sich... [PAUSE] Die Schwierigkeit ist also sehr inkonsistent – manche Bosse machen euch das Leben zur Hölle und andere macht ihr im Schlaf." | 2:00-2:30 | |
|
||||
| 7 | ERKUNDEN | Bewertung des Erlebnisses beim Erkunden des Spiels in der Open World | Open World Exploration, Portal-Reisen, Items aufheben zeigen, Traveling durch Portale (alle Gebiete zeigen), verschiedene Items auffindbar über die Map | "Die Open World zu erkunden macht echt Laune! Ihr reist durch verschiedene Gebiete via Portale – und jedes Gebiet hat seinen eigenen Vibe. Von bunten Wäldern, über dunkle Höhlen bis zu trippy Landschaften ist alles dabei. Überall findet ihr Items, Geheimnisse und versteckte Wege. Es lohnt sich also definitiv, jeden Winkel zu erkunden. [PAUSE] Aber das Gefühl, wenn man einen versteckten Schatz findet? _Chef's kiss_ Unbezahlbar" | 2:25-2:45 | |
|
||||
| 8 | NPCs | NPC-Interaktionen bewerten und dessen Qualität/Tiefe, Questlines, Humorvoller Touch | NPC-Gespräche, Szenen beim Reden mit NPCs | "Die NPCs in White Lavender sind sogar überraschend charmant! Die Dialoge haben einen humorvollen Touch und die Questlines sind echt interessant. Klar, es ist jetzt keine narrative Meisterleistung wie man es von AAA-Titeln kennt, aber die NPCs haben Persönlichkeit und sorgen für ein paar Lacher während des Gameplays. Insgesamt fühlen sich die Interaktionen lebendiger an als man von einem Indie-Titel vielleicht erwarten würde." | 2:45-3:05 | |
|
||||
| 9 | MUSIK | Kurze Erklärung was für Musik genutzt wird (Genre) und ob es zum Charakter des Spiels passt | Hintergrund-Gameplay mit Musik, Hintergrundgameplay von White Lavender | "Der Soundtrack passt perfekt zum psychedelischen Vibe des Spiels. Es ist oft diese Mischung aus ambient und retro-synth Sounds, die das Ganze zusammenhält. Zusätzlich sind auch wirklich häufig Banger dabei, die man jetzt nicht so erwartet hat. Die Musik untermalt so die sowohl entspannenden Momente wie das Erkunden in der Welt als auch die sehr aufregenden Momente des Spiel wie die Bosskämpfe." | 3:05-3:20 | |
|
||||
| 10 | BUGS | Aktuelle Probleme des Spiels und Fehler bei unserem Run | Bug-Footage, spezifische Bug-Beispiele zeigen, Endboss-Bug nochmal zeigen, spezifische Ausschnitte der Bugs | "Okay, jetzt müssen wir noch über den Elefanten im Raum sprechen: nämlich die Bugs im Spiel. Und oh junge, die Liste ist lang. Wir hatten: Enemy Snapping-Probleme – Gegner teleportieren sich plötzlich, Clipping-Issues und Gegner die in Wänden stecken, Framerate-Drops, und der absolute Kracher: Am Ende unseres Runs ließen sich Gegner GAR NICHT MEHR anvisieren. Also so komplett. Das Target-Lock-System hat einfach aufgegeben. Und wie gesagt, der Endboss kann euch nicht treffen wenn ihr unter ihm steht. Das ist jetzt weniger ein Bug und mehr ein 'haben wir nicht gebalanced'-Problem. Für ein Indie-Spiel ist das nicht ungewöhnlich, aber aktuell müsst ihr mit diesen technischen Problemen leider leben. Die Devs patchen hoffentlich fleißig, [PAUSE, dann leise] Gott bewahre... " | 3:20-3:45 | |
|
||||
| 11 | FAZIT | Scoring System und Bewertung zusammenfassen übers Video | Zusammenfassung mit Best-of Footage, Hintergrund: Gameplay (unscharf), Vordergrund: Grafiken der vergebenen Scorings pro Videosektion, Outro | "White Lavender ist ein ambitioniertes Indie-Soulslike mit einer richtig coolen Idee. Der einzigartige Artstyle und die bunte Welt sind erfrischend anders. Das Waffenexperimentieren macht Spaß und die notwendige Varietät ist da. ABER: Die technischen Probleme und Design-Schwächen ziehen das Erlebnis deutlich runter. Animation Lock, miese Hitboxen, simple Bosspatterns, ein viel zu schwacher Endboss, und Bugs die das Spiel teilweise unspielbar machen – das muss man als Spieler auch erstmal schlucken, wenn man das zu spät nach einem Kauf merkt. Es fühlt sich an wie ein Early Access-Titel der noch ein paar Monate Entwicklung braucht. Das Potential ist da, aber aktuell ist es eher was für die hardcore Indie-Fans, die über technische Probleme hinwegsehen können. Wenn die Devs weiter dran arbeiten sollten, könnte das wirklich eine gute Abwechslung zu den eher bekannten Soulslike-Titeln wie eben Dark Souls oder Elden Ring werden. Aber im aktuellen Zustand? Eher schwierig. Habt ihr White Lavender schon gespielt und was sind eure Erfahrungen mit Soulslike Spielen? Lasst es und gerne wissen und bis zum nächsten Mal! | 3:45-4:10 | |
|
||||
|
||||
---
|
||||
|
||||
## NOTIZEN FÜR DIE BEARBEITUNG:
|
||||
|
||||
- **Pacing:** Schnelle Cuts, dynamische Übergänge
|
||||
- **B-Roll:** Viel Gameplay-Material, Bug-Highlights besonders wichtig
|
||||
- **Kritische Momente betonen:**
|
||||
- Animation Lock bei großen Waffen zeigen
|
||||
- Hitbox-Fails bei kleinen Gegnern
|
||||
- Enemy Snapping deutlich machen
|
||||
- Target-Lock Bug am Ende des Videos
|
||||
- Endboss-Schwäche (unter ihm stehen)
|
||||
- Simple/langweilige Bosspatterns
|
||||
- **Musik:** Energetische Hintergrundmusik, White Lavender OST wo passend
|
||||
- **Text-Overlays:** Bei Bugs und kritischen Punkten
|
||||
- **Balance:** Positive Aspekte zeigen, aber ehrlich bei Problemen sein
|
||||
- **Länge:** ~4:00-4:15 Minuten final
|
||||
8
Grafik/Kalki/White Lavender Review/Prod TODOs.md
Normal file
8
Grafik/Kalki/White Lavender Review/Prod TODOs.md
Normal file
|
|
@ -0,0 +1,8 @@
|
|||
# TODOs
|
||||
|
||||
- [x] Texte aufnehmen
|
||||
- [x] Soulslike Gameplay aufnehmen (Khazan, Elden Ring, Dark Souls)
|
||||
- [ ] Doku schreiben
|
||||
|
||||
|
||||
|
||||
22
Grafik/Kalki/White Lavender Review/Projektinformationen.md
Normal file
22
Grafik/Kalki/White Lavender Review/Projektinformationen.md
Normal file
|
|
@ -0,0 +1,22 @@
|
|||
# Projekt
|
||||
|
||||
#### Randbedingungen
|
||||
Partner: Domi
|
||||
Rahmen:
|
||||
- Medienkompetenz
|
||||
- Praktische Anwendungen
|
||||
- Praktisches Projekt
|
||||
|
||||
**Ideen**:
|
||||
1. Generell: Koop in Website Games Koop in Websites wie [Bruno Simon Portfolio](https://bruno-simon.com/)
|
||||
- 2D/3D Mario Website Game (1 Welt, paar Level)
|
||||
- Rythmusgame
|
||||
2. Animation zu:
|
||||
- Calisthenicsübung
|
||||
- Schmetterlingseffekt-Video
|
||||
3. **Reviews zu** **(Greenscreen + Cam + Mic, "very serious")**:
|
||||
- lustiges, dummes Spiel (z.B. White Lavender)
|
||||
- schäbiges Spiel
|
||||
- Tierlist zu irgendwas unnötigem
|
||||
- irgendwas im echten Leben (Calisthenics, Papier, Holzfeeling, Filme)
|
||||
|
||||
42
Grafik/White Lavender Review/Drehbuch(Projekt).md
Normal file
42
Grafik/White Lavender Review/Drehbuch(Projekt).md
Normal file
|
|
@ -0,0 +1,42 @@
|
|||
---
|
||||
share_link: https://share.note.sx/7nwowzi5#4yyPDdY8sVCpafWbQGK11IQo17686i7Qy9lQN8lPBiY
|
||||
share_updated: 2025-10-18T17:09:11+02:00
|
||||
---
|
||||
# Drehbuch
|
||||
Review zum Spiel "White Lavender"
|
||||
|
||||
### Anforderungen:
|
||||
###### 1. Was soll vermittelt werden:
|
||||
- Grundlagen und Struktur von Soulslikespielen in Action-RPGs
|
||||
- Bewertung der Inhalte des Spiels "White Lavender"
|
||||
- Bewertung der technischen Anforderungen des Spiels
|
||||
- Fazit zum Spiel und Empfehlung
|
||||
- Ziel: Comedyreview (Mischung aus ehrlicher Analyse und witzigen Elementen)
|
||||
###### 2. Zielgruppe:
|
||||
- Gamer, Streamer
|
||||
|
||||
### Styleguide/Design:
|
||||
- Einblendung der Reviewer im Stehen mit Mikrofon und Greenscreen im Video unten rechts oder andere Ecken je nach aktuellem Inhalt
|
||||
- Spiel im Full Screen
|
||||
- Gameplay im Hintergrund
|
||||
- Einblendung von Informationen in Textform zu gegebener Zeit
|
||||
### Technischer Entwurf:
|
||||
- Videoformat: mkv, mov
|
||||
- Editor: Davinci Resolve
|
||||
- Versionsverwaltung: NAS-Speicher
|
||||
|
||||
### Skript:
|
||||
|
||||
| Szenen-Nr. | Titel | Inhalte | Bild | Audio/Kommentar | Dauer |
|
||||
| ---------- | ---------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | --------------- | ----- |
|
||||
| 1 | Einführung ins Review | Story vorstellen | (Einblendung) Anfangsszene des Spiels zur Story vom Main Character und der kranken Schwester | | |
|
||||
| 2 | Erklärung des Genres: Soulslike | Theoretische Erklärung mit Inhalten was Soulslikes ausmacht | Zusammenschnitt mehrerer Ausschnitte aus Soulslikes wie Dark Souls, Elden Ring und weiteren Beispielen | | |
|
||||
| 3 | Grafikstil/Designbewertung | Super einzigartiger retroartiger Grafikstil, sehr bunt, CRT-Filter, lustiges Charakterdesign, Rüstung sichtbar am Charakter, Überleitung zu Movement mit goofy Füßeklebenbleiben | Gameplay mit Inhalten von lustigen Skins und Waffen, Heranzoomen an bestimmte Inhalte wie das Füßeklebenbleiben | | |
|
||||
| 4 | Spielabläufe: Movement | Movement des Spiels vorstellen | Movement und Fähigkeiten am Anfang des Spiels zeigen | | |
|
||||
| 5 | Spielabläufe: Combat gegen Enemies | Combat gegen normale Gegner im Detail bewerten | Kampfszenen gegen verschiedene Gegner | | |
|
||||
| 6 | Spielabläufe: Combat gegen Bosse | Bossdesign und Schwierigkeit des Spiels bewerten | Kampfszenen gegen verschieden Bosse | | |
|
||||
| 7 | Spielabläufe: Erkunden | Bewertung des Erlebnisses beim Erkunden des Spiels in der Open World | Traveling durch Portale (mal alle Gebiete zeigen), verschiedene Items auffindbar über die Map | | |
|
||||
| 8 | Spielabläufe: NPC Interaktion | NPC-Interaktionen bewerten und dessen Qualität/Tiefe, Questlines, Humorvoller Touch | Szenen beim Reden mit NPCs | | |
|
||||
| 9 | Musik | Kurze Erklärung was für Musik genutzt wird (Genre) und ob es zum Spielcharakter passt | ? | | |
|
||||
| 10 | Bugs | Aktuelle Probleme des Spiels und Fehler bei unserem Run | Spezifische Ausschnitte der Bugs, was genau falsch ist | | |
|
||||
| 11 | Fazit | Scoring System und Bewertung zusammenfassen übers Video | Hintergrund: Gameplay (unscharf) Vordergrund: Grafiken der vergebenen Scorings pro Videosektion | | |
|
||||
22
Grafik/White Lavender Review/Projektinformationen.md
Normal file
22
Grafik/White Lavender Review/Projektinformationen.md
Normal file
|
|
@ -0,0 +1,22 @@
|
|||
# Projekt
|
||||
|
||||
#### Randbedingungen
|
||||
Partner: Domi
|
||||
Rahmen:
|
||||
- Medienkompetenz
|
||||
- Praktische Anwendungen
|
||||
- Praktisches Projekt
|
||||
|
||||
**Ideen**:
|
||||
1. Generell: Koop in Website Games Koop in Websites wie [Bruno Simon Portfolio](https://bruno-simon.com/)
|
||||
- 2D/3D Mario Website Game (1 Welt, paar Level)
|
||||
- Rythmusgame
|
||||
2. Animation zu:
|
||||
- Calisthenicsübung
|
||||
- Schmetterlingseffekt-Video
|
||||
3. **Reviews zu** **(Greenscreen + Cam + Mic, "very serious", anschließendes Interview mit Alex)**:
|
||||
- lustiges, dummes Spiel (z.B. White Lavender)
|
||||
- schäbiges Spiel
|
||||
- Tierlist zu irgendwas unnötigem
|
||||
- irgendwas im echten Leben (Calisthenics, Papier, Holzfeeling, Filme)
|
||||
|
||||
Loading…
Add table
Add a link
Reference in a new issue