I notice that the progress value is wrong when submitting a stereo job.
Lets say I have a 100 frames with a stereo cam (so 100 frames for left eye and 100 for right eye cam),
the progress indicates 100% when 50 frames are rendered for both cameras.
so deadline considers that 1 frame for left and 1 frame for right is actually 2 frames rendered instead of 1 .
It could be OK if the progress value would go beyond 100% (as a workaround), but its not the case.
So we are stucked to 100% (in the progress column) after actuel 50% is really rendered.
Is there a function to access and modify this value (and trick deadline) after job submission ?
Which software are you rendering with? We probably just need to adjust our progress handler for that application, so knowing which application it is would be a good start.
Also, if you could send us a very simple test scene that reproduces the problem, that would be great!
we re using 3.1 sp1, Maya2009 x64 on Win64, and MayaCmd (since MayaBatch plugin doesnt seam to authorize Command line extra commands)
I am gonna prepare a small Maya scene to render
Cheers
Thanks! We found that when rendering with a stereo camera, Mental Ray will print out the following after each frame is rendered:
So what we’ve done is add a stdout handler to watch for these lines, and more specifically, the frame number mentioned. If an output image is for the same frame as a previous image, the current image isn’t added to the finished frame count, and thus the progress is more accurate. This seems to work pretty well, so we’ll include this fix in the Deadline 4.0 release due out in January.
thx for the reply.
We tested it today but still result is not right.
Do we have to stop deadline to apply the changes with new files (We supposed that was not necessary) ?
Cheers
Do you jobs have more than 1 task for frame? This will only work if there is more than 1 task per frame, because we use the first indication that frame X completed when we update the progress, which is kind of necessary because we don’t know how many times maya will render that frame.
This isn’t perfect, but because maya doesn’t explicitly output the fact that it’s rendering a stereo camera, this is really the only solution without adding a flag that the user needs to enable to tell Deadline that it should look for stereo stdout.
Not sure of what you means by “more than 1 task per frame”
We have to render a stereoL cam and a stereoR cam for each frame (so I guess its 2 tasks per frame)
What I noticed after applying the patch is that the progress is still wrong
if we render , let say , frame 1-200 (for test purpose) on a render node,
when the progress indicates 50% done , there are in fact 52 images left and 52 images right written on disk (instead of 100 for exach eye)
When you submit a job to Deadline, you can specify the Frames Per Task (Task Size) beneath the Frame List. Sorry, I probably should have worded this better.
Hmm, maybe mental ray isn’t printing out the progress we’re expecting then. Can you run another test (frames 1-200, all part of one task), and send us the FULL render log for that test? We can parse the log and try to figure out what we’re parsing wrong.
Where did you notice this? Was it in the Monitor, or in the Slave on the machine that was rendering the job? The reason I ask is that the progress shown in the Monitor for a task isn’t in real time. It’s only updated periodically, so it is very possible that it could fall behind by a few frames. When rendering stereo camera jobs, the Slave application always appears to show the correct progress (well, as correct as it can be - we’ve already covered why it can’t be 100% accurate without explicitly telling Deadline that it’s rendering a stereo job).
Yes I was checking in the monitor.
But before comparing between what the monitor progress bar says and what i really got in my image folder, i always do a “refresh job” and check immediately after my folder (when rendering a non-stereo job , this refresh gives the almost exact result).
As long as it was fast rendered image for the test, i was expecting some differences between progress bar and rendered images (lets says less then 10 images) but not the half complete job (100 frames).
We were able to reproduce the problem with a larger test case. There was a bug in the regular expression we were using that only affected the progress on tasks that had more than 10 tasks. We’ve fixed the issue, and it appears that Deadline calculates the progress correctly for a 200 frame task. I’ve uploaded the new patch here so you can test it out. Installation instructions are the same as before. Let us know if you get better results with this patch.
