Change Details

= 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, 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: {F8283190} == 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, ...). @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. Doings 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 (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: {F8283190} == 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, ...). @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.

= 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 (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: {F8283190} == 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, ...). @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. Doings 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.