-
Notifications
You must be signed in to change notification settings - Fork 2
renderer structure
The rendering system is all contained within the workshop.renderer project. You may notice it is stored in tier1, this is intentional, its entirely isolated and self-contained, it has no knowledge of higher level engine functionality.
The renderer is designed to be capable of being run entirely independently on its own thread without any data syncronization with the game/engine code. This allows it to not have to worry about any data conflicts.
The renderer is create and owned by the engine class, and can be retrieved with a call to engine::get_renderer().
The only way the game communicates with the renderer is through the render_command_queue which can be retrieved by calling renderer::get_command_queue. As the name suggests this command queue allows the game to enqueue a set of fixed commands - things like creating static meshes, destroying static meshes, changing their world location, etc. Each time the renderer is stepped by the engine, the commands in this queue are passed off to the background render job which processes them, updates its view of the world and renders a frame.
This is the only communication the game has with the background render job, it is essentially write-only, state cannot be read back from it. See render_command_queue for a full list of commands the game can use to modify the render state.
The renderer has a large number of render_system_* classes registered to it (registration is done in renderer::create_systems).
These systems define high-level sections of the frame - things like drawing lighting/shadows/geometry/transparency/etc.
Eachs system is responsible for creating the resources it needs to perform its job. Its also responsible for building the render_graph. Each fram render_system::build_graph is called for each system, for each render view (in parallel). During this function is responsible for adding all neccessary render_pass's to the graph to render the intended result.
There are a large number of render_pass classes, these are registered to the render_graph by the systems. These passes respresent small reusable functionality that describes how to generate command lists to pass to the gpu to render something. There are passes for clearing buffers, calculating mipmaps, rendering meshes, etc.
Once all passes are registered the renderer will go through all passes in the render_graph and will in parallel call render_pass::generate.
Within this generate class render_pass will create all the command lists it needs to perform its function and return them to the renderer.
After all passes have been processed the command lists generated are dispatched to the gpu.
Introduction
Standards
Architecture
- Code Structure
- Build Configurations
- Engine Structure
- Virtual File System
- Entity Component System
- Renderer
- Assets
Helpful Notes