Commit cb2b4deb authored by Alan Taylor's avatar Alan Taylor

terminology usage, missed from earlier commit pt.2

parent 184da5e3
......@@ -9,7 +9,7 @@ It is free and [Open Source](https://opensource.org/definition) software, and is
## It will:
* distribute your Blender file, textures and library Blender files to all the render nodes you specify
* calculate the best number of tiles to split your image into
* calculate the best number of blocks to split your image into
* manage rendering the blocks on the remote nodes, and collect them as they complete
* stitch all the blocks together to form the final image
* restart cleanly after being interrupted, without losing any completed blocks
......@@ -174,7 +174,7 @@ render@rpi:~/dtr-master-5a53b19f43cbd859088431753944eb1ca0f42b58 $ ./dtr.py
>> checking if render nodes are responsive
>> benchmarking
using cached benchmarks for all nodes
2048 * 2048, frame 1 with seed 0 is split into 30 tiles, arranged as 5 * 6 distributed over 3 nodes
2048 * 2048, frame 1 with seed 0 is split into 30 blocks, arranged as 5 * 6 distributed over 3 nodes
>> rendering
tile 0 issued to node 127.0.0.1
tile 1 issued to node 192.168.0.128
......@@ -241,7 +241,7 @@ tile 29 retrieved from 192.168.0.129
>> tidying up
>> finished
node tiles mean duration
node blocks mean duration
192.168.0.129 26 0:00:17
127.0.0.1 3 0:02:18
192.168.0.128 1 0:04:14
......@@ -371,7 +371,7 @@ tile 0 retrieved from 127.0.0.1
>> tidying up
>> finished
node tiles mean duration
node blocks mean duration
127.0.0.1 1 2:03:41
total time
......@@ -443,7 +443,7 @@ A solution that works more efficiently for GPU rendering is in progress, noting
### (2) Benchmarking
`bench.blend` should be relatively quick to render, but reflective of the general complexity of typical final renders. It is used to get a rough idea of the relative performance of the remote nodes, so we can estimate the number of tiles to split the image into. This allows us to efficiently render the image without nodes sitting around idle at the end for too long. Remember to set the number of threads to automatic.
`bench.blend` should be relatively quick to render, but reflective of the general complexity of typical final renders. It is used to get a rough idea of the relative performance of the remote nodes, so we can estimate the number of blocks to split the image into. This allows us to efficiently render the image without nodes sitting around idle at the end for too long. Remember to set the number of threads to automatic.
If in doubt, just use the provided `bench.blend`.
......@@ -455,7 +455,7 @@ If you don't want to restart after an interrupted render, start up the script wi
If you want to force the script to run the benchmarks again, start up the script with the `--flush` option, this will delete the benchmark cache. Type: `dtr.py --flush`.
Note that the use of `--flush` implies `--clean`; if a decision has been made to flush the cache, it makes sense to discard any previously rendered tiles.
Note that the use of `--flush` implies `--clean`; if a decision has been made to flush the cache, it makes sense to discard any previously rendered blocks.
### (5) Noise
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment