How to render in Blender without slowing down the other programs

During the image rendering in Blender, it is impossible to do anything else, the computer is strong “brakes”. Blender takes all available computing power without leaving almost nothing to other applications.

In order to run render in Blender with a low priority, so that it does not fill the entire computer and is guaranteed not to slow down the other programs work, you need:

  • Switch the render mode to the CPU
  • Run the render in Blender from the command line:

Windows:

parameters used :

  • /LOW – means that Blender will be launched with the lowest priority, computing power will be allocated to it after the all other programs.
  • /MIN – the window will be minimized in the taskbar.
  • /B – no separate window for launching Blender.
  • /D _path_to_blender_directory_ – here you need to specify the path to the directory where Blender is installed. Since usually all programs are installed in the “Program Files” or “Program Files (x86)” directories (there are spaces in the directory name), you need to enclose it in quotation marks.
  • _full_path_to_blender_ – specify here the full path to the blender.exe file. Enclose it in quotation marks by the same rules.
  • -b – Blender background launch (no graphical interface is created).
  • _path_to_blend_file_ – the full path to the project you need to render. If there are spaces in the path, it must also be enclosed in quotation marks.
  • -f X – instead of X, you need to specify the number of the frame you need to render.
  • -t X1 – instead of X1 you need to specify the number of processor cores that would be allocated for rendering. It is worth to allocate the half of the available cores.

Example:

 

Linux:

used parameters:

  • -n 20 – means that Blender will be launched with the lowest priority, computing power will be allocated to it after the all other programs.
  • -b – Blender background launch (no graphical interface is created).
  • _path_to_blend_file_ – the full path to the project you need to render.
  • -f X – instead of X, you need to specify the number of the frame you need to render.
  • -t X1 – instead of X1 you need to specify the number of processor cores that would be allocated for rendering. It is worth to allocate the half of the available cores.

Example:

 

BIS add-on v.1.1.0

BIS (Blender Interplanety Storage) add-on update to v.1.1.0.

  • Previews autogeneration for procedural materials added. After a while, if the user has not uploaded his own material preview, it will be generated automatically.

The generated preview looks like this:

The update only applies to the server side of the add-on. You do not need to reinstall or update the installed add-on in Blender.

For the correct preview autogeneration, the saved node group must be fully procedural (without using textures, textures are not stored on the server) and have an output named “Shader” or “BSDF” for shader node groups or “Color” or “Factor” for color node groups. The “Displacement” output, if it is in the node group, is also used. To have proper texture coordinates on the preview, the node group must have a “Vector” input.

How to programmatically check if the operator is registered in Blender API

Single add-on or script can contain several different operators, and not all of them may be registered in the API by the register() function. To verify that the required operator is registered in the Blender API, run the following command:

Where:

_operator_bl_idname_ – the text value of the bl_idname operator property.

For example for an operator:

the command will look like this:

 

How to programmatically check if the Blender add-on is registered

To start working every Blender add-on must be registered by setting up the checkbox before add-on name in the User Preferences window – Add-ons page.

To programmatically find out if the required add-on is registered, run the following command:

Where:

add-on_name – the name of the add-on file (without the .py extension) or the name of the add-on package, if it was installed from the package.

Debugging multifile Blender add-on by quick reinstall

It is convenient to use the following system for debugging developing multi-file Blender add-ons. But it has one drawback: modules imported in __init__.py file becomes available only after the file running (after the execution of the register() function). This means that any access to the imported modules before they are registered will cause an error. This is not critical in most cases, but it will cause a problem if, for example, in one imported module is used inheritance from the class, described in the other imported module, because the classes descriptions are processed before the add-on registration.

To get more freedom working with imported modules, we can use another way to debug the add-on – do not run the add-on directly from the development directory, but install it in Blender and check its “live” work. However, manual add-on reinstallation requires a set of routine actions, which complicates such sort of debugging. This issue can be solved by reinstalling the add-on in automatic mode.