![]() |
VPP
0.8
A high-level modern C++ API for Vulkan
|
Defines a vector of physical images to be used as targets for rendering attachments. More...
#include <vppFramebuffer.hpp>
Public Member Functions | |
FrameBuffer () | |
Constructs null reference. | |
FrameBuffer (const std::vector< FrameImageView > &imageViews, const RenderPass &hRenderPass) | |
Constructs a frame buffer from specified image vector. More... | |
FrameBuffer (const RenderPass &hRenderPass) | |
Constructs a frame buffer assuming all views are fixed and specified during the construction of attachment objects. | |
VkFramebuffer | handle () const |
Retrieves the Vulkan handle. | |
VkRect2D | area () const |
Retrieves the size of the frame. | |
FrameImageView | imageView (size_t index) const |
Retrieves the view reference for specified image index. | |
size_t | imageViewCount () const |
Retrieves the count of images. | |
Defines a vector of physical images to be used as targets for rendering attachments.
The framebuffer is associated with given RenderPass object and, by extension, with the render graph. Each item in the vector corresponds to single attachment node defined inside the render graph, in exactly same order as they are listed in the subclass definition (including both Attachment and Display nodes).
An item slot may however point to null view, that means a default-constructed FrameImageView object. In such case, VPP will try to use fixed view specified in the constructor of the corresponding node. There should be either view valid (or both), it is an error when there is a null view in the vector and no fixed view in the node simultaneously.
If specified non-null view (valid FrameImageView), this view will override any fixed view set for corresponding node during its construction.
If all views are fixed, you can avoid using FrameBuffer class completely. This is done by means of RenderManager class that manages FrameBuffer instances internally.
If the only non-fixed views are Display nodes (which implicitly use swapped images from a swapchain), you should also use RenderManager because RenderManager handles swapchains.
Use the FrameBuffer when you need to render into off-screen image targets that change. That also enforces using CommandBufferRecorder class to control rendering. Simpler RenderManager class does not support specifying explicit FrameBuffer. In such case, you must do several lower level things manually, that otherwise would be done by RenderManager:
FrameBuffer accepts view references in untyped form (FrameImageView). You can obtain a FrameImageView from each typed ImageView< ... > instance by calling its frameView()
method.
This object is reference-counted and may be passed by value.
vpp::FrameBuffer::FrameBuffer | ( | const std::vector< FrameImageView > & | imageViews, |
const RenderPass & | hRenderPass | ||
) |
Constructs a frame buffer from specified image vector.
This constructor also handles the null views present inside the vector (if any). They will be replaced by fixed views retrieved from the nodes of the render graph (accessed via render pass).