long preparation time for DR

[klex167]

I have another one:

To speed up the rendering of long animations I'm using Distributed Rendering (1 workstation and 4 slaves).
Unfortunately do the slaves have an extremely long preparation time. In EVERY single frame. I give you 2 examples.

Example 1 (complex scene with many textures):
Rendering with just 1 workstation takes 10 minutes for one frame.
Rendering with 1 workstation + 4 slaves takes 9 minutes per frame because all slaves start to render after 8 minutes.
So my benefit is just 1 minute!

Example 2 (simple scene with alot of instances but just a few textures):
Rendering with just 1 workstation takes 1 minute for one frame.
Rendering with 1 workstation + 4 slaves takes 1 minutes because no slave starts.
Rendering with just the 4 slaves takes 10 minutes because all the slaves start after 9 minutes.
No benefit at all!

So high quality pictures with high resolution have a great benefit of using DR but in animations I'm very disapointed about the speed.
It's not about the network speed.

The only thing I found out: if you use the cloner or the subdivision with high values it takes forever .. but just the slaves NOT the workstation.

Please help. Do you need an example scene?

Best klex.

[sirio76]

Can you define what is a complex scene? I ask because definition of complex may vary wildly depending on the user ideally provide a scene, otherwise indicate the number of object, polygons, instance/render instance, displacement, texture size ecc, the more info the better. Then you should also indicate the specs of your workstation and slaves and the network speed.

[klex167]

I tested a lot and here I have an example scene for you.
There is a detailed object that is deformed by a displace-deformer that has a linear field.
If the linear filed is animated and moving through the scene the problem occurs.

Following you see the preparation time + rendering time:

1) WITHOUT animated modificators:

> workstation
1st frame: 4 sec + 7 sec
2 - n frames: 0 sec + 7 sec

>slave
1st frame: 60 sec + 14 sec
2 - n frames: 0 sec + 14 sec

2) WITH animated modificators:

> workstation
1st frame: 4 sec + 7 sec
2 - n frames: 0 sec + 7 sec

> slave
1st frame: 60 sec + 14 sec
2 - n frames: 40 sec + 14 sec

So for the workstation it is not important if the field is animated or not.
BUT the slave is preparing in every frame if its animated and its NOT preparing if its static.

Do you understand this? Is this as expected?

ps.: hardware:
workstation > Intel Xeon Silver 4114 2.2 Ghz, (96 GB DDR4) NVIDIA Quadro P2000
slave > Intel Xeon E5-2630 2.2 GHZ, (64 GB DDR4)

[aleksandar.kasabov]

Hello klex167,

It is expected to have longer preparation times when using DR as all data needs to be sent to and received by the slave. This time depends on multiple factors, such as the number of slaves, the bandwidth of your network, the size of the scene, etc. It is also expected for the first frame to take more time to prepare as it will send all settings and non-animated geometry. Each following frame will only send the changes (settings, animated geometry, etc). This is why it needs more time when the linear field is animated in comparison to when it is static.

[klex167]

Thank you Aleksandar,

I understand that the preparation time depends on different factors.
But I still wonder why the workstation needs NO preparation time from the 2nd frame on while the slaves still calculate every frame like the first?
That means DR is not helping at all. The scene size from my example is 457 kb so not a big thing.

The rendering time is very important for long animations and decreasing the quality too much is not what I want. Is there no way of improving this?

Best - klex

[aleksandar.kasabov]

Hello klex167,

The slave needs to receive the changes in the geometry, which in your case takes a while as the animated geometry is also subdivided and there are many changes. As mentioned in my previous post, the preparation time (the time to send and receive all the data for the animated geometry) depends on the bandwidth of your network.