Combustion BUG : Gamma/Pedestal/Gain : Output1 Issue

Hi,
Found a bug in the shellrenderer.exe in Combustion 4, but guessing that it is probably present in v3 and v2008 as well…
When you submit a Combustion workspace file to process, the “Output Operator” syntax contains the name of the “Composite” followed by the particular output node number, so as an example it may read something like…“MikeComposite/output1” in the submission script window. This code then gets passed to the shellrenderer.exe. However, in Combustion, the output operator name is dervived from effectively the last “operator” placed on top of say, a composite or nested composited node, hence placing a “Gamma/Pedestal/Gain” operator onto the top composite, results in the output operator being named as follows: “Gamma/Pedestal/Gain/output1”…the result, is the shellrenderer.exe crashes with the C++ error as seen in the image below.

2 issues:

  1. Can we enhance the python submission/plugin code to handle potential output operator nodes with multiple “/foward slashes/” in its name? and…
  2. Can we add a pop-up dialog handler to handle when the shellrenderer.exe does crash so that the task/frame gets error’ed out back to deadline, as the slave doesn’t realise that Combustion has crashed and just sits there! (I had to RDC into the slave to discover that there was a problem…!). (FYI : Suspending the job, does work to kill the shellrenderer.exe and hence, recover the slave.)

Mike

Could you post an example workspace file that reproduces this? We do not currently have a license for Combustion (we’re working on it), so we can’t create and save our own workspaces. Our submission script is using regular expressions to parse this information out, so a test workspace would really help.

What’s the current behavior? Can you give us an example of how the submission script is currently handling this and how it should be handling it?

In the Combusion.py plugin file, find the CombustionProcess class, and in the InitializeProcess function, find this line:

self.StdoutHandling = True

After this line, add this new line:

self.PopupHandling = True

Hopefully that takes care of this problem.

Cheers,

  • Ryan

Hey,

The Popup.handler works perfectly now and fails the frame. Might be worth making this the default for the Combustion plugin?
See attached for a zip file that contains a rendered image sequence 0-50, which is the only input footage into a Combustion v4 workspace, based in the directory “z:\Teapot_360”.
The output directory for 2 output operators is also in the same directory. I have gone through all the operators in a standard copy of Combustion, together with some third-party operator plugins and the bug seems limited to 2 operators, under the colour correction operator sub-menu;

  1. Brightness/Contrast &
  2. Gamma/Pedestal/Gain

In the Combustion workspace file, it has 2 output operators which demonstrate the 2 troublesome operators mentioned above. If you submit the workspace file via the submission script, you will see that the output operator drop-down list has 2 operators available, both of which contain multiple “/forward slashes/” which will cause the shellrenderer.exe to crash (which the new python code now handles nicely).

Also, I have included a ‘fixed’ combustion workspace file which has all the forward slashes replaced with underscore characters.

So maybe, its just a case of flagging this problem during submission and failing the submission, instead of trying to change the actual “characters” that are causing the crash? If the Combustion file is not submitted with the submission, but rather referenced off the network, you don’t really want Deadline changing the name of operators, etc as it may cause more confusion/damage than it actually fixes…! Not sure, what the best approach is to fix this overall issue…

Mike

Teapot_360.zip (992 KB)

Thanks for the information, and we’re glad that the popup handling is working. This will be added to the next release.

We’ve logged the other problem as a bug, and we appreciate you posting the test file.

Cheers,

  • Ryan

We were able to reproduce this through Deadline and by running ShellRenderer from the command line (which wasn’t actually crashing in our tests). In fact, the command line test returned one additional line of output:

We’re not sure why this error isn’t included in the Deadline output, but regardless, it seems like Combustion’s command line renderer can’t handle some of its own operators. :unamused:

I think the best thing to do would be to simply flag these problematic output operators and notify the user that they need to be renamed before they can be submitted.

Cheers,

  • Ryan