Draw-Manager: Allow independent gizmo redraws #73198

New Issue

Julian Eisel · 2020-01-17T15:49:16+01:00

Julian Eisel commented

2020-01-17 15:49:16 +01:00

Draw-Manager: Allow independent gizmo redraws

Motivation

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 (#71347), 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:

06_vr_view_gizmo_update.m4v

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 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.

# Draw-Manager: Allow independent gizmo redraws ## Motivation 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 (#71347), 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: [06_vr_view_gizmo_update.m4v](https://archive.blender.org/developer/F8283190/06_vr_view_gizmo_update.m4v) ## 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 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.

Julian Eisel commented

2020-01-17 15:49:16 +01:00

Added subscribers: @Jeroen-Bakker, @JulianEisel, @fclem

Asher commented

2020-01-17 16:04:12 +01:00

Added subscriber: @ThatAsherGuy

Clément Foucault commented

2020-01-17 16:09:15 +01:00

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.

noki paike commented

2020-01-17 22:51:25 +01:00

Added subscriber: @nokipaike

noki paike commented

2020-01-17 22:51:25 +01:00

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

Clément Foucault commented

2020-01-18 11:42:59 +01:00

In #73198#852359, @nokipaike wrote:
just out of curiosity, is this bug #72968 a similar problem?

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

> In #73198#852359, @nokipaike wrote: > just out of curiosity, is this bug #72968 a similar problem? It could fix it but would not fix the core issue.

Miro Horváth commented

2020-01-21 10:26:46 +01:00

Added subscriber: @MiroHorvath

Aaron Carlisle commented

2020-02-17 20:21:13 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Draw-Manager: Allow independent gizmo redraws #73198

Draw-Manager: Allow independent gizmo redraws

Motivation

Basic Proposal