Add-on PartitionRender v.0.0.4 update.
- Compositing nodes for final image combining connected to a separate output Compositing node and removed each time partition render starts. That allows to re-render images without manual editing compositing nodes.
Add-on PartitionRender v.0.0.3 update.
- Added “Reset” and “Clear” buttons:
- “Reset” – resets the current partition to the first.
- “Clear” – reset with all saved partitions deletion.
- Checking the “Use Range” checkbox resets partition to the first.
Add-on PartitionRender v. 0.0.2 update.
- Added ability to render a limited partitions range.
- Fixed a bug with an unsaved *.blend-file. If the Blender file is not saved, all temporary files are stored in the system temporary directory.
Blender add-on allowing to interrupt the rendering process and resume it from the interrupted place. For those who are not able to have the powered-on computer for render for a long time.
For example, the whole image render takes 12 hours. And there is no way to have the computer powered on all the time, but it is possible to power it on for 5 hours with breaks. If you interrupt the standard rendering process to turn off the computer – the next time render starts from the beginning, and all progress is lost. PartitionRender add-on allows dividing the image into several blocks – partitions, each of them is rendered separately. Choosing division by X and Y in 2 parts, the image is divided into 4 blocks. Each of them will be rendered about 3 hours that fit in the time to work. Each partition after rendering saves to file. The next time (after rebooting the computer) PartitionRender automatically continues with the partition on which the break occurred. After finishing all partition renders, partitions automatically compile to the whole image in compositing.
Add-on is free and open-source. If you want to support it – you can buy the add-on for a convenient price, or set the price to 0 to download it for free.
To clear compositing window (completely remove all nodes from it), run the following code:
nodesField = bpy.context.scene.node_tree
for currentNode in nodesField.nodes:
In the development of add-ons, their modules should be abstracted as much as possible. For a very simple reason – functional, created for a current add-on, will likely need in the next add-on, and possibly not even in one. In the add-on release, the problem of accessing to such common functionality modules is easily solved – all the necessary modules are included in a single package and distributed together. However, during the add-ons development, such modules are much easier to store separately, in one instance, without associating them with any particular package, and import if necessary the desired modules to the desired add-on.
In accordance with the packages import rules, Python allows to refer modules in the following ways:
In the development of complex add-ons with large code volume storing all the code in a single file is inappropriate. When a single file contains logically unrelated classes, functions, and datasets, it is difficult to read, debug, find the necessary code pieces, reuse code. Such code layout is considered as very bad programming tone.
Blender Python supports modular system that allows subdividing logical code parts of the add-on into different files, and then connect them to use. Even if you have never thought about modules, creating scripts or add-ons, you have already used them – any code stored in the *.py file is a separate independent module. Just your addon consists of only one module. Complex add-ons may consist of several tens of modules.