Before I bought Deadline I only knew RenderPal which was nice too, but made me too much trouble with Lightwave. Deadline is more cooperative here.
But what I don´t like is the feedback: I can´t see the progress. It is 0%, or it is 100%. Nothing in between. Is there a setting somewhere to get a more detailed feedback here? Also the RAM and CPU usage is shown much better in RenderPal. I would love to see that in Deadline too, especially when I have the additional licenses to start the other nodes.
With a render time of more than 1 hour per frame progress should be clearly over 50%, but Deadline tells me something like 0%. Not nice:
Thanks for reporting this progress problem! I checked our Lightwave plugin, and we would only calculate progress when a pass or frame finished. So if had a scene with one pass, and you were rendering one frame per task, you would never get any progress info.
I ran a command line Lightwave render, and found it printed “Image Reconstruction %” message during the rendering of each pass so we used this to add better progress handling. This will be included in Deadline 5.2, but I’ve uploaded the updated plugin file here if you want to use it now. Just note that it has only been tested against Deadline 5.1.
To apply the patch, go to \your\repository\plugins\Lightwave, and first make a backup of Lightwave.py (just in case). Then unzip the attached file to the same folder. Submit a new job, and let us know if you start to see progress being reported.
We haven’t seen how it’s shown in RenderPal. I’m guessing it’s live too? Currently, we only store this information for a task after it has finished, but we are looking at ways to address this. For now, you can see the cpu/memory usage of the slave that’s rendering it by finding that slave in the slave list (there is a right-click task option to auto-select the slave). The slave list has CPU and Memory usage columns you can view.
I had some network problems so I´ve had to restart all machines. I did what you described, but still it doesn´t work as expected:
Thougt it might be because Pulse wasn´t running, so started it, but can´t make it connect to the slaves. Still searching the Documentation for a solution.
After a task for one of your jobs completes, right-click on it and select Task Reports -> View Log Reports. Then right-click on the log item in the upper list and save it to disk, and then upload it here. We’ll take a look at Lightwave’s output to try and figure out what the problem is.
Thanks! The log shows the Image Reconstruction part that we are now capturing, so I’m surprised that you aren’t seeing any progress info. Can you check one of the Slave windows on a render node to see if the Progress and Status fields are showing proper progress during the Image Reconstruction phase? Maybe it’s working, but something is preventing that information from making it to the Monitor.
I copied the status of one node and attached the .txt-file. But now I´d like to say: See you Monday, it´s WEEEEEEEEEEEEEEKEND time (and I´m going to an Amiga-Meeting with my Atari 800 XL ). node02_rendertask_lw_progress.txt (98 KB)
I just watched one of the slaves and realised, that they don´t give much information while rendering. The image reconstruction is only the last part of rendering and goes from 0% to 100% in not more than a second. I actually saw the Monitor showing “99%” once. So basically it works, but its meaningless, as I want to get a feedback of the rendering status.
That’s interesting. In the tests I did, that Image Reconstruction didn’t kick in until about half-way through the render, but it definitely made up more than 50% of the overall render time. I guess it’s based on the type of scene you’re rendering…
I took another look at the first log you posted, and I really don’t know what else we should go off of for progress. There are a whole bunch of loading, preparing, and moving lines, but none indicate any sort of overall progress. Currently, the only useful info regarding progress is the “Rendering frame 425, segment 1/1, pass 1/1” lines and the Image Reconstruction lines, and we’re already handling those…
"You can start a render job in mode 3 (disable the ScreamerNet mode in the job submission or properties panel within Deadline), for which the -t switch to LWSN gives a percentage readout that could be scraped for display. That’s the only way that I think any controller could give a percentage readout of task completion. However, DL doesn’t start LWSN with this switch and so won’t have anything to scrape in that mode.
In mode III, you need to consider that DL restarts the LWSN process at the end of each bucket of tasks that the nodes get assigned. The size of this bucket is configurable in the submission dialog (and is described in the documentation)."
Very interesting! We’ll play with the -t argument and see what it prints out.
It’s too bad that it will only work in mode 3. The benefit to mode 2 (screamernet mode) is that Deadline can keep Lightwave and the scene file loaded in memory between frames, which eliminates a lot of overhead.
We’ll let you know when we have something working.
Seems to work quite well! Here’s an updated Lightwave plugin file that uses the -t argument in non-screamernet renders to report progress. Install it the same way as before. Let me know if it works for you.
I was stupid again. I ahd set it to 00:05:00 thinking it´s minutes:seconds:milliseconds as with some other software I use much. Now everything is fine.
I was just wondering if this is still the case or not in deadline. I ran lwsn the other day with the -help flag to see if there was -t support in mode 2 and it appears there is a flag for it. Any chance there might be an update that fixes this problem? (Currently running deadline 5.2)
No, the -t switch changes function between mode II and mode III. In mode II, since you’re asking the controller for information about the task (including whether it’s been cancelled, etc.), the -t switch defines how often that check occurs. In mode III, there’s no need to talk to a controller - the job is defined and run locally, so the -t switch changes to define how often a status message is printed to the console.
