Page MenuHome

Sculpt: Delay Viewport Updates
ClosedPublic

Authored by Pablo Dobarro (pablodp606) on Nov 18 2019, 1:40 AM.
Tokens
"Love" token, awarded by MetinSeven."Like" token, awarded by EAW."Love" token, awarded by monio."Like" token, awarded by Frozen_Death_Knight."Like" token, awarded by franMarz."Like" token, awarded by Alrob."Mountain of Wealth" token, awarded by Brandon777.

Details

Summary

In Blender 2.81 we update and draw all nodes inside the view planes.
When navigating with a pen tablet after an operation that tags the whole
mesh to update (like undo or inverting the mask), this introduces some
lag as nodes are updating when they enter the view. The viewport is not
fully responsive again until all nodes have entered the view after the
operation.

This patch delays nodes updates until the view navigation stops, so the
viewport navigation is always fully responsive. This introduces some
artifacts while navigating, so it can be disabled if you don't want to
see them.

I'm storing the update planes in the PBVH. This way I can add support
for some tools to update in real-time only the nodes inside this plane
while running the operator, like the mesh filter.

Should fix viewport navigation issues mentioned in T71564

Diff Detail

Repository
rB Blender
Branch
arcpatch-D6269 (branched from master)
Build Status
Buildable 7135
Build 7135: arc lint + arc unit

Event Timeline

Feels like implementing a patch that hides the part of the code that needs to be optimized.
Perhaps spend some time looking at alternatives and point the pros and cons of them so we can decide what the best way is to tackle this problem. You can open a design task for this.

Jeroen Bakker (jbakker) requested changes to this revision.Dec 12 2019, 11:49 AM
This revision now requires changes to proceed.Dec 12 2019, 11:49 AM

I don't think this is about hiding a not optimized part. Nodes need to be updated on the GPU and those updates are already multithreaded. Even if we make that process 10 times faster, that will still take some compute time from viewport navigation and that could make the viewport movement lag.
This is more about UX. The option is similar to the "Fast Navigate" of multires or the option some windows manager have to display only the outline of the window if the hardware is not enough to redraw the whole content in real time while moving it. This is just trying to give priority to the responsiveness of the software instead of displaying 100% correct information all time, which is a common practice in software design.
@William Reynish (billreynish) What do you think?

Prioritizing responsiveness over fidelity is indeed often a good tradeoff for GUIs.

The main issue I have is mostly that it is presented as yet another toggle for the user to set. Could we not just do this when Fast Navigate is enabled? So Fast Navigate does both things at once.

@William Reynish (billreynish) In my opinion, I would remove both options and leave them enabled by default. If you are using multires it is because you want to take full advantage of its performance and GPU geometry updates should never happen during view navigation, but I'm not sure if some users would find that annoying.

Also, there is an artifact that you are not seeing in the video. If you run an operation that requires a full PBVH rebuild (like remeshing), geometry that was outside the view won't be rendered while navigating (similar to this https://twitter.com/pablodp606/status/1177352630710001664 ). Currently, that geometry is being uploaded to the GPU as the viewport moves, so it makes the navigation lag a lot. I still prefer not seeing the geometry while navigating than the lag.

I wonder if hiding the mask (and other overlays) entirely is possible during this "Delay Viewport Update"? I think it will be a slightly nicer experience if the mask disappeared entirely and reappeared again, instead of popping in and out. I immediately thought of Multires Fast Navigate when I saw this, and I agree it would be a good idea to combine the two into one checkbox.

  • Rebase
  • Fix face set drawing

Can we commit this fix or an alternative solution for 2.83? With face sets and multires planned it is now more common to use operation that requires all nodes to be updated and rebuild in high poly meshes, which makes the viewport navigation and cursor lag constantly.

IMO we should put the option in a different location (seems more a user setting) and perhaps enable by default. As you say you want to enable this feature by default in the future.

This revision is now accepted and ready to land.Apr 2 2020, 8:55 AM
This revision was automatically updated to reflect the committed changes.