PySide6.QtGui.QRhiTextureRenderTarget¶

class QRhiTextureRenderTarget¶

Texture render target resource.

Details

A texture render target allows rendering into one or more textures, optionally with a depth texture or depth/stencil renderbuffer.

For multisample rendering the common approach is to use a renderbuffer as the color attachment and set the non-multisample destination texture as the resolve texture. For more information, read the detailed description of the QRhiColorAttachment class.

Note

Textures used in combination with QRhiTextureRenderTarget must be created with the RenderTarget flag.

The simplest example of creating a render target with a texture as its single color attachment:

QRhiTexture *texture = rhi->newTexture(QRhiTexture::RGBA8, size, 1, QRhiTexture::RenderTarget);
texture->create();
QRhiTextureRenderTarget *rt = rhi->newTextureRenderTarget({ texture });
rp = rt->newCompatibleRenderPassDescriptor();
rt->setRenderPassDescriptor(rp);
rt->create();
// rt can now be used with beginPass()

Note

This is a RHI API with limited compatibility guarantees, see QRhi for details.

Added in version 6.6.

Synopsis¶

Virtual methods¶

def create()
def newCompatibleRenderPassDescriptor()

Note

This documentation may contain snippets that were automatically translated from C++ to Python. We always welcome contributions to the snippet translation. If you see an issue with the translation, you can also let us know by creating a ticket on https:/bugreports.qt.io/projects/PYSIDE

class Flag¶

(inherits enum.Flag) Flag values describing the load/store behavior for the render target. The load/store behavior may be baked into native resources under the hood, depending on the backend, and therefore it needs to be known upfront and cannot be changed without rebuilding (and so releasing and creating new native resources).

Constant

Description

QRhiTextureRenderTarget.Flag.PreserveColorContents

Indicates that the contents of the color attachments is to be loaded when starting a render pass, instead of clearing. This is potentially more expensive, especially on mobile (tiled) GPUs, but allows preserving the existing contents between passes. When doing multisample rendering with a resolve texture set, setting this flag also requests the multisample color data to be stored (written out) to the multisample texture or render buffer. (for non-multisample rendering the color data is always stored, but for MSAA storing the multisample data decreases efficiency for certain GPU architectures, hence defaulting to not writing it out) Note however that this is non-portable: in some cases there is no intermediate multisample texture on the graphics API level, e.g. when using OpenGL ES’s GL_EXT_multisampled_render_to_texture as it is all implicit, handled by the OpenGL ES implementation. In that case, PreserveColorContents will likely have no effect. Therefore, avoid relying on this flag when using multisample rendering and the color attachment is using a multisample QRhiTexture (not QRhiRenderBuffer ).

QRhiTextureRenderTarget.Flag.PreserveDepthStencilContents

Indicates that the contents of the depth texture is to be loaded when starting a render pass, instead clearing. Only applicable when a texture is used as the depth buffer ( depthTexture() is set) because depth/stencil renderbuffers may not have any physical backing and data may not be written out in the first place.

QRhiTextureRenderTarget.Flag.DoNotStoreDepthStencilContents

Indicates that the contents of the depth texture does not need to be written out. Relevant only when a QRhiTexture , not QRhiRenderBuffer , is used as the depth-stencil buffer, because for QRhiRenderBuffer this is implicit. When a depthResolveTexture is set, the flag is not relevant, because the behavior is then as if the flag was set. This enum value is introduced in Qt 6.8.

Constant	Description
QRhiTextureRenderTarget.Flag.PreserveColorContents	Indicates that the contents of the color attachments is to be loaded when starting a render pass, instead of clearing. This is potentially more expensive, especially on mobile (tiled) GPUs, but allows preserving the existing contents between passes. When doing multisample rendering with a resolve texture set, setting this flag also requests the multisample color data to be stored (written out) to the multisample texture or render buffer. (for non-multisample rendering the color data is always stored, but for MSAA storing the multisample data decreases efficiency for certain GPU architectures, hence defaulting to not writing it out) Note however that this is non-portable: in some cases there is no intermediate multisample texture on the graphics API level, e.g. when using OpenGL ES’s `GL_EXT_multisampled_render_to_texture` as it is all implicit, handled by the OpenGL ES implementation. In that case, PreserveColorContents will likely have no effect. Therefore, avoid relying on this flag when using multisample rendering and the color attachment is using a multisample `QRhiTexture` (not `QRhiRenderBuffer` ).
QRhiTextureRenderTarget.Flag.PreserveDepthStencilContents	Indicates that the contents of the depth texture is to be loaded when starting a render pass, instead clearing. Only applicable when a texture is used as the depth buffer ( `depthTexture()` is set) because depth/stencil renderbuffers may not have any physical backing and data may not be written out in the first place.
QRhiTextureRenderTarget.Flag.DoNotStoreDepthStencilContents	Indicates that the contents of the depth texture does not need to be written out. Relevant only when a `QRhiTexture` , not `QRhiRenderBuffer` , is used as the depth-stencil buffer, because for `QRhiRenderBuffer` this is implicit. When a depthResolveTexture is set, the flag is not relevant, because the behavior is then as if the flag was set. This enum value is introduced in Qt 6.8.

PySide6.QtGui.QRhiTextureRenderTarget.m_desc¶

PySide6.QtGui.QRhiTextureRenderTarget.m_flags¶

abstract create()¶

Return type:: bool

Creates the corresponding native graphics resources. If there are already resources present due to an earlier create() with no corresponding destroy() , then destroy() is called implicitly first.

Note

renderPassDescriptor() must be set before calling create(). To obtain a QRhiRenderPassDescriptor compatible with the render target, call newCompatibleRenderPassDescriptor() before create() but after setting all other parameters, such as description() and flags() . To save resources, reuse the same QRhiRenderPassDescriptor with multiple QRhiTextureRenderTarget instances, whenever possible. Sharing the same render pass descriptor is only possible when the render targets have the same number and type of attachments (the actual textures can differ) and the same flags.

Note

resources, such as QRhiTexture instances, referenced in description() must already have create() called on them.

Returns true when successful, false when a graphics operation failed. Regardless of the return value, calling destroy() is always safe.

description()¶

Return type:: QRhiTextureRenderTargetDescription

Returns the render target description.

See also

setDescription()

flags()¶

Return type:: Combination of Flag

Returns the currently set flags.

See also

setFlags()

abstract newCompatibleRenderPassDescriptor()¶

Return type:: QRhiRenderPassDescriptor

Returns a new QRhiRenderPassDescriptor that is compatible with this render target.

The returned value is used in two ways: it can be passed to setRenderPassDescriptor() and setRenderPassDescriptor() . A render pass descriptor describes the attachments (color, depth/stencil) and the load/store behavior that can be affected by flags() . A QRhiGraphicsPipeline can only be used in combination with a render target that has a compatible QRhiRenderPassDescriptor set.

Two QRhiTextureRenderTarget instances can share the same render pass descriptor as long as they have the same number and type of attachments. The associated QRhiTexture or QRhiRenderBuffer instances are not part of the render pass descriptor so those can differ in the two QRhiTextureRenderTarget instances.

Note

resources, such as QRhiTexture instances, referenced in description() must already have create() called on them.