Render Slaves Scene stuck at first frame

[-Ben-Battler-]

Hi

I am testing Version 1.0.

We are rendering a Movie of a Truck turning slowly around its roll axis and we are using DR.

The problem is that the Master Workstation is updating the scene correctly while the Render Slaves stuck at the situation of the first frame. So as soon as they contribute to the rendering, the truck's old perspective of the old frame is being merged into the new perspective of the actual frame.

The attached images will bring clarity.

With V7 this wasn't the case, we just updated all Workstations to Version 1.0. We only changed the Secondary Solver from HDCache to UHDCache.

BR Ben

[Ludvik Koutny]

I know this is not solution for your problem, but you should never use DR for animation. It's slower, a lot more prone to problems, and generally pointless. Just set up some render manager (backburner, which is shipped with 3ds Max for free or deadline) and let each computer render different frame.

Also, in case you are using batch render, DR does not support batch render.

[maru]

With V7 this wasn't the case, we just updated all Workstations to Version 1.0. We only changed the Secondary Solver from HDCache to UHDCache.

Stupid question: did you also install 1.0 on nodes?

[fobus]

I know this is not solution for your problem, but you should never use DR for animation. It's slower, a lot more prone to problems, and generally pointless. Just set up some render manager (backburner, which is shipped with 3ds Max for free or deadline) and let each computer render different frame.

Also, in case you are using batch render, DR does not support batch render.

So what if we have 5 frames (stills) with animated camera and 10 PCs to render it. We have to use only half of rendering power? With VRay, for example, we can send this job to backburner with DR on and use all PCs to render it twice as fast. As DR is have no support of batch render it seems to have no support backburner suport as well. I think this is a very bad news. I thought that we can use this feature at last in 1.0.

[-Ben-Battler-]

Stupid question: did you also install 1.0 on nodes?

Yes I did, otherwise the slaves are not connecting to the master.

I know this is not solution for your problem, but you should never use DR for animation. It's slower, a lot more prone to problems, and generally pointless. Just set up some render manager (backburner, which is shipped with 3ds Max for free or deadline) and let each computer render different frame.

Also, in case you are using batch render, DR does not support batch render.

Thanks for your answer. Exactly, I didn't want to hear this answer but I will consider it.

Since in VRay DR render for sequences worked like a charm, I was assuming that it would work in Corona too (which it did in V7).

PS: I now made the test without switching to UHDCache but the situation is the same.

[Ludvik Koutny]

I know this is not solution for your problem, but you should never use DR for animation. It's slower, a lot more prone to problems, and generally pointless. Just set up some render manager (backburner, which is shipped with 3ds Max for free or deadline) and let each computer render different frame.

Also, in case you are using batch render, DR does not support batch render.

So what if we have 5 frames (stills) with animated camera and 10 PCs to render it. We have to use only half of rendering power? With VRay, for example, we can send this job to backburner with DR on and use all PCs to render it twice as fast. As DR is have no support of batch render it seems to have no support backburner suport as well. I think this is a very bad news. I thought that we can use this feature at last in 1.0.

Then those are 5 still frames, not an animation. Obviously he was talking about animation of truck turning around.

[fobus]

But the problem remains. Animation or stills in frames, no matter. The problem is still there. It will be very good to have one solution for it.

[Ludvik Koutny]

But the problem remains. Animation or stills in frames, no matter. The problem is still there. It will be very good to have one solution for it.

I never said it should not be resolved. DR should work rock solid in all cases. But that doesn't change anything about fact that using rendering manager for animation will be always faster, easier, and LOT more stable.

[fobus]

I never said it should not be resolved. DR should work rock solid in all cases. But that doesn't change anything about fact that using rendering manager for animation will be always faster, easier, and LOT more stable.

Sure. So is it a bug? Will it be in plans in near future to resolve it?

[Ludvik Koutny]

I never said it should not be resolved. DR should work rock solid in all cases. But that doesn't change anything about fact that using rendering manager for animation will be always faster, easier, and LOT more stable.

Sure. So is it a bug? Will it be in plans in near future to resolve it?

Definitely. Although it may be the known one, if Ben uses batch rendering. Batch rendering does exactly this. But if he does not use batch rendering, then it's probably a new bug. Anyway, in both cases it should definitely be fixed.

[Frood]

 fobus, you´ve got the point here:

"So what if we have 5 frames (stills) with animated camera and 10 PCs to render it."

Additionally it´s about having control about the rendering result while still having benefit of multiple machine power. This is our general workflow for quick projects. Fyi:

https://corona-renderer.com/bugs/view.php?id=776

I don´t believe it´s very hard to fix but i´m waiting already quite a while for a fix (the first bugtrack entry for that bug was closed as "fixed", submission date was  2014-03-12).

[fobus]

Fixed? In 1.0 it's still there. May be they fixed somthing else. I have no access to Mantis, sorry.

[Frood]

It´s more "again" than a "still" there :) I´m confident it will be addressed soon.

[Ondra]

Fixed (hopefully... please test ;)) - see the folder "2015-03-09 DR server" here https://www.dropbox.com/sh/mswauuv1afec8am/AAA5OKrd_QujokDM3mxQ7S40a - just replace the executable on your render nodes

[fobus]

Not working DR anymore with this fix. All nodes are marked "FAILED". DR on slaves is continuously trying to start, but couldn't start it.
May it be because I just replaced executable of 1.00.00 DR with this experimental?

UPD:
Just found that DR not working with backburner at all.