I’m not sure this is exactly a Deadline issue, might be more Max 2011 or Vray related but…
In my example scene where things broke, If you have say a render set to save out as a TGA file, you have 7 render elements and you tile render your image. It renders, puts the tiles in folder for render elements then stitches them together as expected.
If you go back to the file, change the Render Output of your main rgb to say EXR file and kick it off again as tile renders… The tiles for the main rgb save as EXRs and then will stitch together again, the tiles for the render elements will save out but will not stitch back together again citing errors about bad file data, if you try to open them in Photoshop you’ll get the same issue. However If you change the extension of the file to .tga they will then open so for some reason max is saving an TGA file with a .exr extension.
The easy fix is to remove all the render elements and add them in again, but this a bit of pain.
Any Ideas?
Dave:
We’ve noticed the same/similar issue here in our studio, and we have had problems over the years with elements in general, even before our switch to deadline.
We’ve adopted the following workflow to minimize these issues: (We are a VRay shop as well)
Main Guidelines:
- If you ever change the main render output, delete and reassign all the render elements.
- Never change any of the main components about render elements after they are created - specifically, Element Name and output - output includes both format, bitdepth, or output name in the element.
For Stills:
We typically set the main render output and then create all the elements. When we render through deadline, we don’t use any of the renderelement/pathing options. If one of these are ever checked, we reset the output and all elements.
For Animations:
We set the main output and create all the elements. When rendering animations through deadline, we always use the “update render element paths” to make the render element folders.
With these simple rules we have been able to eliminate any odd issues - trust me - we had some crazy ones!
Thanks, bragibjornson. I’m aware of these pipeline issues, but unfortunetly making everyone in the studio aware of these and policing it is difficult, that’s why I was wondering if there can be any processing by Deadline to ensure this problem doesn’t occure. It might be a case of pre-submission deadline stores all the values associated with the render elements and removes them all and adds them back in again, shouldn’t take more than a second or so to run.
Perhaps you might like to test this script?
It removes and then re-adds all the render elements. I’m going to integrate it into our deadline submission and see if we get any more errors.
[code]–stores all the values of the render elements
–removes all render elements
–restores all render elements
(
local re = maxOps.GetCurRenderElementMgr()
local AR_Elements = #()
local AR_ElementProps = #()
local AR_ElementNames = #()
for i = 1 to re.numrenderelements() do
(
local theelement = re.getrenderelement (i - 1)
append AR_ElementNames theelement.elementname
--getproperty
append AR_Elements (classof theelement)
local a = #()
for prop in (getPropNames theelement) do
(
--print prop
--print (getproperty theelement prop)
try(append a (getproperty theelement prop))
--try catch is for dealing with render element bitmaps...
catch(append a "")
)
append AR_ElementProps a
)
re.RemoveAllRenderElements()
for i = 1 to AR_Elements.count do
(
re.addrenderelement (execute((AR_Elements[i] as string) + "()"))
local theelement = re.getrenderelement (i - 1)
for j = 1 to (getPropNames theelement).count do
(
try(setproperty theelement (getPropNames theelement)[j] AR_elementProps[i][j]
)
catch()
)
)
--to get around weird bug with VrayExtraTex Names
for i = 1 to AR_ElementNames.count do
(
local theelement = re.getrenderelement (i - 1)
print AR_ElementNames[i]
theelement.elementname = AR_ElementNames[i]
)
)[/code]