subsurface modifer, displacement and array. i was going to increase the amount in the array so that it goes from the bottom to the top (making an hourglass), but i didnt see any difference, so i slowly moved my mouse to the right. then everything froze, so i releaced my mouse and moved it to the side, but blender didnt registrate that i let go of the mouse. and i ended up with a count of almost 500… i had to wait for 15 min for blender to finnish thinking…
would it not be great if blender had an extra security level? such as if you increased a value like this, you get a notification in the bottom corner that an action is being preformed, and you being able to cancle it at any time. kind of like baking. you click bake, and then you get the black square witch shows the progress. and you can cancle it at any time.
Sure it would be great, that’s really annoying behavior. Unfortunately, like many other applications Blender is relying on working mostly in a single main thread, without background tasks or interruptible computations (except for rendering, which was designed with such capabilities in mind). It’s not that everyone was waiting for anyone to suggest such an obvious improvement, it’s that this way of programming is massively simpler and far less error-prone, especially in a language like C (which Blender is mostly written in).
There aren’t really that many functions in Blender where this becomes a problem - the subdivision modifier is one, because every level quadruples the face count. There is a “safety limit” at 6 levels, but even that can be far too much if your input mesh is dense. What you need to do is learn about these pitfalls and not do stuff like dragging the subdivision level around.
The concept of a warning is a nice, but the implementation should be diffrent from a warning, maybe it should have multiple ways.
For example
“You are about to perform a very Heavy Task in Blender, And it can crash”
Continue with Task
Abort Task
Switch to Multi Thread Task Loading (Other Application can behave weird or Crash)
And it should ALWAYS save the file as a recovery in case blender can not call “m_alloc” , which will crash it.
m_alloc Memory Allocation -> Blender Crashes when the RAM is full
Or accually it could calculate an approximate amount of RAM needed, and if not suffiecent go
Continue with Task (Will crash if RAM is not enough)
*3) Switch to Multi Thread Task Loading (Doesnt change the RAM issue)
Well how do you determine that you’re performing a heavy task? In some cases, it might be simple to guess. However, it is not simple to guess that you’re going to run out of physical memory (the operating system deals with that) somewhere in the process, nor is it always possible to compute the memory requirements in advance.
Also consider the case were you change some value way up in the modifier stack that ends up causing lots of computations somewhere below. The program can’t locally predict this is going to happen from the place you made the change.
In your case, the problem was that you fired off a large amount of tasks by dragging a slider. Those individually weren’t necessarily heavy, but it added up. Blender can’t simply determine you didn’t really want all those tasks fired off.
Fixing this really isn’t so easy, or else it would have already been done.
This is very unlikely to happen on a 64-bit build. What happens instead is that your OS is going to start paging out to disk (which will make your entire system run very slow). Users just have to watch their memory usage. RAM doesn’t even seem to be the problem in the thread authors’ case.
Safety warnings are nice and all, but investing the developer time to install airbags in every feature that could potentially crash blender seems like a waste of time.
There’s a reason that ‘real’ scissors don’t look like this:
Frankly, (no offense) this is a case of user error. One where, hopefully, the user learned to be more careful about dragging sliders in the middle of fat modifier stack. If, instead of learning, the user decides that blender is broken and it needs features to prevent this from happening, I don’t hold out much hope for that user advancing very far in that software.
Firstly, it’s hard enough getting the developers to treat the users like adults without giving them further excuse to wrap us in cotton wool. How can we argue that users are smart enough to set their own object wireframe colours if we need to be warned every time we bump settings up to their maximum values? Especially when we’re stacking multiple operators together? I don’t think we can.
Secondly, it is not something that can be easily done, at least at the moment. Not every modifier is “interruptible” like baking. To implement what you want, all operators, modifiers, etc would need to be made interruptible and/or thread safe. HUGE task that. Not going to add much benefit for the time/resources needed to be spent implementing it (though it would have some other benefits, I don’t think they’re on the BFI priority list).
Thirdly, what modifiers / operators do we do this for? What combinations? Is there a way to turn it off and, if so, is it modifer-by-modifier or an all-or-nothing flag? The issue you had was in changing a property, so what happens when you want to change three properties - do they all get warnings? It’s not as simple as just sticking a modal warning before running the setting - it would need to be an integral part of the code flow whenever adding a modifier to the stack or changing properties on it. I think it is not worth the coding & user grief.
