Page MenuHome

Draw-Manager: Allow independent gizmo redraws
Confirmed, NormalPublicTO DO


Draw-Manager: Allow independent gizmo redraws


Currently, to redraw a gizmo, we have to redraw the entire viewport. So whenever a gizmo changes highlight state, visiblity state or any other visual state, the entire viewport is redrawn. This may be a very expensive operation that we should definitely try to avoid.

For the first XR milestone (T71347), we further want to introduce gizmos to viewports that give feedback on the VR session. For example gizmos indicating the position and rotation of the VR camera and the controllers. They would have to be constantly redrawn at a rather high rate to be useful. Redrawing the entire viewport for this takes many resources needed for the VR view rendering.
This is such a gizmo, it currently requires redrawing the entire viewport for every frame:

Basic Proposal

It would be nice if we could just render gizmos into a separate framebuffer and overlay that on top of the viewport, so that both can be updated independently. Integrating the gizmo drawing with the draw-manager passes and compositing would be quite difficult, and brings its own overhead (re-running draw loop, managing passes, compositing, ...).

@Jeroen Bakker (jbakker) suggested to instead blit the default framebuffer into a separate one before gizmos are drawn. That one can then be kept around and re-used to redraw the gizmos on top, whenever they changed visual state.
We'll also need to redraw 2D annotations and region info (cursor, render border, view-axis, FPS text, etc) then, since they draw in-between 3D and 2D gizmos. Doing so isn't that expensive though.

We may want to have an option to use the old full-redraw behavior over the more performant one, as the latter is heavier on GPU memory.

Event Timeline

We plan to use a similar scheme for the main viewport itself. Having only the overlays and/or the gizmos redrawn on top of the cached render.

just out of curiosity, is this bug T72968 a similar problem?

just out of curiosity, is this bug T72968 a similar problem?

It could fix it but would not fix the core issue.

Aaron Carlisle (Blendify) changed the task status from Needs Triage to Confirmed.Feb 17 2020, 8:21 PM