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.

[Ondra]

what do you mean? you mean submitting a job with DR active to backburner does not work? That AFAIK does not work also in 1.0, nothing should have changed there

[fobus]

You're right. I forgot that it hasn't work earlier too.

...and because of this everyone who wants to render more than one frame has to have one full licensed PC just for rendering purposes (as he can't send a job to backburner).

[Frood]

Could you clarify that a little bit? Basically what you would like to achieve is a sort of "clustering" of slaves in Backburner like it is possible e.g. with mental ray and it´s satellites? So that a single BB job (1 frame) uses not only one slave but multiple ones?

In that case I don´t understand why you wrote "[...] who wants to render more than one frame [...]". Because even if you have to render 1 single frame you can´t use all slaves by submitting it to BB. You have to render it locally. But consider Render Setup -> coronaRenderer -> Performance Settings -> # of threads (=cores to use). Set this to [your_core_count]-1 and let the frame(s) render with all slaves included. You can still work at your box and if RAM isn´t the issue you will not even notice.

[fobus]

Hm... You're right. Even one frame needs a workstation to be rendered distributively. Of course you can render parallel with work on youre own PC, but when scene rendere with lot of RAM it is ineffective.

[Ondra]

AFAIK the NYX DBR can help here... I recommend checking it out to see if it can help you (and you get discount for it with corona purchase ;))

[fobus]

AFAIK the NYX DBR can help here... I recommend checking it out to see if it can help you (and you get discount for it with corona purchase ;))

I think it will be much better to just have a fully working feature in Corona, than buying another tool for DR. Is this really that hard to implement DR support fro backburner jobs?

[Ondra]

I mean... this is the solution you can use today. Additional tweaks for Corona DR will take time

[fflasshh]

I just scrolled trough the topic. I've been testing version 1.0 with max 2014, and DR worked fine with animation. I used corona's own DR manager. I have one workstation, and one render slave. Each frame took about 10 mins to render with both computers rendering the same frame. I didn't tried backburner yet, but the default DR of corona worked well in my case. There were no moving objects in the scene, only the camera.

[Frood]

I mean... this is the solution you can use today. Additional tweaks for Corona DR will take time

Did you for sure changed drserver in the latest hotfix version only regarding the frames-to-render bug? Or is it additionally a kind of experimental build? Just a discreet question.

[Ondra]

only that. It seems to be stable, and will be probably released as next stable build

[Frood]

While strange things happened here using BB I checked the logs and was surprised, hence the question. So please: what is the intended behaviour for the following situation right now:

- create some Scene
- add (ready to render) slaves to DR
- tick "Enable"
- submit that job to Backburner to one of the slaves

Is the local Max instance on the one slave(!) who renders the scene via BB(!) supposed to use the other slaves via CoronaDR or not?

Thanks!

[fflasshh]

Strange thing happened to me also, I mixed the two rendering solutions. But I figured out what the problem was... So If you use Backburner, "Distributed redering" shouldn't be enabled in the corona render settings. Because if you do so, a slave gets the job (one frame) from backburner, with the settings that it should use distributed rendering. this way frames get mixed.
So use eihter Backburner (to render more frames, and one frame per slave), or the built in CoronaDR (to render one or more frames, with rendering all the slaves the same frame, the same time).

[Frood]

fflasshh, regarding your mixed up frames see this thread, there is a hotfix for DrServer. I encountered mixed up frames only when using DR and selecting frames (not a range) to render but give it a try.

The question to Ondra is: Should it work like described in my post (one BB-Job includes other slaves defined in the file) or not. At least for pre 1.0 Corona builds (before slaves got saved into the scene, could be also Alpha 6, can´t remember exactly right now) this was (of course) not possible at all and as far as I can remember it still isn´t intended to work like this. One reason is a legal one, not technical. I hope Ondra can clarify (some day :).

Good luck!