Starting a thread here to document all my findings from the problems with Maya, Render Layers, VRay and Tile Rendering.
Deadline Version: 7.2.0.18R
Maya 2015
VRay 3.1 for Maya
At the moment we have two issues…
MAJOR: All the render tiles finished rendering but not all the files were copied to the network.
MAJOR: The Config file for the Draft Tile Asssembler had the wrong paths to files for the render elements (AOVs)
MAJOR: Submitting Tile Renders from Maya fails as the MEL code is checking an Arnold AOV value which returns undefined as we don’t have Arnold.[FIXED in 6.2.1]
A_01) Render a Vray scene, no file name Prefix options, using default output path. 5 Render Elements, Full Frame rendering.
Result: Renders frame, render saves and render elements are saved.
A_02) Render a Vray Scene, no file name prefix options, using default output path 5 render elements, Region Rendering, Old-style Tile rendering mode, 2x2 tiles. Renders, each tile element gets saved, images are stitched together
A_03) Render a Vray Scene, filename prefix set to /, 5 render elements, region rendering, old-style TIle rendering, 2x2 tiles, Renders, each tile element gets saved but the only one to stitch is the Beauty Pass, all the other render elements fail with the following error message. Looks like it’s not looking in the sub-folders for the elements.
Ok so the Problem 3) I identified in my first post is on line 5353
int $aovMode =getAttr “defaultArnoldRenderOptions.aovMode”`;
I changed this to:
int $aovMode = 0;
Which I think caused the previous errors on pathing for the stitching of the render elements,
I’ve now changed it to:
int $aovMode = 1;
This still doesn’t fix the problem, the main beauty stitches but the render elements don’t.
The Config file for stitching for the main beuaty render is in the folder:
N:\3.CGI\CGI_R&D\Maya_VRay_testing\TileTest_projA\Images\TileTest_Proj_A_04
In this file the paths are correct for the beauty’s tiles.
The config files for stitching the other render elements are in this folder…
N:\3.CGI\CGI_R&D\Maya_VRay_testing\TileTest_projA\Images
With the paths inside the txt files pointing to the same folder, not the folder where the render element tiles are residing.
Also, notes for detail, the renders are being saved as individual files not a combined EXR file. For your tests, PNG will definitely show up this problem.
I am told at least some of the stuff you are seeing is fixed in Deadline 7.2.1, which is currently in beta. Can you advise if trying the beta is an option for you?
The one you sent me via email is from 7.2.1 correct? If so, yes I have tried that MEL script, it stops the submission errors but doesn’t fix the render element stitching issues.
All the errors for the render element assembly building is with code in the SubmitMayaToDeadline.mel file, so please send me a new version if there is one your side.
I think it’s better to keep our conversation on the ticket system, and I’ll post an update when we have more solid info. Feel free to keep posting here, though.
So what is going is that Maya automatically adds the Camera, Render layer (and Render elements, or whatever else individual renderers add in) to the start of the output prefix if they are not included in the output prefix and they are required (multiple renderable cameras, render layers, etc). When we were originally building up the Draft Tile assembler we did not know that it did this so we were not handling it as such. This is why we are getting weird cases everywhere. It also caused a lot of issues with where the files were going if you submitted cameras as separate jobs and did not have in your output prefix the files would be written to the same location.
What this all means is that we are going to have to re-write the code that is setting up the region names, and the output file names throughout the submitter to detect these cases (like has render layers and does not have in the prefix) and handle them appropriately.
What might be good then for Sanity, is in the Submit Maya to Deadline window to have a path preview of what the output is actually going to be so the user can remove any extra tokens that they might have put in. I’ll chat to Vlado about making the output path in VRay give more of a clue about this happening as well…
Looking at a recent project done out here in NYC I see all sorts of problems with rendering due to this issue.
I have a renders folder with all kinds of naming conventions…
/
/
//
//
I’m going to try and standardise this out here but as our project vary is size and complexity massively there’s not really a one-size, fits-all solution for us.
Grant talked with us today and mentioned his refactoring is going well and is simplifying the code base so far. It’s probably going to be placed into the 8.0 branch, but I can pick out the files and hand it to you to use.
