/usr/share/qt5/doc/qt3drenderer/qt3drenderer-framegraph.html is in qt3d5-doc-html 5.5.1-4ubuntu3.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 | <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<!-- qt3drenderer-framegraph.qdoc -->
<title>Qt3D Renderer Framegraph | Qt3D Module 5.5</title>
<link rel="stylesheet" type="text/css" href="style/offline.css" />
</head>
<body>
<div class="header" id="qtdocheader">
<div class="main">
<div class="main-rounded">
<div class="navigationbar">
<ul>
<li>Qt 5.5</li>
<li>Qt3D Module</li>
<li>Qt3D Renderer Framegraph</li>
<li id="buildversion">Qt 5.5.1 Reference Documentation</li>
</ul>
</div>
</div>
<div class="content">
<div class="line">
<div class="content mainContent">
<div class="sidebar">
<div class="toc">
<h3><a name="toc">Contents</a></h3>
<ul>
<li class="level1"><a href="#framegraph-rules">FrameGraph Rules</a></li>
<li class="level2"><a href="#setting-the-framegraph">Setting the Framegraph</a></li>
<li class="level2"><a href="#how-the-framegraph-is-used">How the Framegraph Is Used</a></li>
<li class="level1"><a href="#framegraph-examples">Framegraph Examples</a></li>
<li class="level2"><a href="#a-simple-forward-renderer">A Simple Forward Renderer</a></li>
<li class="level2"><a href="#a-multi-viewport-framegraph">A Multi Viewport FrameGraph</a></li>
<li class="level2"><a href="#deferred-renderer">Deferred Renderer</a></li>
<li class="level1"><a href="#other-benefits-of-the-framegraph">Other Benefits of the framegraph</a></li>
<li class="level1"><a href="#conclusion">Conclusion</a></li>
</ul>
</div>
<div class="sidebar-content" id="sidebar-content"></div></div>
<h1 class="title">Qt3D Renderer Framegraph</h1>
<span class="subtitle"></span>
<!-- $$$qt3drenderer-framegraph.html-description -->
<div class="descr"> <a name="details"></a>
<p>The Qt3D Renderer aspect allows for the rendering algorithm to be entirely data-driven. The controlling data structure is known as the <i>framegraph</i>. Similar to how the Qt3D ECS (entity component system) allows you to define a so-called Scenegraph by building a scene from a tree of Entities and Components, the framegraph is also a tree structure but one used for a different purpose. Namely, controlling <i>how</i> the scene is rendered.</p>
<p>Over the course of rendering a single frame, a 3D renderer will likely change state many times. The number and nature of these state changes depends upon not only which materials (shaders, mesh geometry, textures and uniform variables) are found within the scene, but also upon which high level rendering scheme you are using.</p>
<p>For example, using a traditional simple <i>forward rendering</i> scheme is very different to using a <i>deferred rendering</i> approach. Other features such as reflections, shadows, multiple viewports, and early z-fill passes all change which states a renderer needs to set over the course of a frame and when those state changes need to occur.</p>
<p>As a comparison, the Qt Quick 2 scenegraph renderer responsible for drawing Qt Quick 2 scenes is hard-wired in C++ to do things like batching of primitives and rendering opaque items followed by rendering of transparent items. In the case of Qt Quick 2 that is perfectly fine as that covers all of the requirements. As you can see from some of the examples listed above, such a hard-wired renderer is not likely to be flexible enough for generic 3D scenes given the multitude of rendering methods available. Or if a renderer could be made flexible enough to cover all such cases, its performance would likely suffer from being too general. To make matters worse, more rendering methods are being researched all of the time. We therefore needed an approach that is <i>both flexible and extensible</i> whilst being simple to use and maintain. Enter the framegraph!</p>
<p>Each node in the framegraph defines a part of the configuration the renderer will use to render the scene. The position of a node in the framegraph tree determines when and where the subtree rooted at that node will be the active configuration in the rendering pipeline. As we will see later, the renderer traverses this tree in order to build up the state needed for your rendering algorithm at each point in the frame.</p>
<p>Obviously if you just want to render a simple cube onscreen you may think this is overkill. However, as soon as you want to start doing slightly more complex scenes this comes in handy. For the common cases, Qt3D provides some example framegraphs that are ready to use out of the box.</p>
<p>We will demonstrate the flexibility of the framegraph concept by presenting a few examples and the resulting framegraphs.</p>
<p>Please note that unlike the Scenegraph which is composed of Entities and Components, the framegraph is only composed of nested nodes which are all subclasses of <a href="qt3d-qframegraphnode.html">Qt3D::QFrameGraphNode</a>. This is because the framegraph nodes are not simulated objects in our virtual world, but rather supporting information.</p>
<p>We will soon see how to construct our first simple framegraph but before that we will introduce the framegraph nodes available to you. Also as with the Scenegraph tree, the QML and C++ APIs are a 1 to 1 match so you can favor the one you like best. For the sake of readability and conciseness, the QML API was chosen for this article.</p>
<p>// TODO: Add list of framegraph node types</p>
<p>The beauty of the framegraph is that combining these simple node types, it is possible to configure the renderer to suit your specific needs without touching any hairy, low-level C/C++ rendering code at all.</p>
<a name="framegraph-rules"></a>
<h2 id="framegraph-rules">FrameGraph Rules</h2>
<p>In order to construct a correctly functioning framegraph tree, you should know a few rules about how it is traversed and how to feed it to the Qt3D renderer.</p>
<a name="setting-the-framegraph"></a>
<h3 >Setting the Framegraph</h3>
<p>The <a href="qml-qt3d-renderer-framegraph.html">FrameGraph</a> tree should be assigned to the activeFrameGraph property of a QFrameGraph component, itself being a component of the root entity in the Qt3D scene. This is what makes it the active framegraph for the renderer. Of course, since this is a QML property binding, the active framegraph (or parts of it) can be changed on the fly at runtime. For example, if you want to use different rendering approaches for indoor and outdoor scenes or to enable or disable some special effect.</p>
<pre class="cpp">Entity {
id: sceneRoot
components: FrameGraph {
activeFrameGraph: ... // FrameGraph tree
}
}</pre>
<p><b>Note: </b>activeFrameGraph is the default property of the <a href="qml-qt3d-renderer-framegraph.html">FrameGraph</a> component in QML.</p><pre class="cpp">Entity {
id: sceneRoot
components: FrameGraph {
... // FrameGraph tree
}
}</pre>
<a name="how-the-framegraph-is-used"></a>
<h3 >How the Framegraph Is Used</h3>
<ul>
<li>The Qt3D renderer performs a <i>depth first traversal</i> of the framegraph tree. Note that, because the traversal is depth first, the <i>order in which you define nodes is important</i>.</li>
<li>When the renderer reaches a leaf node of the framegraph, it collects together all of the state specified by the path from the leaf node to the root node. This defines the state used to render a section of the frame. If you are interested in the internals of Qt3D, this collection of state is called a <i>RenderView</i>.</li>
<li>Given the configuration contained in a RenderView, the renderer collects together all of the Entities in the Scenegraph to be rendered, and from them builds a set of <i>RenderCommands</i> and associates them with the RenderView.</li>
<li>The combination of RenderView and set of RenderCommands is passed over for submission to OpenGL.</li>
<li>When this is repeated for each leaf node in the framegraph, the frame is complete and the renderer calls QOpenGLContext::swapBuffers() to display the frame.</li>
</ul>
<p>At its heart, the framegraph is a data-driven method for configuring the Qt3D renderer. Due to its data-driven nature, we can change configuration at runtime, allow non-C++ developers or designers to change the structure of a frame, and try out new rendering approaches without having to write thousands of lines of boiler plate code.</p>
<a name="framegraph-examples"></a>
<h2 id="framegraph-examples">Framegraph Examples</h2>
<p>Now that you know the rules to abide by when writing a framegraph tree, we will go over a few examples and break them down.</p>
<a name="a-simple-forward-renderer"></a>
<h3 >A Simple Forward Renderer</h3>
<p>Forward rendering is when you use OpenGL in its traditional manner and render directly to the backbuffer one object at a time shading each one as we go. This is opposed to <a href="qt3drenderer-framegraph.html#deferred-renderer">deferred rendering</a> where we render to an intermediate <i>G-buffer</i>. Here is a simple <a href="qml-qt3d-renderer-framegraph.html">FrameGraph</a> that can be used for forward rendering:</p>
<pre class="cpp">Viewport {
rect: Qt.rect(0.0, 0.0, 1.0, 1.0)
property alias camera: cameraSelector.camera
ClearBuffer {
buffers: ClearBuffer.ColorDepthBuffer
CameraSelector {
id: cameraSelector
}
}
}</pre>
<p>As you can see, this tree has a single leaf and is composed of 3 nodes in total as shown in the following diagram.</p>
<p class="centerAlign"><img src="images/simple-framegraph.png" alt="" /></p><p>Using the rules defined <a href="qt3drenderer-framegraph.html#framegraph-rules">above</a>, this framegraph tree yields a single RenderView with the following configuration:</p>
<ul>
<li>Leaf Node -> RenderView<ul>
<li>Viewport that fills the entire screen (uses normalized coordinates to make it easy to support nested viewports)</li>
<li>Color and Depth buffers are set to be cleared</li>
<li>Camera specified in the exposed camera property</li>
</ul>
</li>
</ul>
<p>Several different <a href="qml-qt3d-renderer-framegraph.html">FrameGraph</a> trees can produce the same rendering result. As long as the state collected from leaf to root is the same, the result will also be the same. It is best to put state that remains constant longest nearer to the root of the framegraph as this will result in fewer leaf nodes, and hence, fewer RenderViews overall.</p>
<pre class="cpp">Viewport {
rect: Qt.rect(0.0, 0.0, 1.0, 1.0)
property alias camera: cameraSelector.camera
CameraSelector {
id: cameraSelector
ClearBuffer {
buffers: ClearBuffer.ColorDepthBuffer
}
}
}</pre>
<pre class="cpp">CameraSelector {
Viewport {
rect: Qt.rect(0.0, 0.0, 1.0, 1.0)
ClearBuffer {
buffers: ClearBuffer.ColorDepthBuffer
}
}
}</pre>
<a name="a-multi-viewport-framegraph"></a>
<h3 >A Multi Viewport FrameGraph</h3>
<p>Let us move on to a slightly more complex example that renders a Scenegraph from the point of view of 4 virtual cameras into the 4 quadrants of the window. This is a common configuration for 3D CAD or modelling tools or could be adjusted to help with rendering a rear-view mirror in a car racing game or a CCTV camera display.</p>
<p class="centerAlign"><img src="images/multiviewport.png" alt="" /></p><pre class="cpp">Viewport {
id: mainViewport
rect: Qt.rect(0, 0, 1, 1)
property alias Camera: cameraSelectorTopLeftViewport.camera
property alias Camera: cameraSelectorTopRightViewport.camera
property alias Camera: cameraSelectorBottomLeftViewport.camera
property alias Camera: cameraSelectorBottomRightViewport.camera
ClearBuffer {
buffers: ClearBuffer.ColorDepthBuffer
}
Viewport {
id: topLeftViewport
rect: Qt.rect(0, 0, 0.5, 0.5)
CameraSelector { id: cameraSelectorTopLeftViewport }
}
Viewport {
id: topRightViewport
rect: Qt.rect(0.5, 0, 0.5, 0.5)
CameraSelector { id: cameraSelectorTopRightViewport }
}
Viewport {
id: bottomLeftViewport
rect: Qt.rect(0, 0.5, 0.5, 0.5)
CameraSelector { id: cameraSelectorBottomLeftViewport }
}
Viewport {
id: bottomRightViewport
rect: Qt.rect(0.5, 0.5, 0.5, 0.5)
CameraSelector { id: cameraSelectorBottomRightViewport }
}
}</pre>
<p>This tree is a bit more complex with 5 leaves. Following the same rules as before we construct 5 RenderView objects from the <a href="qml-qt3d-renderer-framegraph.html">FrameGraph</a>. The following diagrams show the construction for the first two RenderViews. The remaining RenderViews are very similar to the second diagram just with the other sub-trees.</p>
<p class="centerAlign"><img src="images/multiviewport-1.png" alt="" /></p><p class="centerAlign"><img src="images/multiviewport-2.png" alt="" /></p><p>In full, the RenderViews created are:</p>
<ul>
<li>RenderView (1)<ul>
<li>Fullscreen viewport defined</li>
<li>Color and Depth buffers are set to be cleared</li>
</ul>
</li>
<li>RenderView (2)<ul>
<li>Fullscreen viewport defined</li>
<li>Sub viewport defined (rendering viewport will be scaled relative to its parent)</li>
<li>CameraSelector specified</li>
</ul>
</li>
<li>RenderView (3)<ul>
<li>Fullscreen viewport defined</li>
<li>Sub viewport defined (rendering viewport will be scaled relative to its parent)</li>
<li>CameraSelector specified</li>
</ul>
</li>
<li>RenderView (4)<ul>
<li>Fullscreen viewport defined</li>
<li>Sub viewport defined (rendering viewport will be scaled relative to its parent)</li>
<li>CameraSelector specified</li>
</ul>
</li>
<li>RenderView (5)<ul>
<li>Fullscreen viewport defined</li>
<li>Sub viewport defined (rendering viewport will be scaled relative to its parent)</li>
<li>CameraSelector specified</li>
</ul>
</li>
</ul>
<p>However, in this case the <i>order is important</i>. If the ClearBuffer node were to be the last instead of the first, this would result in a black screen for the simple reason that everything would be cleared right after having been so carefully rendered. For a similar reason, it could not be used as the root of the <a href="qml-qt3d-renderer-framegraph.html">FrameGraph</a> as that would result in a call to clear the whole screen for each of our viewports.</p>
<p>Although the declaration order of the <a href="qml-qt3d-renderer-framegraph.html">FrameGraph</a> is important, Qt3D is able to process each RenderView in parallel as each RenderView is independent of the others for the purposes of generating a set of RenderCommands to be submitted whilst the RenderView's state is in effect.</p>
<p>Qt3D uses a task-based approach to parallelism which naturally scales up with the number of available cores. This is shown in the following diagram for the previous example.</p>
<p class="centerAlign"><img src="images/framegraph-parallel-build.png" alt="" /></p><p>The RenderCommands for the RenderViews can be generated in parallel across many cores, and as long as we take care to submit the RenderViews in the correct order on the dedicated OpenGL submission thread, the resulting scene will be rendered correctly.</p>
<a name="deferred-renderer"></a>
<h3 >Deferred Renderer</h3>
<p>When it comes to rendering, deferred rendering is a different beast in terms of renderer configuration compared to forward rendering. Instead of drawing each mesh and applying a shader effect to shade it, deferred rendering adopts a <i>two render pass</i> method.</p>
<p>First all the meshes in the scene are drawn using the same shader that will output, usually for each fragment, at least four values:</p>
<ul>
<li>World normal vector</li>
<li>Color (or some other material properties)</li>
<li>Depth</li>
<li>World position vector</li>
</ul>
<p>Each of these values will be stored in a texture. The normal, color, depth, and position textures form what is called the G-Buffer. Nothing is drawn onscreen during the first pass, but rather drawn into the G-Buffer ready for later use.</p>
<p>Once all the meshes have been drawn, the G-Buffer is filled with all the meshes that can currently be seen by the camera. The second render pass is then used to render the scene to the back buffer with the final color shading by reading the normal, color, and position values from the G-buffer textures and outputting a color onto a full screen quad.</p>
<p>The advantage of that technique is that the heavy computing power required for complex effects is only used during the second pass only on the elements that are actually being seen by the camera. The first pass does not cost much processing power as every mesh is being drawn with a simple shader. Deferred rendering, therefore, decouples shading and lighting from the number of objects in a scene and instead couples it to the resolution of the screen (and G-Buffer). This is a technique that has been used in many games due to the ability to use large numbers of dynamic lights at the expense of additional GPU memory usage.</p>
<pre class="cpp">Viewport {
rect: Qt.rect(0.0, 0.0, 1.0, 1.0)
property alias gBuffer: gBufferTargetSelector.target
property alias camera: sceneCameraSelector.camera
LayerFilter {
layers: "scene"
RenderTargetSelector {
id: gBufferTargetSelector
ClearBuffer {
buffers: ClearBuffer.ColorDepthBuffer
RenderPassFilter {
id: geometryPass
includes: Annotation { name: "pass"; value: "geometry" }
CameraSelector {
id: sceneCameraSelector
}
}
}
}
}
LayerFilter {
layers: "screenQuad"
ClearBuffer {
buffers: ClearBuffer.ColorDepthBuffer
RenderPassFilter {
id: finalPass
includes: Annotation { name: "pass"; value: "final" }
}
}
}
}</pre>
<p>Graphically, the resulting framegraph looks like:</p>
<p class="centerAlign"><img src="images/deferred-framegraph.png" alt="" /></p><p>And the resulting RenderViews are:</p>
<ul>
<li>RenderView (1)<ul>
<li>Define a viewport that fills the whole screen</li>
<li>Select all Entities that have a Layer component matching <code>"scene"</code></li>
<li>Set the <code>gBuffer</code> as the active render target</li>
<li>Clear the color and depth on the currently bound render target (the <code>gBuffer</code>)</li>
<li>Select only Entities in the scene that have a Material and Technique matching the annotations in the RenderPassFilter</li>
<li>Specify which camera should be used</li>
</ul>
</li>
<li>RenderView (2)<ul>
<li>Define a viewport that fills the whole screen</li>
<li>Select all Entities that have a Layer component matching <code>"screenQuad"</code></li>
<li>Clear the color and depth buffers on the currently bound framebuffer (the screen)</li>
<li>Select only Entities in the scene that have a Material and Technique matching the annotations in the RenderPassFilter</li>
</ul>
</li>
</ul>
<a name="other-benefits-of-the-framegraph"></a>
<h2 id="other-benefits-of-the-framegraph">Other Benefits of the framegraph</h2>
<p>Since the <a href="qml-qt3d-renderer-framegraph.html">FrameGraph</a> tree is entirely data-driven and can be modified dynamically at runtime, you can:</p>
<ul>
<li>Have different framegraph trees for different platforms and hardware and select the most appropriate at runtime</li>
<li>Easily add and enable visual debugging in a scene</li>
<li>Use different <a href="qml-qt3d-renderer-framegraph.html">FrameGraph</a> trees depending on the nature of what you need to render for a particular region of the scene</li>
<li>Implement a new rendering technique without having to modify Qt3D's internals</li>
</ul>
<a name="conclusion"></a>
<h2 id="conclusion">Conclusion</h2>
<p>We have introduced the <a href="qml-qt3d-renderer-framegraph.html">FrameGraph</a> and the node types that compose it. We then went on to discuss a few examples to illustrate the framegraph building rules and how the Qt3D engine uses the framegraph behind the scenes. By now you should have a pretty good overview of the <a href="qml-qt3d-renderer-framegraph.html">FrameGraph</a> and how it can be used (perhaps to add an <a href="http://en.wikipedia.org/wiki/Z-buffering">early z-fill pass</a> to a forward renderer). Also you should always keep in mind that the <a href="qml-qt3d-renderer-framegraph.html">FrameGraph</a> is a tool for you to use so that you are not tied down to the provided renderer and materials that Qt3D provides out of the box.</p>
</div>
<!-- @@@qt3drenderer-framegraph.html -->
</div>
</div>
</div>
</div>
</div>
<div class="footer">
<p>
<acronym title="Copyright">©</acronym> 2015 The Qt Company Ltd.
Documentation contributions included herein are the copyrights of
their respective owners.<br> The documentation provided herein is licensed under the terms of the <a href="http://www.gnu.org/licenses/fdl.html">GNU Free Documentation License version 1.3</a> as published by the Free Software Foundation.<br> Qt and respective logos are trademarks of The Qt Company Ltd. in Finland and/or other countries worldwide. All other trademarks are property
of their respective owners. </p>
</div>
</body>
</html>
|