AWS Thinkbox Discussion Forums

Deadline 9 and Krakatoa

We just started getting into Krakatoa in the last week and I want to start rendering on our render farm via deadline. However when I send a Krakatoa job via RP Manager to Deadline our multilayered exr does not save the passes and the file becomes corrupt saying there is an issue in the header of the file. However if we submit Krakatoa scene via RP Manager as a local render the EXR saves correctly. I have not sent a Krakatoa job to deadline yet without submitting via RP Manager. Any thoughts or suggestions to solve this issue?

We’re not certain of the cause yet either.

I’m curious if the error is from the EXR headers or not. KMX works differently than the others in that it tends to split the images out into distinct files…

Can you outline the workflow so we can test over here? Also, in the meantime, could you split out the channels and merge them some other way as a workaround?

Edwin,

With Krakatoa enabled as the “Renderer” we first load in all of the Render Passes in the Render Elements Section, but don’t choose an output path. We then go to the Main Render Output path, name the file and choose “open exr” and then go to setup

and choose “add” and select all Krakatoa Elements and choose ok. Now that is setup how we want it we load up RP Manager and submit to deadline .

PS: Let me know if you need something else. We like single EXR as they are easier to manager on the network and are a lot easier to use in After Effects since Creative Cloud.

Thanks,
Austin Reed

Edwin,

I submitted the test above and saved the Render Elements as individual files and those saved out perfectly fine. However the “exr” that was supposed to save all of the passes together as a single file still gives me this error Single_EXR_File_Error.png. When we render with Vray we can save a single “exr” file with all the render elements using the Vray Frame Buffer just fine. Is this a limitation of the Max VFB or something how Krakatoa render saves out the files?

Thanks,
Austin Reed

Hi Austin,

It seems to work ok with Krakatoa (and Scanline) when rendered locally, so we will have to dig deeper on our side to understand what happens when rendered on Deadline. At this point, I would not like to point fingers at Krakatoa, Deadline, or 3ds Max before we have more data.

Thanks for reporting and illustrating the problem, very much appreciated!

Bobo,

Deadline has saved us on so many accounts and appreciate your guys hard work. We will work with multi file solution until you and your team can figure out a fix.

Take care,
Austin Reed

Since your case had a few variables - Krakatoa MX, Krakatoa Render Elements, RPM, Deadline - I decided to try to simplify the test a bit.

So first I set up a Krakatoa MX with all available Render Elements (like you did), and added them all to the single EXR output.
Rendered locally, and they all ended up in the file as they should (as long as they had any data, some were empty, but still there)

Then I submitted this scene to Deadline directly without RPM, just using SMTD.
Rendering on Deadline produced a file which contained NONE of the elements. It had only RGBA, but the content was the data from the Krakatoa Z-Depth element instead. The file sizes were also 28KB for the Deadline render, and 131KB for the local render with all elements, so obviously a bad file was produced. However, it did not cause any header errors, but then again I did not use Irfanview, but our own inhouse viewer.

So this lets RPM off the hook, and points at a problem in either Krakatoa or Deadline.

So next I modified the same scene to render the actual teapot mesh in Scanline renderer (it does not get any more basic than that).
Rendered locally with all Scanline Render Elements saved to the single EXR, all ended up in the file as they should. File size was 280KB.

Submitted to Deadline, and got a tiny 19KB file with the wrong content of the RGBA channels, and no other channels in it. The RGBA contained either the Object_ID or the Material_ID (both default to pure blue). To find out which one it was, I assigned a Material with ID 10 and set the Object ID to 2, and resubmitted. However, it does not really matter much, wrong is wrong. When the rendering finished, it did NOT contain either the green or red color of the Material ID or Object ID, but the Velocity stored in the RGBA! In other words, the content of the EXR appears to change randomly!

So this lets Krakatoa off the hook because both it and Scanline have the same issue when rendering on Deadline with an EXR attempting to include all render elements in one file.

I will have to involve the Deadline developers now… stay tuned!

Privacy | Site terms | Cookie preferences