Hi, On Wednesday 29 June 2016 22:38:13 Émeric MASCHINO wrote: > Hi, > > I don't understand how frustum culling works with Qt3D (Qt 5.7 as time > of writing). > > From QFrustumCulling documentation [1]: "If present, only tries to > draw entities that are in the view of the camera. The camera is > selected by a QCameraSelector frame graph node in the current > hierarchy." > > How "If present" should be interpreted? I mean, how/where in the > framegraph should QFrustumCulling be created/added/made a child of > what?
The node should be far enough up the tree that is encompasses all the leaf nodes to which you wish to apply frustum culling. > I thus had a look at Qt3DExtras::QForwardRenderer source code [2]. > There, QFrustumCulling is simply made a child of a QClearBuffers > instance. But that's all. Is this sufficient to enable frustum > culling? And why not making it a child of the camera selector > (m_cameraSelector member)? Either way works. The renderer works by doing a "pass" for each leaf node in the frame graph. Each "pass", known as a RenderView, collects state from the leaf node up to the root node of the frame graph. So as long as the culling node is somewhere in that path, it will be applied. > If there's a reason that QFrustumCulling is a child of a QClearBuffers > instance, how would it work for multiple viewports like in the Multi > Viewports QML Example (there's no FrustumCulling instance there, hence > my question) [3]? I mean, all the viewports in the framegraph there > "share" a common ClearBuffers instance, but each viewport selects a > distinct camera, with a different point of view. The view frustum is > thus different for each viewport. If I had to enable frustum culling > in this example, should I put one instance only as a child of the main > viewport (like the ClearBuffers instance) or should I have one > FrustumCulling as a child of the top left viewport, another one as a > child of the top right viewport, and so on? Either, but having a single instance will result in slightly less work on the backend. Usually, you should propagate state that changes infrequently during a frame up towards the root of the framegraph. Think of each depth level in the frame graph as representing a different rate of change. The root node is constant over the whole frame whereas the leaf nodes define a section of the frame. Nodes in between vary with relative frequency to their depth in the frame graph. > Last but not least, is frustum culling really implemented? Source code > seems... well, simple [4]. There was a related bug report, but I can't > read that much history [5]. Frustum culling is simple once you have the bounding volumes for entities and the planes forming the view frustum. These are computed elsewhere to where the culling is actually performed. The culling is currently performed at: http://code.qt.io/cgit/qt/qt3d.git/tree/src/render/backend/renderview.cpp#n541 We are actually in the process of parallelising much more of the work that Qt 3D does on the backend. So shortly this will be done in a separate job: https://codereview.qt-project.org/#/c/159300/ Hope this helps, Sean > > Thanks, > > Émeric > > > [1] http://doc.qt.io/qt-5/qt3drender-qfrustumculling.html > [2] > https://github.com/qt/qt3d/blob/dev/src/extras/defaults/qforwardrenderer.cp > p [3] http://doc.qt.io/qt-5/qt3d-multiviewport-example.html > [4] > https://github.com/qt/qt3d/blob/dev/src/render/framegraph/qfrustumculling.c > pp [5] https://bugreports.qt.io/browse/QTBUG-42535 > _______________________________________________ > Interest mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/interest -- Dr Sean Harmer | [email protected] | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions _______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
