We have this problem, in our fusion comps we use sometimes the variable for loaders and savers: “comp”.
Deadline copies the comp local, but then the comp variable isn’t working…
here’s an extract of the logs:
0: STDOUT: Rendering with Fusion version: 6.2
0: STDOUT: Beginning render…
0: INFO: LOG:
0: INFO: LOG: Render started at Tue 2:05PM (Range: 0 to 181)
0: INFO: LOG: Loader2 failed to load file “C:\Documents and Settings\Administrator\Local Settings\Application Data\Prime Focus\Deadline\slave\jobsData\Master\Sh010\GroentenUitBalen_Sh010_MASTER_0000.dpx” (clip “comp:\Master\Sh010\GroentenUitBalen_Sh010_MASTER_0000.dpx” at frame 0) : The system cannot find the file specified.
0: INFO: LOG:
0: INFO: LOG:
0: INFO: LOG: Loader2 failed to load file “C:\Documents and Settings\Administrator\Local Settings\Application Data\Prime Focus\Deadline\slave\jobsData\Master\Sh010\GroentenUitBalen_Sh010_MASTER_0001.dpx” (clip “comp:\Master\Sh010\GroentenUitBalen_Sh010_MASTER_0000.dpx” at frame 1) : The system cannot find the file specified.
0: INFO: LOG:
While we used as a loader: “comp:\Master\Sh010\GroentenUitBalen_Sh010_MASTER_0001.dpx”
is there a way, to let deadline not copy the comp?
IT_RrSs" on node “Mesh Object” ignored - geometry may have wrong position - turning hierarchy off can fix
0: INFO: LOG: FBX Warning: xform inherit type “eINHERIT_RrSs” on node “Mesh Object” ignored - geometry may have wrong position - turning hierarchy off can fix
0: INFO: LOG: Rendered frame 6 (1 of 1), took 31.787 secs
0: INFO: LOG: Render completed successfully at Tue 2:46PM - Total Time: 0h 0m 31.79s, Average: 31.79 seconds/frame
0: STDOUT: output file type = table
0: STDOUT: Checking file C:\Users\Public\Documents\eyeon\Fusion\Comps…\renders2d\left\Master_L_000006.exr
0: STDOUT: Saver “SV_MASTER” did not produce output file.
0: STDOUT: Expected file “C:\Users\Public\Documents\eyeon\Fusion\Comps…\renders2d\left\Master_L_000006.exr” to exist.
0: STDOUT: Fusion reported that the render succeeded, by returning true to comp:Render(),
0: STDOUT: but an expected output file from a saver was not found to exist. There is not generally a
0: STDOUT: single cause for this, but some possibilities for figuring what happened include:
0: STDOUT: - A drive mapping may be missing.
0: STDOUT: - An error occurred, producing log output (which would be displayed above if this is the case),
0: STDOUT: but for some reason dfscript still returned a success result.
0: STDOUT: - The file which is expected to exist perhaps shouldn’t have existed. In this case you should
0: STDOUT: email deadline-support@franticfilms.com with details of this, so we can fix this script.
0: STDOUT: If your problem is none of the above, email deadline-support@franticfilms.com for assistance
0: STDOUT: in diagnosing the problem.
0: STDOUT: SCRIPT ERROR: Saver “SV_MASTER” did not produce output file.
Scheduler Thread - Render Thread 0 threw an error:
Scheduler Thread - Exception during render: An error occurred in RenderTasks(): Saver “SV_MASTER” did not produce output file.
at Deadline.Plugins.ScriptPlugin.RenderTasks(Int32 startFrame, Int32 endFrame, String& outMessage)
Is the “comps” variable defined on the slaves the same way it is defined on the workstations? From checking our Fusion installation, it appears that “C:\Users\Public\Documents\eyeon\Fusion\Comps” is the default for the “comps” variable.
Hi ryan,
I booted the some of the renderslaves of fusion,
and there in the preferences AllDocs:Comps;Fusion:Comps was already configurated for that setting?
I’ve changed the global setting - I think (right clicking on the fusion icon and change the global preference from AllDocs:Comps;Fusion:Comps to Fusion:Comps alone.
The pathmap “AllDocs:” refers to the operating system’s public/shared document folder, so I hoped this would help, but without success… I receive still the error message…
What do you have AllDocs mapped to on your workstations? Is it a network location? If they also map to the local docs folder, that will be a problem because the output path needs to be a network location that’s accessible from all slaves.
comps: is the default location for saving .comp files (and autosaves) This is usually in the user profile and is a bad location for net-rendering.
comp: is the location of the .comp file itself. So if this location changes at submission, there will be an issue.
I believe there is a setting that can detect if a path is relative to the comp and simplify it automatically by substituting the “comp:” variable. This would be an issue if you use submit comp or change the location of the .comp file. Then you would need to either modify all “comp:” strings to be substituted with the network path, or you would need to copy all assets in that tree to each local machine.
@Ryan the concept of rendering locally and collecting the outputs would make an interesting, although hard to fully support, feature.
Another idea would be to make a symbolic link to the network location.
I’ve done some tests further and indeed, trying to change that global “comps” setting didn’t help.
So… the main problem is deadline copies the comp file.
We have hundreds of comps to submit, and we don’t feel like to set every loader to the correct path. As this would cost us a lot of time (we have 30 loaders and 3 savers in the comp).
The assets are also very big to copy it locally.
So we’re really looking for a way that deadline would use the comp file as saved on the network, instead of copying this.
If you disable the option to submit the comp with the job, then Deadline should be rendering the comp from it’s original network location. I’ll run some tests here to try and confirm this.
I’ve confirmed that this error occurs even if the comp is being loaded from its network location. I’ll continue to dig and try to find out why. I’ll keep you posted.
What’s interesting is that “comp:” isn’t listed here. What’s also interesting is that if I open up the comp file from the network in Fusion, and use the Console tab to test MapPath against an output path with “comp:” in it, Fusion maps it to the local docs folder (not the network folder that the comp is sitting in). So it would appear that Fusion’s MapPath functionality doesn’t support the “comp:” variable properly (at least not from their scripting API).
One thing you can do to workaround this issue for now is to disable the Check Saver Output option in the submitter before submitting the job. I tested this here and it worked fine.
if tool.Clip then
path = tool.Clip[comp.CurrentTime]
path = comp:MapPath(path)
eyeon.setclipboard(path)
end
shows the correct path in the clipboard.
I AM noticing that if I have a comp saved in one location, then save it in a different location, the clips don’t change from comp: to the properly resolved path pointing to their original location. So maybe the comp is being re-saved somewhere else prior to the MapPath being run?
That was the case in our test. We just took a comp, resaved it to the network, and then submitted it. When I created the comp from scratch and initially saved it to the network, the path mapping worked.
I’ve checked this further, and the workarounds which Ryan proposed are working for us.
When having a “comp:” variable in a loader, deadline gives problems when “submit comp file” in fusion submission is checked.
When having a “comp:” variable in a saver, deadline gives problems when “check saver output” in fusion submission is checked.
Now I changed the submission script, in such a way that these 2 options aren’t checked anymore.
I don’t think that the “comp:” variabele should be listed in the mappath of fusion, because, it’s the same as saying “give me the location of this comp file”.
Is this some kind of bug / misunderstanding between deadline and fusion?
Because the option “check saver output” isn’t something I like to see unchecked…
I think the issue is with Fusion. Our tests have shown that MapPath will properly map “comp:”, but only if the file is still in its original location. If the file gets saved to copied to somewhere else, the MapPath function breaks. We’ve confirmed this in Fusion without Deadline in the picture.
That being said, we might be able to workaround it, since it’s only an issue when checking the output path. We could probably just do a string replacement to replace “comp:” with the path before we pass it to MapPath. We can’t just stop using MapPath in case the path contains other mappings. We’ll see what we can figure out.
