IECoreScene : Spline collapse/expand support for native renderer nodes Arnold/Renderman

[boberfly]

Generally describe what this PR will do, and why it is needed.

• Expand and collapse splines/ramps support for native renderer shaders for Arnold and Renderman
• Helps for interoperability with OpenUSD schemas
• For Arnold it is only designed for ramp_rgb and ramp_float nodes and not any htoa/mtoa native nodes currently
• For Renderman there are shaders that are both ri:surface/C++ based and OSL-based, so these need to be checked for and not modify existing OSL naming conventions for splines (eg. if the OSL shader name has the Pxr prefix it'll use this convention).

Related Issues

• N/A

Dependencies

• N/A

Breaking Changes

• Just to note this modifies deprecated functions collapseSplineParameters and expandSplineParameters by adding shaderType and shaderName arguments, but it looks like these functions may just go private into collapseSplines/expandSplines ? Looks like IECoreArnold uses it still.

Checklist

• I have read the contribution guidelines.
• I have updated the documentation, if applicable.
• I have tested my change(s) in the test suite, and added new test cases where necessary.
• My code follows the Cortex project's prevailing coding style and conventions.

I wanted to use the CI facilities for this one to see if my unit tests work - I need to make a Cortex-specific Rez pack to do better testing on my end still...

TODO : Arnold splines/ramps probably don't need the duplicated knots at the start/ends but I am not sure what it prefers yet, need to test mtoa/htoa or ArnoldUSD...

Also there's some potential round-trip data loss as MonotoneCubic doesn't exist in Cortex but it does exist in Gaffer, so I'm not too sure how to deal with this yet.

Also also: Arnold supports an array of different interpolation/basis per-position, this code only supports one for the whole spline, but I think other well-known DCCs do this also.

[boberfly]

Alright I was able to get past testArnoldArrayInputs by just disabling the duplication of start/end points in the Arnold case, I don't think Arnold ramp_rgb' 'ramp_float needs/wants that?

[johnhaddon]

What's your timeframe for this @boberfly? We have the odd comment in Gaffer suggesting that life might be easier all round if we pass SplineDefinitions around instead of Splines, and I'm wondering if we might be able to come up with something cleaner and more widely applicable if we give ourselves the freedom of an ABI break for Gaffer 1.6, rather than try to shoehorn more into 1.5. I'm not convinced that SplineDefinition in its present form is ideal either, but now we have a few more use cases we might be able to come up with something similar that addresses all our problems.

[boberfly]

Timeframe I'm not too sure probably like May-ish, I don't mind carting around this change for internal testing if you guys are thinking of something cooler for 1.6 - I can probably make an upgrade script if I get too far with this, or keep any set-in-stone assets purely as USD files.

Hopefully my dabblings help here to figure out how to take this further, cheers!