Fusion 5.1 Feature Request

I’m hoping that i might be possible to either add the ability to supply additional arguments to or have added into the current list of arguments the “/log {filename}” argument for the fusion console slave.



I’ve been trying to trouble shoot issues with our renderer’s and I recently discovered this feature which has shed a WHOLE lot of light on some of the problems we are having.



Cheers

Shane

Hi Shane,



Do you know if more gets printed out to the log file than is printed out to the console? I guess either way, it would help in the case of using RenderSlave.exe instead of ConsoleSlave.exe.



What we could do is modify the plugin to add the “/log {filename}” argument, and then append the log to the slave log when the task completes or errors out. We’ll log this as a feature request.



Cheers,

  • Ryan

Hi Shane,



I just ran a test, and any information that would be saved to the log is

also printed to the slave log. Could you not just use these logs for

debugging, rather than adding the /log switch to the Deadline renders?



Cheers,

Sorry of the late reply, been debugging fusion.



I was generally unaware that the logs were actually the same, if they are, then that’s fine.



In fact, where I want more information, none is normally given (when the actual render occurs…:P)



I was also curious over the choice to use eyeonscript to talk to the slave, especially when the slave is…killed off…at the end of the render??



I’ve been mucking around with the command line console slave to test why some of our systems won’t render and it does it all quite nicely…it starts, loads the comp, renders and then quites cleanly…



The only reason I can see to leave it running (in listen mode) is if you aren’t going to kill it off…and I’m sure there’s a reason we do, but that’s probably us clutching at straws for a solution to our woes…



Cheers

Shane

The benefit of using eyeonscript to talk to the fusion slave is that we

can keep the composition loaded in memory between tasks for the same

job. This reduces the overhead of starting up fusion for every single

task, which would be the case when using the command line method of

rendering. Another benefit is that we can set additional settings like

High Quality and Proxy, which aren’t available from the command line.

The reason the fusion slave is killed off at the end of each job is so

that it isn’t running when Deadline goes to start another job

(especially if that next job isn’t a fusion job). When Deadline

eventually picks up another fusion job, the fusion slave just gets

started up again.



The latest version of Deadline does support using the command line

method of rendering. You just have to configure the Fusion5 plugin from

the Monitor to enable it. In Deadline 3.0, there will actually be two

separate plugins (Fusion and FusionCmd), and which plugin you use can be

chosen on submission.



Cheers,

Hay thanks for the info! Really helpful. Don’t get me wrong, I really like the way you guys plug into fusion via eyeonscript, really neat. I was curious :slight_smile:



Shane

Hi Ryan, back again!



It would seem that we are running into a small problem with the timeout values of our fusion jobs.



We have some older x32 machines which are taking up a little of the slack allowing our x64 machines to be prioritized to 3d rendering.



The main issue we are having right now is that the x32 machines, been a lot slower then the x64 machines, are exceeding the default timeout (which the compositors see fit to set to 10 mins…and in perfect world, this would be okay).



What I’d like to be able to do is change the timeout value for these specific machines ONLY. So that when the x64 machines pick up the fusion job, they still have the default timeout, but the x32 machines get more time to render.



I’ve tried playing around with the “Normalized Render Time Multiplier” but this does not seem to have any effect, the machines continue to timeout after the default time.



Also…the “render.log” does not seem to contain the same information as the “/log {filename}” option…this is the information written to the fusion render slave folder yes??



Shane

Hi Shane,



I think it would make sense to have the normalized render time play a

factor when determining timeouts. We’ve added this as a feature request.



With regards to the log, I was referring to the logs you can view by

right-clicking on the job in the monitor and selecting Job Reports ->

View Log Reports. These logs contain the stdout which was printed out by

the console slave, which is the same as what would have been printed to

the log when using the /log switch.



Cheers,

Ah, thanks for the clarity Ryan, always nice be to be on the same page :wink:



Shane