[Interest] [Qt3D] Frustum culling

[Sean Harmer]

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
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest

--
Dr Sean Harmer | sean.harmer at kdab.com | 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