Repository navigation
Begriffe
Diese Seite erklärt die Vulkan- und Grafikbegriffe, die in der Terminalausgabe der Engine (Aufrufbeschreibungen, Begründungen, Pipeline-Block, Meldungen) und in sandbox.h vorkommen – der englische Begriff, wie er dort steht, mit einer deutschen Erklärung.
Quellen: [Spec] = Glossar der Vulkan-Spezifikation; [Spec, Pipelines] = Kapitel Pipelines der Spezifikation; [Guide] = Vulkan Guide (Khronos); [Samples] = Vulkan Samples, Dynamic Rendering; [Engine] = Dokumentation der Engine (docs/ARCHITECTURE.md, docs/BUILD.md, docs/REQUIREMENTS.md). Begriffe, für die nur die Engine spricht, tragen deren eigene Formulierung und keine weitere Definition.
| Begriff | Erklärung | Quelle |
|---|---|---|
| window, window surface / surface, drawing area | Das Fenster ist das Betriebssystemfenster (GLFW), in dem gerendert wird. Die Surface (VkSurfaceKHR) ist das plattformunabhängige Vulkan-Objekt dafür, das die übrige API für alle Fensteroperationen benutzt – in den Worten der Engine the drawing area of a window. |
[Guide] Surface; [Engine] ARCHITECTURE, The initialization chain |
| input callbacks | Die vier Rückruffunktionen, mit denen das Fenster Tastatur- und Mausereignisse an die Engine meldet; sie treiben die Kamerasteuerung. | [Engine] ARCHITECTURE, The initialization chain |
| Vulkan instance / instance | Das oberste Vulkan-Objekt: die Verbindung der Anwendung zur Vulkan-Implementierung (VkInstance). |
[Spec] Instance |
| extensions, window system | Erweiterungen sind optionale Teile der API, die beim Anlegen von Instanz oder Gerät angefordert werden; welche das Fenstersystem für Surface und Präsentation braucht, erfragt die Instanz von ihm. | [Spec] (extension ohne eigenen Glossareintrag); [Engine] Begründung von CreateInstance
|
| debug messenger | Der Empfänger, über den die Validation Layers ihre Meldungen an die Engine liefern; sie druckt sie als Validation layer: … – Warnungen und Fehler auf stderr. |
[Engine] BUILD, Expected console output in Debug |
| GPU, devices the instance lists | Ein physisches Gerät (VkPhysicalDevice) repräsentiert ein Gerät im System; die Instanz zählt sie auf, die Engine wählt eine GPU mit Vulkan 1.3 und dynamicRendering. |
[Spec] Physical Device; [Engine] ARCHITECTURE, KI 1 |
| logical device, queues | Das logische Gerät (VkDevice) ist die Schnittstelle der Anwendung zum physischen Gerät und Elternobjekt der meisten Vulkan-Objekte. Eine Queue (VkQueue) führt Command Buffers auf dem Gerät aus; Queues mit gleichen Eigenschaften bilden eine Queue-Familie. |
[Spec] Logical Device, Queue, Queue Family |
| memory pool | Gerätespeicher (VkDeviceMemory) ist Speicher, auf den das Gerät zugreift; der Memory Pool der Engine unterallokiert ihn für alle Buffer und Bilder. |
[Spec] Device Memory; [Engine] ARCHITECTURE, Ownership |
| swap chain, swap chain image(s), present | Die Swap Chain (VkSwapchainKHR) stellt über eine Reihe von Bildern (VkImage) die Fähigkeit bereit, Renderergebnisse auf einer Surface zu präsentieren; ein Bild daraus, das präsentiert wird, ist ein presentable image. Präsentieren heißt: das fertig gezeichnete Bild im Fenster zeigen. |
[Guide] Swapchain; [Spec] Presentable image |
| image views, image format | Ein Image View (VkImageView) ist ein Objekt auf einen Teilbereich eines Bildes mit der Angabe, wie dessen Inhalt zu interpretieren ist; das Format sagt, wie die Pixel gespeichert sind. |
[Spec] Image View |
| dynamic rendering, rendering set-up | Rendern ohne Render-Pass- und Framebuffer-Objekte: die Attachments werden beim Beginn des Renderns (vkCmdBeginRendering) direkt angegeben. Die Engine legt ihren Rendering-Aufbau – Attachment-Beschreibungen, Tiefenbild, Off-Screen-Farbbild – in InitializeRendering an. |
[Samples] Dynamic Rendering; [Engine] ARCHITECTURE, KI 2 |
| depth image, off-screen color image | Das Bild, in das die Tiefenwerte geschrieben werden, und das Farbbild, in das die undurchsichtige Szene gezeichnet wird, bevor der composite-Pass sie auf das Swap-Chain-Bild bringt. | [Engine] ARCHITECTURE, One frame |
| attachments, color and depth attachments, formats of the attachments | Die Bilder, in die ein Pass zeichnet: das Color Attachment ist das Ziel der Fragment-Farbausgaben und des Blendings, das Depth/Stencil Attachment das Ziel von Tiefentest und Tiefenschreibzugriffen. Eine Pipeline wird für die Formate ihrer Attachments gebaut. | [Spec] Color Attachment, Depth/Stencil Attachment |
| pipeline(s), the engine's pipelines, own pipeline, (pipeline) layout | Eine Pipeline (VkPipeline) steuert, wie Grafikarbeit auf dem Gerät ausgeführt wird: ein oder mehrere Shader plus der Zustand der nicht programmierbaren Stufen. Das Pipeline-Layout legt die Ressourcen (über Descriptor-Set-Layouts) und Push Constants fest, die Pipelines mit diesem Layout benutzen. "pbr" ist die Pipeline der Engine; eine eigene Pipeline teilt deren Layout. |
[Spec] Pipeline, Pipeline Layout; [Engine] ARCHITECTURE, Named pipelines |
| descriptor set layouts, descriptor pool, descriptor sets | Ein Descriptor beschreibt eine Ressource, damit ein Shader sie ansprechen kann; ein Descriptor Set ist das Objekt, in das Descriptoren geschrieben werden und das an einen Command Buffer gebunden wird; sein Layout legt Typen, Anzahl und Anordnung der Ressourcen fest; aus dem Descriptor Pool werden die Sets allokiert. | [Spec] Descriptor, Descriptor Set, Descriptor Set Layout, Descriptor Pool |
| light buffers | Der Storage Buffer an Binding 6, in den die Engine jeden Frame alle Lichter der Szene (LightData) schreibt. |
[Engine] ARCHITECTURE, What a mesh shader gets from the engine |
| command pool, command buffer(s), begin / end / recording, submit | Ein Command Buffer (VkCommandBuffer) zeichnet Befehle auf, die an eine Queue übergeben werden; der Command Pool ist der Speicher, aus dem Command Buffers allokiert werden. Aufzeichnen heißt Befehle zwischen begin und end in den Buffer schreiben; submit übergibt den fertigen Buffer der Queue zur Ausführung. |
[Spec] Command Buffer, Command Pool, Submission |
| default textures | Die gemeinsamen Ersatztexturen der Engine, mit denen ein Material ohne eigene (KTX2-)Textur gezeichnet wird – etwa die default albedo. | [Engine] REQUIREMENTS texture_pipeline; BUILD, Run
|
| semaphores and fences, synchronize | Eine Semaphore ist ein Synchronisationsobjekt mit Signal- und Warteoperationen innerhalb einer Queue oder zwischen Queues; eine Fence wird signalisiert, wenn übergebene Arbeit auf der Queue fertig ist, und kann vom Host (der CPU) abgewartet werden. | [Spec] Semaphore, Fence |
| worker threads, upload (textures) | Die Threads des Thread-Pools der Engine, die Texturen dekodieren und auf die GPU hochladen. | [Engine] ARCHITECTURE, Ownership |
| model loader, UI | Der Model Loader parst glTF-Dateien (tinygltf), Materialien, Lichter und Kameras; die UI ist das Bedienfeld der Engine (Dear ImGui) mit eigener Vulkan-Pipeline. | [Engine] ARCHITECTURE, Ownership |
| buffers and images on the GPU | Ein Buffer (VkBuffer) ist eine lineare Folge von Daten im Gerätespeicher; ein Image (VkImage) eine mehrdimensionale, formatierte Interpretation von Gerätespeicher. Meshes und Texturen der Szene liegen in solchen Objekten. |
[Spec] Buffer, Image |
| initialization chain, frame sequence | Die acht Aufrufe, mit denen main() die Engine aufsetzt, und die sechs Aufrufe eines Frames – die Begriffe der Engine für die beiden Reihenfolgen. |
[Engine] ARCHITECTURE, The initialization chain, The render loop |
| Begriff | Erklärung | Quelle |
|---|---|---|
| frame, frame slot, acquire | Ein Frame ist ein Durchlauf der sechs Aufrufe, der ein Bild präsentiert; die Engine hält zwei Frames gleichzeitig in Arbeit, jeder in einem eigenen Slot mit eigenem Command Buffer, Semaphoren und Fence. Acquire holt das nächste Swap-Chain-Bild, in das gezeichnet wird. | [Engine] ARCHITECTURE, One frame; REQUIREMENTS synchronisation_speicherverwaltung
|
| uniform buffers, scene data | Ein Uniform Buffer ist ein Descriptor-Typ für einen Buffer, den ein Shader nur liest; die Engine schreibt jeden Frame die Szenendaten (Matrizen, Kamera, Lichtanzahl) hinein. | [Spec] Uniform Buffer; [Engine] ARCHITECTURE, What a mesh shader gets from the engine |
| camera controls, terminal commands | Die Tastatur- und Maussteuerung der aktiven Kamera und die in das Terminal getippten Befehle Name.Move / Rotate / Scale; beide wirken in UpdateScene. |
[Engine] ARCHITECTURE, Terminal commands; REQUIREMENTS input_handling
|
| clear | Die Attachments zu Beginn des Renderns auf einen Startwert setzen: Farbe Schwarz (0, 0, 0, 1), Tiefe 1,0. | [Engine] ARCHITECTURE, KI 2 |
| draw, draw commands, bind | Zeichenbefehle sind die Befehle, die Arbeit mit einer Grafik-Pipeline auslösen; bind wählt davor die Pipeline, die Descriptor Sets und die Buffer, mit denen gezeichnet wird. | [Spec] Drawing Commands |
| rendering pass / pass | In der Engine ein beginRendering … endRendering-Paar im Command Buffer mit seinen Attachments; darin werden beliebig viele Objekte und Pipelines gezeichnet. |
[Engine] ARCHITECTURE, One frame |
| Begriff | Erklärung | Quelle |
|---|---|---|
| input assembly, triangle list | Die erste Stufe der Grafik-Pipeline setzt aus Vertices geometrische Primitive zusammen – Punkte, Linien, Dreiecke – nach der angeforderten Topologie; triangle list heißt: je drei Vertices ein Dreieck. | [Spec, Pipelines] Input Assembler |
| engine vertex layout | Die festen Vertex-Attribute der Engine: Position, Normale, UV, Tangente und je Instanz die Modell- und die Normalenmatrix ([[3 Phong-Modell im Shader | 3-Phong‐Modell-im-Shader]]). |
vertex shader, VSMain
|
Die Stufe, in der Vertices transformiert und ihre Positionen und Attribute berechnet werden; VSMain ist ihr Einstiegspunkt in jeder Shader-Datei der Engine. |
[Spec, Pipelines] Vertex Shader; [Engine] ARCHITECTURE, Named pipelines |
| rasterization | Der Rasterizer erzeugt aus der zweidimensionalen Beschreibung eines Punktes, einer Linie oder eines Dreiecks eine Folge von Fragmenten, die je einem Bereich des Framebuffers zugeordnet sind. | [Spec, Pipelines] Rasterization |
cull mode (none / front / back) |
Which side of a triangle a pipeline does not draw: keine, die Vorder- oder die Rückseite; Vorderseiten sind die gegen den Uhrzeigersinn aufgezählten. | [Engine] pipeline_settings.h; ARCHITECTURE, Named pipelines
|
fragment shader, PSMain
|
Die Stufe, die die Werte bestimmt, die in die Attachments geschrieben werden; PSMain ist ihr Einstiegspunkt. |
[Spec, Pipelines] Fragment Shader; [Engine] ARCHITECTURE, Named pipelines |
| depth test, writes depth / no depth writes | Eine Fragment-Operation, die entscheidet, ob erzeugte Werte in den Framebuffer geschrieben werden – hier der Vergleich der Fragmenttiefe mit dem Tiefenbild (LessOrEqual); writes depth heißt, dass die Tiefe des gezeichneten Fragments ins Tiefenbild geschrieben wird. |
[Spec, Pipelines] Fragment operations; [Engine] ARCHITECTURE, Named pipelines |
| color blending, transparent pass | Blending sind Rechenoperationen zwischen der Fragmentfarbe und dem Wert im Color Attachment, die die endgültige Farbe ergeben; die Engine blendet nur ihre eigene Pipeline "pbr" bei transparenten glTF-Materialien, im transparenten Pass direkt auf das Swap-Chain-Bild; eigene Pipelines zeichnen ohne Blending. |
[Spec] Blending; [Engine] ARCHITECTURE, Named pipelines |
.slang, .spv (SPIR-V) |
SPIR-V ist eine binäre Zwischendarstellung für Shader-Stufen; Shader werden in einer Hochsprache – hier Slang – geschrieben und zu SPIR-V übersetzt, das vkCreateShaderModule braucht. Der Build übersetzt x.slang zu x.spv. |
[Guide] What is SPIR-V; [Engine] BUILD, Commands |
| fixed / yours | Markierung im Pipeline-Block: yours an den vier Zeilen, die die Shader-Datei und die zwei Einstellungen einer eigenen Pipeline bestimmen, fixed an allem, was die Engine festlegt. |
[Engine] ARCHITECTURE, Terminal output |
| Begriff | Erklärung | Quelle |
|---|---|---|
| validation layer | Vulkan selbst prüft keine Fehler; die Validation Layers werden während der Entwicklung eingeschaltet, um ungültiges Verhalten zu erkennen, und nie mit einer Anwendung ausgeliefert. In der Engine nur in Debug-Builds aktiv. | [Guide] Khronos Validation Layer; [Engine] REQUIREMENTS validation_layer
|
| loading overlay | Die Anzeige der Engine, die die ersten Frames überdeckt, während Meshes und Texturen eines geladenen Modells hochgeladen werden. | [Engine] ARCHITECTURE, Absatz Scene loading |
| tone mapping, exposure | Der composite-Pass bringt die linearen Farben des Off-Screen-Bildes auf den Bildschirm: Belichtung (exposure, Standard 1,2) und ein filmisches Tone Mapping, das den Wertebereich auf den darstellbaren abbildet. | [Engine] ARCHITECTURE, Shaders (composite.slang) |
| glTF, KTX2 | glTF ist das Modellformat, das LoadModel() liest (.gltf / .glb, geparst mit tinygltf); KTX2 das einzige Texturformat, das die Engine dekodiert (libktx). |
[Engine] REQUIREMENTS texture_pipeline; BUILD, Run
|
| uniform buffer object (UBO), push constants, storage buffer (Shader-Seite) | UBO: der nur lesbare Buffer mit den Szenendaten (Binding 0). Push Constants: ein kleiner Satz Werte, den die Anwendung direkt setzt und der Shader liest, ohne Buffer oder Descriptor-Set-Änderung – hier die Materialfaktoren. Storage Buffer: ein Buffer, den der Shader lesen und schreiben kann – hier die Lichter (Binding 6). | [Spec] Uniform Buffer, Push Constants, Storage Buffer |
Quellen im Netz: Vulkan-Spezifikation, Glossar; Vulkan-Spezifikation, Kapitel Pipelines; Vulkan Guide, WSI; Vulkan Guide, Validation; Vulkan Guide, What is SPIR-V; Vulkan Samples, Dynamic Rendering. Engine-Dokumentation: docs/ARCHITECTURE.md, docs/BUILD.md, docs/REQUIREMENTS.md.