Optimized per-datablock global undo #60695
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
96 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#60695
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Global undo is slow on scenes with many objects. A big reason is that undo writes and reads all datablocks in the file (except from linked libraries). If we can only handle the ones that actually changed, performance would be much improved in common scenarios.
This proposal outlines how to achieve this in 3 incremental steps. Only 1 or 2 of these steps would already provide a significant speedup.
At the time of writing there is no concrete plan to implement this, but I've had this idea for a while and it seemed useful to write down in case someone likes to pick it up.
1. Read only changed datablocksDONELinked library datablocks are already preserved on undo pop. We can do the same thing for all non-changed datablocks, and only read the changed ones.
We can detect which datablocks were changed by checking that their diff is empty. Addition and removal of datablocks also needs to be detected. We need to be careful to exclude runtime data like
LIB_TAG_DOITfrom writing, to avoid detecting too many datablocks as changed. Most changes to runtime data go along with an actual change to the datablock though.Since unchanged datablocks may point do changed datablocks, we need to reload datablocks in the exact same memory location. We can safely assume the required memory size stays the same, because if it didn't those other datablocks' pointers would be changed as well. In principle other datablocks should not point to anything but the datablock itself, but there may be exceptions that need to be taken care of (e.g. pointers to [armature] bones hold by [object] pose data...).
Mainfields other than datablock lists may need some attention too.2. Optimize post undo/redo updatesDONEThe most expensive update is likely the dependency graph rebuild. We can detect if any depsgraph rebuild was performed between undo pushes, and if so mark that undo step as needing a depsgraph rebuild. This means the undo step is no more expensive than the associated operation.
This requires the dependency graph to be preserved through undo in scene datablocks, similar to how images preserve image buffers. This would then also preserve GPU data stored in the dependency graph. If the dependency graph supports partial rebuilds in the future, that could be taken advantage of.
There may be other expensive updates, to be revealed by profiling.
3. Rethink how we handle cache preservation across undo steps.
#76989 seems to point to some pointer collision issue, similar to the reason that lead us to add session uuid to IDs when we started re-using existing pointers in undo.
Note that according to the report, there were already issues before undo refactor - hard to tell though if they had the same root cause?
This needs to be investigated further.
4. Write only changed datablocks
While undo/redo is usually the most expensive, the undo push that happens after each operation also slows down as scene complexity increases. If we know which datablocks changed, we can only save & diff those.
This could be deduced from dependency graph update tags. However there are likely still many operations where tags are missing. If it is not done correctly, then instead of a missing refresh there is a more serious bug of not undoing all changes. So this needs verification throughout the Blender code for correct tagging, before it can be enabled.
Debug builds could verify correctness by testing the diff is empty whenever there was no tag.
Current Status and Plan
There is an experimental option in 2.83 to address step 1 and (part of) step 2. This was developed in branches and is now in master. Implementation of step 3 has not started.
id-ensure-unique-memory-addressbranch).id-ensure-unique-memory-addressbranch).session_uuidcould be used to find matching datablocks.Added subscribers: @brecht, @mont29, @ideasman42, @Sergey
#60418 was marked as duplicate of this issue
Added subscriber: @sobakasu
Added subscriber: @Mets
Added subscriber: @machieb
Added subscriber: @juang3d
Added subscriber: @MACHIN3
Added subscriber: @JerBot
Removed subscriber: @JerBot
Added subscriber: @JerBot
Added subscriber: @DanielGrauer
Added subscriber: @MichaelWeisheim
Added subscriber: @0o00o0oo
Added subscriber: @filibis
Added subscriber: @AlanNoble
Added subscriber: @NahuelBelich
Added subscriber: @mz-4
Added subscriber: @DanielPaul
Added subscriber: @SergienkoEugene
Added subscriber: @JonDoe286
Added subscriber: @EnzioProbst
Added subscriber: @YuryZiankouvki
Added subscriber: @AndreyRusnak
Added subscriber: @MauricioMarinho
Added subscriber: @crantisz
Added subscriber: @DanieleViagi
Added subscriber: @Lambdadelta
Added subscriber: @jimix85
Added subscriber: @slumber
Added subscriber: @SamGreen
Added subscriber: @AntoineRol
Added subscriber: @z01ks
Added subscriber: @pilotchiao
Added subscriber: @sinokgr
Added subscriber: @Piquituerto
hi @brecht , with version 2.8, we decided to give another go to Blender and overall it is great release and we were considering switching, but this undo issue is a the biggest show stopper we found so far. I'm surprised to be honest with the fact that this is considered "normal" priority. I have never worked in a production that doesn't have a few thousand objects per scene with a few million polys. If undoing a move takes a couple of minutes, this makes blender unusable for most productions I think. I decided to add this comment with the hope to bump this up a bit. I hope that's OK.
Nick
Yes I think we need to make more noise about this. It's disconcerting that this task is Normal Priority. Blender is getting a lot of hype because of Eevee and UI improvements, and many people are posting cool little video snippets of what can be done. But as soon as a scene gets a bit bigger, the simple function of Undoing becomes a major hinderance. I just finished a slightly more complex scene and the Undo performance was the biggest issue I faced throughout the whole project. It's not just that we need to wait 5-10 seconds for the Undo, it's also all the times you avoid Undoing because you know it's going to lock your computer for a while. This inhibits creativity as well, as Undo is a weapon that an artist can use to try many many different things quickly. I think Ton Roosendaal's priority has always been that Blender has to be fast. So let's bump this up to the highest priority possible!
Undo lag is also for me the biggest production killer in the moment. Not only modelling, everything (except of edit poly) gets dramatically slow undoable on more complex scenes. It affects every user in mid-late state of the project, even with SSD and high end pc it's just slow. So thumb up that this feature gets more important!
I agree with you guys, I think this should be high priority, I work for the video game industry as a Senior Character artist and I'm wasting a lot of production time because of the slow undo. Characters scenes are heavy ( around 25 millions polys ) and we use a lot sculpting tools with subdivision modifier. I'm currently testing blender 2.8 features and I'm evaluating if it make sense to use it for the whole character modeling production. Unfortunately for the moment I can't recommend it to my co-workers because of this performance issue. Blender team did a great job with this 2.8 release and I love using this software, as soon as this performance issue get fixed I think it will be awesome to use and ready for production.
Removed subscriber: @Mets
Added subscriber: @FeO
I agree with the understated importance of this issue: no matter how great the advanced functions of a software are, if it's basics aren't rock solid, it's not usable in an actual production process.
The Undo function is one of the most used and the lag it currently generates kills all possible efficiency that Blender can otherwise provide.
The "undo step is no more expensive than the associated operation" is an absolute must-have before I can advocate for using Blender in a professional context, which I hope I eventually will.
Is the issue with slow undo known/reported?
Are there examples of comparable files which perform well in 2.7x and badly in 2.8x?
The code for global-undo (memfile undo internally) didn't have changes which should impact performance since 2.7x, it's quite possible the performance issue is elsewhere.
Undo is bad in both, this is not a regression, any complex file makes undo nearly a torture to use. Just animating a camera for example, you are just transforming the camera, and making undo in a big scene takes A LOT instead of being instantaneous as it should be.
Check this thread, there are a lot of people talking here about their undo experience:
https://devtalk.blender.org/t/blender-2-8-undo-improvements-it-last-45-seconds-to-undo-an-object-movement-in-a-big-scene/2554
@ideasman42 my understanding is that reports about 2.8 undo being slower than 2.7 are not issues in the undo system itself, but rather related to features like subdivision surfaces and the dependency graph.
Still, doing improvements like these would solve performance problems that we already had in 2.7, and reduce dependency graph overhead even if that's good to optimize on its own too.
Removed subscriber: @sobakasu
Removed subscriber: @AndreyRusnak
I started using blender with 2.78 and use it daily. I'm pretty sure there is no significant slowdown in 2.8 compared to 2.78.
With 2.8 there is just so much more feedback from the industry who work with big scenes, that this topic increased in attention.
Undo in blender was and still is, super slow.
@brecht I'm sorry if this is annoying, but can we have some insight into plans for this topic? Will we see something about this in the near future?
Sadly this is pretty much the most important feature for all people I know, who want to and already are working with blender. (Including me)
We consider this a high priority task and will try to get it solved sooner rather than later. It's marked as high priority in #63728 (Data, Assets & I/O Module).
Oh, that's amazing. Can't wait for this to be addressed!!
That's pretty good news :D Thank you!
Will at least investigate the first part of the project, we already kind of do that with linked datablocks, so should not be too hard to handle local unchanged ones the same way...
Hi @mont29,
That's great. If you have a build that you want us to test, can you please give us some instructions of how to download and I can compare with the existing version.
Removed subscriber: @SergienkoEugene
Added subscriber: @DanPool
Correct me if I’m wrong, but this approach of only updating modified datablocks won’t improve performance in a scene containing a single high density mesh object. Am I right? Would this be only on the level of mesh edits, or would simple changes like location, rotation and scale also require fully reloading the mesh object?
Added subscriber: @MeshVoid
Added subscriber: @softyoda
Added subscriber: @item412
Added subscriber: @damd
Added subscriber: @ReguzaEi
Added subscriber: @justastatue
Did some preliminary tests in undo-experiments branch, fairly dirty but working enough to get a first idea of PART 1 project.
So far, playing with undo in a big Spring production scene (lighting one, just moving around some lights and undo), avoiding reading of unchanged IDs saves about 30% of the read process time. Thing is, we are talking of around 100ms (130 ms with current master code, 90ms with code in the branch), when the actual undo step takes about 4 seconds from a user PoV. So main optimization is clearly to be sought into the scene update/rebuild happening after undo 'memfile' has been read...
A single undo in my scene, was at least a couple of minutes. My scene was an imported FBX data from a car manufacturer (and under NDA so I can't share I'm afraid).
Thanks for the tests. Step 1 by itself is not the important optimization in a file like that indeed. But it's a prerequisite for step 2, to be able to preserve most of the depsgraph.
Added subscriber: @perpleks
Added subscriber: @nokipaike
a question...
if we have a data collection (a mesh with a certain n number of vectors) and we move the pivot of this data, blender with the undo recalculate-read&write the displacement of all the vectors of the mesh or just the displacement of the pivot point ? ... because it is obvious that in the first case it is a problem of heaviness ...
Added subscriber: @John_Do
Added subscriber: @Voguart
Added subscriber: @lastrodamo
Added subscriber: @beefaroni
Really glad you all are tackling this at a high priority. Thank you.
For AAA hard surface asset production the undo history is the single biggest thing holding back adoption from other artists. Maya and 3DS Max are able to undo almost instantly in comparison.
Added subscriber: @DaveStromberger
Added subscriber: @MaciejMorgas
Added subscriber: @CharlieJolly
Undo also stores unnecessary things. E.g. node selection is stored.
Nodes selection is very common to be stored in the undo and it is very useful in many cases, especially on huge scenes where they will be very slow to navigate and you may have had to manually select many objects and you might accidentally click somewhere that will lose your current selection.
@sinokgr I see your point but that might be better managed by using frames and groups
@CharlieJolly yeah, maybe but to be honest, personally I wouldn't change its default behaviour. It works as people expect. The only issue I think people have, is with the performance. That's my opinion at least.
That's a discussion better held elsewhere, this task is only about solving a specific performance issue in undo.
Added subscriber: @fsiddi
Added subscriber: @AlbertoVelazquez
Added subscriber: @MichaelHermann
Added subscriber: @Schiette
Just wondering if it's possible to estimate whether there will be global undo performance improvements to be expected in 2.82 and which bcon phase? Thanks!
One of the scenes I'm working on is again entering the complex and heavy stage, where the wait time for undoing simple things like moving/rotating/scaling as well as selecting objects is exceeding 5 seconds. This is basically training me to avoid Undoing, but overall I must say it creates a lot of frustration.
I admit that the whole data block and depsgraph discussion is over my head. But I have the advantage of a simpleton when it comes to coming up with very plain ideas. Maybe it would be possible to have an Experimental feature or even an add-on that would be recording a list of the types of actions the user performs. This could be a separate Undo for Heavy Scenes and could have its own shortcut. So whenever the user moves, rotates, scales or selects anything, that gets remembered by the script. Then when the Heavy Undo button is pressed, it will just go back a couple of steps in the list, but AVOIDING the regular Undo function. Rather it just moves an object back to where it was a couple of lines back in the list. If that makes sense...
So this Experimental Feature could be a simple workaround until the real Undo is ironed out.
Added subscriber: @SteffenD
Can large models be broken into smaller chunks? A single mesh model that I can edit freely in 3ds Max takes 5 or so seconds to update in Blender. Undo also takes about 5 seconds.
For instance there are import routines for Unity that split the mesh into a separate submesh every time a certain threshold is met. I think it’s around 50k polys. I’m sure this wouldn’t be easy, since the mesh would have to be merged and welded for the 3D View and UV Editor, but it may help with performance of sculpts and imported cad files.
Added subscriber: @dgsantana
Added subscriber: @GeorgiaPacific
Removed subscriber: @GeorgiaPacific
Added subscriber: @GeorgiaPacific
Added subscriber: @LapisSea
Added subscriber: @FrancoisRimasson
Added subscriber: @seaside98-4
Added subscriber: @Fad.N53
Added subscriber: @youthatninja
What about separate undo per mode? 🤔
As it was in 2.7x
When you undo in edit mode it roll back as normal, but if you undo in edit mode it roll back you to the stage before you last enter in to edit mode
AFAIK (@ideasman42 may confirm, I think he knows the whole undo stack behavior better than anybody else currently):
Edit modes already have their own undo management, the change in 2.8x was to integrate them into the general undo history as a single timeline.
The undo type involved in this 'speedup' project (nickname “memfile” undo, re-reading a whole .blend file from memory to simplify) is only used in Object and Pose modes.
Edit modes use each a specific, optimized undo type that already does not involve re-reading a whole .blend file (and hence does not invalidate the whole depsgraph and evaluated/cached data).
So why not split the timeline for time being?
Because most of crashes happens when you jumping back and forth modes then undo steps
blender starts to cycle through modes -> 💯% crash, even on not heavy scenes
Have you reported this bug? I’m not having this issue.
I have also experienced this crash. Although pretty rarely and inconsistent so I was unable to produce a bug report.
Removed subscriber: @machieb
@DanPool i think there are plenty of those reports. yes, maybe is too much as i said about 100% crash.
it's most likely inconsistent but not much rarely and it hard to reproduce as @LapisSea said.
anyway the struggle is real, when you tweaked one vert go out edit mode then again in to edit mode, and then you decided to rollback
i vote for split 'timeline' as it was in .7x, at least for a time being.
Please stick to the specific topic of this task, this is not a forum.
Removed subscriber: @YuryZiankouvki
Removed subscriber: @Voguart
Added subscriber: @rwman
Added subscriber: @MrBeep
Why this is Normal priority? Undo in Blender 2.8 takes two times more than in 2.7 and is so slow compared to undo in any other application. Starting from simple Notepad to complex ones like Cinema 4d. This should be set the highest priority above all others issues.
@MrBeep this is not a forum to have random chat, but a design task over an highly technical topic. Please refrain from useless comments.
Where can I state my discontent over current technical issues Blender is struggling with making sure my opinion will be noticed by the developers?
devtalk.blender.org and mention the developer you want to notice with an @ usually they notice it :) (admin delete this message after a while if you think it’s better)
Added subscriber: @BintangPratama
Added subscriber: @YegorSmirnov
Added subscriber: @MetinSeven-1
Will this optimization also be beneficial to the frustrating undo / redo behaviour in Sculpt Mode? I truly hope that will be fixed soon.
Removed subscriber: @MetinSeven-1
Added subscriber: @Moult
Added subscriber: @Achraf-Ayadi
Added subscriber: @ckohl_art
Does preserving/re-using unchanged datablocks/memory mean that this Gotcha will no longer be true 100% of the time? (for data/IDs that didn't change) https://docs.blender.org/api/current/info_gotcha.html#undo-redo
Added subscriber: @Yianni
@ckohl_art the pointer will remain the same if the object still exists after undo. But it can of course get deleted, so you still can't rely on it.
Added subscriber: @Aurontwist
Removed subscriber: @MrBeep
Removed subscriber: @perpleks
Added subscriber: @ebarranco
Added subscriber: @2046411367
Looking into the current state I found a few issues. Some require potentially deeper design changes to get maximum performance.
Double Undo Step
Currently every object mode undo will undo twice. Once doing a complete file read to restore the current state, and then a second one partially reading only changed datablocks. Since the current bottleneck is often still the depsgraph this is not always a big problem, but it's still something we should avoid.
A simple fix for that would be to initialize memory chunk
is_identical_futuretotrue. Or better, to skip reading such an undo step which has no changes relative to the current state entirely.However, the problem is that we don't actually know for certain that there have been no changes relative to the current state. For a few reasons:
One way to solve this would be to perform an undo push right before we do an undo pop. This would let us reliably detect when the scene has actually changed, and allow the contents of unchanged datablocks to stay the same which should help the depsgraph.
Of course, writing the entire database to avoid reading the entire database is still not particularly efficient. Once step 3 of this design task is implemented, we would however be able to write just the changed datablocks which would make it faster.
Further, we could consider changing when undo pushes happen. Maybe after dependency graph updates and (some but not all) Python handlers, or even UI drawing. Or we could perform undo pushes only before operators run. However this has significant implications for how operators perform undo, also those implemented in Python add-ons breaking API compatibility.
Depsgraph Update Flags
D7274 fixes an issue with meshes being detected as always changed after they have been changed once. But I still found that e.g. editing a modifier parameter will cause slower undo two steps later. The reason for this seems to be that dependency graph evaluation is performed after undo.
id->recalcis saved along with the undo step, and will be set still because the dependency graph has not been updated yet. When loading the undo step, this value is restored which means dependency graph evaluation has to be re-done. In most cases this is really only needed for data flushed back to the original datablocks, the evaluated datablocks may be in the correct state already. Performing undo pushes after dependency evaluation would help with this, though as explained above is not a simple change.The other issue that accumulation of recalc flags also happens after undo. This means they will be included in the next undo step which may be for a completely different operator. One way to solve this would be to accumulate the recalc flags set by operators, not after depsgraph flushing or evaluation. Basically, accumulate all flags passed to
DEG_id_tag_update(). For correct results, after undo we would then callDEG_id_tag_update()with those flags, so any indirect flags are set as well. Doing this would limit slowness only to one step later.Short term I suggest to do the following:
runtimemembers andid->tag.is_identical(_future)and only read changed datablocks. I would do this for performance, but also because I'm not entirely sure the current code will give correct results in all cases.This could get us in a state where the it's still slower than it could be in some cases, but hopefully faster in most cases and stable enough for 2.83.
Then the next step could be:
This comment was removed by @beefaroni
We have enough complex production files for testing at this point. The most important way to help now is finding bugs where things crash or corrupt .blend file, which any user can help with by enabling the experimental undo speedup option, and then reporting bugs to the tracker that explain how to redo the problem.
It also helps somewhat to find cases where undo is unexpectedly slow. However there are currently a number of known cases where things are still slow that are hard to explain. So it's probably more efficient for us to fix those first since otherwise those will be reported over and over.
Added subscriber: @mattli911
I just tested out a scene with some heavy geo/higher object count I've been working on in 2.82. Normally it's been taking 20~ seconds to undo an object movement/non Edit Mode stuff.
Testing out the very latest 2.83 build, with the fix on, I was getting almost instant Undos now, or < 1 second! Sometimes it would stall out, as noted above in comments, but at worst it seemed to be about 12 seconds now. Sweet!!
Although, I am seeing worse view-port performance vs. 2.82. My GPU was hitting 100% in windows sometimes and stalling out a video playing in the background, for example. Also just rotating the view looked choppy vs. much more smooth/no real issues in 2.82. Could be from Undo fixes or something else going on?
In any case, thank you guys for working on this, this is my #1 fix / wish right now for Blender. Sorry if this is considered "spam" / delete if you need to.
@brecht that plan looks sound to me.
I can do the runtime fields clearing, wanted to do them asap anyway... this will just require handling more IDs with a temp copy as we already do with meshes...
Added subscriber: @c2ba
This issue was referenced by
c5ed2eb95eI addressed some of the issue explained in #60695#899783 in D7339: Undo: change depsgraph recalc flags handling to improve performance. This doesn't try to handle any issues with Python app handlers or other operators not doing undo pushes, but I think it may be ok in practice anyway.
I found another slowness issue when adding/duplicating/deleting objects, and added that to the list in the description.
Wow, I was testing the latest build as of this morning and so far, i see pretty big speed improvements!!
In a more complex undo, duping an entire highpoly weapon and moving it and hitting undo, it is about 2-3x faster than 2.82.
Doing more normal level of undos, its 4-5x faster than 2.82, taking less than 1 second vs. 4-5 seconds on 2.82. Awesome!!
It would be really great if you guys make it even faster, but so far, I'm super happy to see this. Thank you for all your hard work so far!
Added subscriber: @Pinnhead
In Blender 2.90 Alpha with new undo enabled. Undo in object mode in heavy scene (over 12M tris) increased from 33sec (Blender 2.82) to 1 second. Bravo devs!
https://twitter.com/i/status/1250696931904573442
Added subscriber: @Leul
Hi there.. is this #70814 bug related to this undo (basically it causes the first undo of a stroke to also undo brush settings)
@Leul, that's unrelated to this specific task.
Added subscriber: @vidarino
I have experienced some weird Rigid Body behaviour when undoing lately (e.g. #76053), including some crashes, and all the weirdness seems to go away when I use legacy undo. I can't reproduce the crash reliably (I'm trying to work that out as we speak), but #76053 might be a starting point.
Added subscriber: @flipswitchingmonkey
Not sure if it is related to the new undo, but I just faced weird bug: When in edit mode, i pressed Ctrl-Z to undo (inteded to undo scaling some vertices), and then quickly Ctrl-Shift-Z to redo, but i ended up in weird state - the mesh appear scaled, in the undo history I appear to be two steps below the tip, and if i redo those two steps, they was undoing my scaling action halfway for each of those two steps.
Sadly I can't reproduce it yet.
That is blender 2.83.15 with new undo turned on.
I saw an update posted above, about fixing some issues that caused the entire scene to be reloaded yet?
Not sure if that's in 2.9 alpha build as of today or not however. Unless is not a fix yet either?
I am still seeing long undo steps when going between object mode/edit mode. But that might still be in the works/on the books.
I feel if that can be solved / reduced even 50%, that would make things much much better :).
Overall Undo is still way faster than it's been in the past, since 2.8. But since I'm often am toggling between edit/object mode and have to undo, it can still be alot of waiting around between those steps. Or I try to look at the undo history and jump to that specific point if at all possible, to make it faster.
Windows 64bit, running 2.9 Alpha (May 30, 00:27:32 -
2ee94c954d)This issue was referenced by
cda1540858This probably isn't possible / would require massive changes, but I have no idea. But looking at 3DS Max Undo again, they are doing it in a way, where when you Undo, it doesn't matter if you are in Object or Edit mode, it will still undo those steps/not switch between states during Undo.
Meaning, if you are in Object mode, it will still Undo the Edit Mode level changes. Part of the lag I think I still experience in even 2.83, is the fact that blender has to switch to Edit mode/back and forth, in order to Undo those changes. Object mode Undo is faster now, but when it has to switch back and forth into Edit mode, it can take 5,10+ seconds yet.
I also notice things like Proportional Edit (Soft select) will Undo/get Toggled On/Off during Undo as well, which is very strange to me. It seems like some of those UI elements should not be affected/not be accounted for in the Undo, IMO. Or really maybe most UI things are ignored, except for Modifiers or that sort of thing?
The UI aspect of this may or may not contribute that much to the overall speed/is probably another task/item all together, but thought I'd mention in here as well.
Added subscriber: @oweissbarth
Are there still plans to improve Undo? Object level Undo is much better now. Although I still see some pretty long/rough Undos when toggling into edit mode and back out and then undoing.
I can often sit and wait 5,10,15 seconds yet for 1 undo step in a denser scene.
The mesh itself is lowpoly, but has some modifiers on it like bevel/subSurf. I'm not sure if it's because it's having to reload the entire scene during undo/recalculate a ton of modifiers or what.
I see the issue in 2.90.1 or 2.91/etc.
I can create a new bug if that helps/create an example file/scene or upload something here.
Same here... on simple scenes... undo is fine.. though as soon as I hit a definite complexity level.... Blender undo becomes pretty slow.. spending quite a big percentage of my work waiting for an undo step.
Added subscriber: @Nominous
Added subscriber: @Byron1c
Added subscriber: @PhilippeCrassous
Bumping this again.
Basically it's the same as what I mentioned above. I'm currently in 2.91.2, and when I'm in a more complex scene, Undo is getting to be super annoying/slow/killing productivity.
If I make changes in edit mode, toggle to object level and toggle back into edit, then Undo, it can stall/take 5-10 seconds at least to undo my last edit...
This is even editing/toggling a mesh as simple as 100 verts or something. When I toggle/undo, it appears to reload the entire scene in those cases, or so I assume/am guessing.
This can really start to impact general workflows/flow when trying to work on the lowpoly stage , for example, while my highpoly is visible in the scene. So that I can see how things are aligned/fitting/etc.
I know I could hide the highpoly meshes in a collection/layer or some other method, but I really need to see both at once.
Coming from other modeling programs, I've really not even thought about my Undo actions, or it's basically a non-issue. But in blender it's starting to become a pretty big annoyance and sometimes almost makes me want to just use another program again.
It's great to see other areas of Blender improving, but, I really hope to see Undo getting love again... since it's a super basic action that EVERYONE always uses, and I feel really needs to function as smoothly as possible, to not get in the way of peoples flow/creativity/etc.
thank you!
I've switched to maya just because of this... :/
Added subscriber: @zrp
whats your scene like? how many polygons? whats your PC specs? I think after I upgraded my pc the lag is very less. Go to preferences and in viewport settings maybe remove anti aliasing? this helped me to increase the performance.
I think it's fairly obvious polygons/computer specs isn't the issue here. He's noticing undo in Blender is a pain whereas with other programs he didn't even need to think about it.
Unfortunately, it's a problem with Blender that needs fixing at high priority, not a problem with a user's workflow/computer.
+1
Added subscriber: @Ryda42
The whole undo system seems to need an overhaul. Like you, this is causing me to consider other programs.
Removed subscriber: @lastrodamo
Added subscriber: @Vyach
Added subscriber: @raincole
Bumping this too after I read 3.0 roadmap.
In my opinion the undo performance is the biggest issue that Blender has in its current state. While more features and UI improvements are nice, studios can easily afford hiring people who knows Python to improve their workflow. What they can't do is to overhaul how undo works. If core team isn't solving this, then no one will be.
I've never seen any other software that lags so badly for undo. And unfortunately, undo is one of the most used feature in any software. I understand it's a lot of work to overhaul such a fundamental part of Blender, but that's exactly why we need the core team's help. If it were easy people would've solved it anyway.
I know the veterans are used to it and accepted that's how Blender is. Again, Blender is probably the only software on the earth that requires users to be so aware of their undo actions. It often takes as much time to undo a single vertex editing as to run a frame of physics simulation, which is one of the most challenging task in computer science. I hope this means something.
Added subscriber: @Garek
Added subscriber: @IihT2cWA9xiP30BsYphz3EiEISNoScoe
Added subscriber: @RedMser
Added subscriber: @Dangry
Added subscriber: @CHARLES-MURRAY
Hi all!
I'm sorry, it seems to me that your function causes an illogical reset of the cursor to the origin of the coordinate system after canceling the action. I will leave a link to the page where I described my problem and its solution.
#118132