Arnold : Multiple Outputs Per Driver

[danieldresser-ie]

( Recreated from #6207 but with the branch on GafferHQ ).

This allows rendering multi-layer exrs directly from Arnold.

It took a fair bit of reorganizing to fit this into the current structure, but I'm feeling reasonably good about how it ended up - it should be in a good place for reviewing at least. It probably could use more test coverage before we merge it ( perhaps less for the new feature being added, and more for some of the existing functionality, to make sure that nothing has been broken that is currently in use ).

The only known breakage that happened in the tests were that there were some tests that used the same filename for multiple outputs - these failed with an error about these outputs not being possible to merge, until they were given distinct names, which seems to reflect the intent of the tests. Hopefully this wouldn't be an issue in production scenes, where people are actually using the files ( the only reason why the file being overwritten wasn't previously an issue is because the test in question was just testing the conversion to an Arnold scene, not an actual render ).

The one case I can think of that could affect production is that previously when using ieDisplay, you could use an identical fileName for multiple outputs with different parameters, since the fileName wasn't important to an interactive display. If users were doing that, they could an error message about the outputs not being valid to merge, and need to change the output name. But hopefully if they've been creating displays based on Gaffer's templates, this won't be an issue.

[danieldresser-ie]

I was unable to reproduce the test failures locally. On a retry, everything succeeded in CI as well.

I'm still feeling rather concerned by one of the failures - this feels exactly like the sort of test that could reveal an issue where the new code does something wrong in a corner case:

testEditLightGroups (GafferArnoldTest.InteractiveArnoldRenderTest.InteractiveArnoldRenderTest) ... gaffer: include/Gaffer/Signals.inl:271: Gaffer::Signals::Signal<Result(Args ...), Combiner>::Slot::CallScope::CallScope(Gaffer::Signals::Signal<Result(Args ...), Combiner>::Slot&) [with Result = void; Args = {GafferImage::GafferDisplayDriver*}; Combiner = Gaffer::Signals::DefaultCombiner<void>]: Assertion slot.previous' failed.
WARNING | signal caught: SIGABRT -- Abnormal process abort`

Have you ever seen that before? I should probably try running the tests repeatedly locally - if it's a random thing, maybe I can reproduce a failure.

[johnhaddon]

Have you ever seen that before?

I have, and I don't think it's related to this PR. I think it's down to Signal not being thread-safe, and something about the way we use signals in the Display node. I haven't found the time to look into it more deeply yet, partly because there's no sign of this causing problems in the wild.