Relatively simple (but significant) interaction performance improvement with regard to Modifiers
Problem
As things currently are, everything in the scene updates at a consistent tick during user interaction. On smaller scenes, this behaves as you would expect, it's nice and smooth and you see a real time update of everything in your modifier stack. While editing dense scenes, or objects with a long list of modifiers, interaction is completely unusable because the user's input has a tendency to overshoot the desired target due to lag.
Consider the following specific example that is currently plaguing me:
Dragging live boolean objects around on a dense mesh is completely unusable even on an extremely high end system (threadripper + 1080TI). I currently have to isolate the cutter mesh, move it around to where I think it should go (which is a complete guess, because I've hidden the target mesh), then unhide everything to see the result. I do this back and forth until I land on something that is "close enough".
Proposed Solution
Add a per-object option to defer scene updates until AFTER interaction has finished. To use the live boolean example, this would result in a fluid interaction with the cutter mesh while you're dragging it around, and only when you release it the target mesh is updated. There would be a noticeable (and expected) hitch when you're finished interacting, but it would put control back in the user's hands. The option should be per-object because A) not all modifiers will benefit from this, and B) not all objects in a scene are going to exhibit these problems.
Note: this isn't exactly a new idea- in Modo, meshfusion had the same problems in dense scenes. Beyond some very basic models, it quickly became unusable until they added the Deferred Update option in 10.2: youtu.be/rq5vIs_1Drc
5 Comments
I've learned that mentioning another piece of software to Blender devs pretty much guarantees they will ignore everything else you've said. I like this proposal and think it makes sense, but don't think it will gain much traction unless you pull the note off the end of your proposal.
@dpdpforlife: You are probably right, but i'm going to leave it on principle. Blender's growth is going to be largely driven by users migrating from other software and bringing new ideas with them, and if we don't want to follow Autodesk down the path to turning users away it's imperative that we are able to objectively consider a proposal without the interference of ego.
An overall market ignorance and apathy toward their userbase is one of the many reasons why Autodesk has been swirling the drain for so many years, and I may be unreasonably idealistic but I have faith that the Blender development community on the whole can mature beyond such pettiness.
Hi, it's not a question of ego but one of law : if they start working on something that is admittedly based off a copyrighted feature/concept from some other software it may cause legal issues. I second that you should remove your last paragraph and leave it at that.
That's a good idea, and although your specific example has a better solution (disable visibility of modifier instead of hiding boolean object) there's nothing to argue with, and I think the new dependency graph might help with that actually, by scheduling partial scene updates more efficiently.
* @Hadrien Brissaud * I'm not sure you can copyright a concept in software. We'd be screwed if only the first software ever created was able to have a save function due to concept copyright.
Check out most 3d applications, they all have displace modifiers, smooth modifiers, uv unwrap modifiers/processes, etc etc.
I know this is a necro post, but blender got in trouble for the direction widget at the top. a certain "automated table" decided arrows on a box was their idea