AWS Thinkbox Discussion Forums

Lightning Behavior

Hi,
I just wanted to check with you about some of the behavior that lightning is exhibiting to clarify what’s going on. We have some tools that take advantage of some standard naming conventions, and just recently we had an issue where a file had a suffix of _alt_0 appended to it. We also noticed the following logs to go along with it.

0: INFO: Lightning: CallCurRendererRenderFrame returned code 1
0: INFO: Lightning: Render done
0: INFO: Lightning: Attempt to move C:\Users\render\AppData\Local\Temp\xhl2680.5.carrier_beauty.rgba.1046.exr to destination failed: Access is denied.
0: INFO: Lightning: Waiting 1 seconds to try again.
0: INFO: Lightning: Attempt to move C:\Users\render\AppData\Local\Temp\xhl2680.5.carrier_beauty.rgba.1046.exr to destination failed: Access is denied.
0: INFO: Lightning: Waiting 2 seconds to try again.
0: INFO: Lightning: Attempt to move C:\Users\render\AppData\Local\Temp\xhl2680.5.carrier_beauty.rgba.1046.exr to destination failed: Access is denied.
0: INFO: Lightning: Waiting 3 seconds to try again.
0: INFO: Lightning: Attempt to move C:\Users\render\AppData\Local\Temp\xhl2680.5.carrier_beauty.rgba.1046.exr to destination failed: Access is denied.
0: INFO: Lightning: Waiting 4 seconds to try again.
0: INFO: Lightning: Attempt to move C:\Users\render\AppData\Local\Temp\xhl2680.5.carrier_beauty.rgba.1046.exr to destination failed: Access is denied.
0: INFO: Lightning: Waiting 5 seconds to try again.
0: INFO: Lightning: Saved image to \\san\show\burn\xhl\xhl2680\gen\rndr\carrier_beauty\rgba\xhl2680.5.carrier_beauty.rgba.1046_alt_0.exr
0: INFO: Lightning: Checking render elements

I just wanted to know what the process is for lightning determining when/where it places these alternate files.
Thanks!
-Shem

Hi Shem,

Lightning adds the “alt#” extension if it’s unable to write to the original output location. You can see in the log that it was getting Access Denied errors when trying slave the image. We figured this was better then just failing the render and losing the image.

Here’s how it works. First, we make 5 attempts to save the image with it’s original file name with increasing intervals between save attempts. If all 5 fail, then we make six more attempts by appending _alt_0, _alt1, …, alt_5 to the file. If those fail, then we just throw an error for that task.

Cheers,

  • Ryan

Okay, cool. I guessed that’s what was happening, but just wanted to make sure that there weren’t any edge cases that weren’t be indicated in the log.
Thanks for the clarification!

Would it be possible to add in an option that allows you to disable this feature, perhaps in the Deadline 3dsmax plugin options?

Yeah, I’m sure we could add an option for that. Just curious why you want it? It would mean that the render would fail and it would keep retrying the task until it is able to successfully write the file.

There’s a monitor job RC script which allows easy cleanup of any _alt_x named files by attempting to remove this temporary suffix and rename them back to the original filename.

@Ryan Hmmm, I guess that I was referring to it failing the job completely without generating products, but that wouldn’t be ideal either. Now that I’ve thought about it, it’d be great to be able to define how we want the alternate files to be named. In our situation, we have a script that uses naming conventions to pull the products back into the rest of the pipeline; the suffix ends up creating a bit of a mess as these naming conventions have become pretty well established.
@Mike That sounds like it could be useful; I’ll look into it. Thanks!

I guess it depends on how much customization you want over the alternate files. Would it be enough to be able to define a suffix other than “alt#”?

Hmmm, I don’t think it would, as it appends it appends it to the frame number section of the filename. Let me talk to our pipeline guys and see if we can do anything on our end to resolve this issue.
Thanks!

Privacy | Site terms | Cookie preferences