Experimental vulkan render engine The goal is to create a flexible render engine that
- supports multiple windows
- place for making experimental render code.
Library uses
- volk for vulkan loading
- imgui as debug UI.
- glm as math library
- ADR templates for documentation of design decisions
- sdl for window handling
- CT image source: https://isbweb.org/data/vsj/ (Thank you)
- exported to image with: https://www.radiantviewer.com/
A render engine is not only for games. Many scientific code uses rendering and compute. Sometimes the only goal is debugging some algorithm. For this purpose multiple window support is essential.
This render API supports this need. Imgui is integrated in a way that it supports multiple context. With different renderer definition one can visualize different things on different windows.
This feature sounds easy but not. The most problematic things are with using elegantly the volk function table and how to integrate this with ImGui. See more in Logical Device ADR
Sometimes it is not just about showing the result but saving it or forwarding it to other application. For this purpose this API supports headless rendering. Later on this can be used also to visualize it.
In this way one can distribute the load between a powerfull GPU and a less effective one (like an integrated). I.e.: Rendering and compute on the powerfull machine and then saving the image and visualizing it with an integrated GPU
Open TODOs:
- Proper multi queue support
- Parallel rendering support
Volume renderer is added to the API. Mostly for experimental reasons. Like computing AO. It is also a nice test of how to integrate Cuda compute inside rendering process. And using subpassload to achive better performance for ray marching. See more details in the Design decision section.
A simple volume rendering without AO
Volume renderer is added to the API. Mostly for experimental reasons. Like computing AO. It is also a nice test of how to integrate Cuda compute inside rendering process. And using subpassload to achive better performance for ray marching. See more details in the Design decision section.
A simple volume rendering without AO
There are some major design decision what was made during the library creation. Some of those are experimental decisions to figure out its consecvencies.
See
- Resource State Machine
- Off-Screen Rendering
- Volume Rendering
- Distance Field Calculation and Compute
- Volume Rendering with Ambient Occlusion
- Synchronization with fences,semaphores
- Multiple Queue Family Support
- DescriptorSetLayout Setup
- Command Context
- Multiple Device Support - Having a Logical Device
- Error handling
- Object initialization
- Objects responsibility
- Singletons
- Resource Uploader
Ongoing TODOs: