[Interest] [Qt3D] Frustum culling
sh at theharmers.co.uk
Thu Jul 7 19:54:41 CEST 2016
On 07/07/2016 09:46, Émeric MASCHINO wrote:
> 2016-07-01 17:37 GMT+02:00 Sean Harmer <sean.harmer at kdab.com>:
>> 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:
> Well, unless I'm missing the point, I only see m_frustumCulling member
> variable with setter/getter. But that's all: nobody seems to care
> about the status of this member variable, nor if it was set when a
> QFrustumCulling instance was found in a RenderView's frame path. Or
> maybe is it because you're in the process of rewriting things for more
> parallelism as you told?
Yeah, the change I linked to has already been merged, so that code has
now changed and all is done within the frustum culling job.
>> 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:
> As a side note, how jobs then "interface" themselve in the rendering process?
The Renderer is responsible for instantiating suitable jobs and setting
up the dependencies between them. In this case the renderer creates a
job to perform the world transform updates, then update the bounding
volume hierarchy. Once this is done the renderer performs a frustum
culling job (if enabled in the framegraph) using the data from the
previous jobs and the planes defining the frustum of the currently
selected camera (also from the framegraph).
Other kinds of filtering can also take place such as limiting entities
to a subset of defined layers. This is done in yet another job.
Much of this logic is controlled by the frame graph visitor:
>> Hope this helps,
> Yes, thanks :-)
> Interest mailing list
> Interest at qt-project.org
More information about the Interest