2
\$\begingroup\$

I've been learning graphics engine recently and I come across a term - conservative:

The CPU-GPU sync point problem Unreal solves like any other engine that uses queries, by deferring reading the query data for a number of frames. This approach works, although it might introduce props popping in the screen with a fast moving camera (in practice it might not be a massive problem though since doing occlusion culling using bounding boxes is conservative, meaning that a mesh will in all likelihood be marked as visible before it actually is).

I simply have no idea how this is helping in dealing with object popping problem (Maybe I don't have a picture of the process in mind). Also, I read that Nanite of UE5 also has conservative occlusion culling (from a deep dive into Nanite virtualized geometry):

enter image description here

So what is the point to be conservative? How does it influence real-time rendering process?

\$\endgroup\$

1 Answer 1

5
\$\begingroup\$

It means not throwing away objects you're not sure about, i.e. conserving objects when in doubt.

Primer

The concept of broad phase collision detection (or, in this case, visibility checking) is where we assume an entity to have a larger bounds than it actually does, e.g. using a bounding sphere or bounding box around the entity.

This allows for cheaper collision detection initially; only once we know the object is in that space, we go to the more expensive and exacting process of narrow phase detection, where we check against the detailed mesh of the entity, including its current transformed / animated state.

"Collision detection" here refers to "intersection of the view frustum with scene objects".

Answer

What they mean by conservative here is "conservative in terms of not possibly throwing away anything that might possibly be visible in the scene", i.e. it conserves geometry rather than discarding by default. Since doing broadphase checks only is cheaper and narrow phase checks may be deferred until a more opportune moment, that's probably why this happens.

The approach is liberal in terms of assuming broadphase bounding boxes to be a valid representation of visibility; and as a consequence of that, it is conservative in terms of discarding objects, i.e. "stuff popping into the visible scene before it should" (paraphrase), equating to "a mesh in all likelihood... be[ing] marked as visible before it actually is", as the view frustum may intersect the larger bounding box or sphere but not intersect the detailed mesh inside. Thus we conserve objects by default.

This should give you some perspective: While a and d are legitimately visible, c and b are not. Yet in their algorithm, "with a fast moving camera", c and b would be rendered anyway.

(The green arrow indicates that a moving object may have a much larger bounding box to account for its current rate of motion, thus potentially exacerbating the problem.)

enter image description here

Why defer?

Deferral is often done for expensive processes that happen multiple times per time period. Assume an expensive function F that is called multiple times per frame (for example). If we can consolidate multiple calls to F, the overall strain on system resources is less, and the impact thereof may be invisible the player (which is great). Tim Ford of Blizzard talked about this process for Overwatch.

\$\endgroup\$
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .