7
$\begingroup$

Occasionally I end up using a metaball. If I scale the main metaball, it changes the resolution. The smaller it gets, the high resolution it becomes. If you press S to make it bigger and you accidentally go in the wrong direction to make it smaller, it takes about an hour to bake the increased resolution.

Another case is when I use the Remesh modifier. I slowly increase the octaves and then accidentally push it up to 10 or 11. Then blender freezes, and crashes.

Is there a way to prevent blender from doing long computer freezing calculations unless I permit it to?

$\endgroup$
  • 1
    $\begingroup$ Good question! Technically it should be possible to implement such a feature (similar to the "unresponsive script" warning in Firefox), although I don't think that it is implemented. $\endgroup$ – lbalazscs Jan 6 '17 at 14:38
  • 1
    $\begingroup$ More a suggestion than a full answer as I don't know what specific cases it will and won't work with, but if the console window is open and you press Ctrl+C you can sometimes abort whatever Blender is doing during complex tasks. $\endgroup$ – Timaroberts Jan 6 '17 at 20:36
2
$\begingroup$

Not in the way you are thinking

This is one of those "Computer Science Traps" that sound easy on paper but are actually impossible for computers to solve. The specific problem at work is the "Halting Problem". The gist of the issue:

the Halting problem is the problem of determining, from a description of an arbitrary computer program and an input, whether the program will finish running or continue to run forever....Alan Turing proved in 1936 that a general algorithm to solve the halting problem for all possible program-input pairs cannot exist.

There are ways to cheat, however. Firefox, as mentioned above, cheats by putting time-limits ("timeouts") on operations. Blender does not have this luxury, because, as you said:

it takes about an hour to bake the increased resolution.

Which, as annoying as it sounds, is still legitimate.

The ways around this to make sure you can see the render/bake output, and check in occasionally. If you suspect that your machine has bitten off more than you can chew, you can usually escape the process by mashing esc

$\endgroup$
  • $\begingroup$ Good tip with escape. I didn't know you could do that... However, I doubt that it will work while blender is freezing up. $\endgroup$ – 10 Replies Jan 6 '17 at 20:18
  • $\begingroup$ I understand how conceptually the halting problem is relevant, but, since all blenders operations are finite, I don't quite see how that is relevant. There could be some sort of checker program to see if blender will loop more than 100 thousand times or something. $\endgroup$ – 10 Replies Jan 6 '17 at 20:20
  • $\begingroup$ How can you know that you are going to loop 100 thousand times without looping 100 thousand times? $\endgroup$ – Kirbinator Jan 6 '17 at 23:03
  • $\begingroup$ Each action you make in blender is finite, for the sake of simplicity we will limit to the list of actions to modifiers. You can apply a subdivision modifier, and set the preview resolution to 300 (normal values are usually from 1 to 5). Before blender subdivides, it could look at the number of verts in your mesh and calculate how many loops it would take to bake. Then, blender could give you a warning message to tell you that you might not want to subdivide this far and give you an option to cancel rather than silently attempting to subdivide by 300. $\endgroup$ – 10 Replies Jan 7 '17 at 0:10
  • $\begingroup$ It's not a matter of letting Blender decide how much is too much. It should attempt to perform whatever it's told. How many times have I lost hours of work because of stupid mistakes... If all operations are indeed run in separate threads and cancellable, as they should, then it still needs to have some memory watchdog to pause threads before they request an amount of memory that's not available. If memory requests by underlying operations cannot be caught, I'm sure the API could be remodeled to centralize these on Blender itself. $\endgroup$ – ecv Dec 11 '18 at 16:58
2
$\begingroup$

This is a problem that lies deep in the architecture of the program and thus isn't that easy to solve.

When you are doing an operation, in any program, and the GUI of the program freezes during the calculation, this is a pretty good indicator that the calculation has been done on the rendering thread. This is easy to implement and works well as long as the calculation returns in a small enough amount of time.

The better way is to start any calculations in a new Thread. If it is done so, the GUI thread can "monitor" the calculation thread and eventually kill it if it takes too long. Blender does this for rendering, baking, compositing and some more: Their progress is shown at the top with an icon to stop the action.

But it is way harder to set up in code. You need to:

  • Start a new Thread and assign its task
  • Repeatedly ask the Thread its progress and show it to the user
  • This means that the Thread has to calculate its progress somehow
  • Eventually kill the process after timeout or on user interaction
  • Show results of the operation if there are any

The problem lies a bit deeper, in how rendering is done in a loop and how variables are stored, but it doesn't matter.

Also, most of the calculations are some Python scripts with their own API. I don't know how the scripts integrate into the code, but it's pretty sure that it makes things even more complicated.

So, yes, in theory, there is a way to make Blender handle long calculations well. But it hasn't been implemented (yet?) and would require a great amount of time the devs probably won't spend, sadly.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.