Prman Spline Experiments

[danieldresser-ie]

Putting up an early prototype for discussion.

This is a pretty simple approach which allows rendering Prman OSL nodes with spline parameters, and also translating them to and from USD. ( Validated by rendering the resulting USD in USDView with the Prman hydra backend ).

For discussion:

• Why do we prefix shader types when writing USD? I assume that just deleting this code is not an actual solution, but it does seem to be required if we want to write shaders that are compatible with USDView.
• Is it OK to drive this just based on the shader name ( would be nice to at least at least check if the shader is an OSL shader ... that will be necessary if we need to support both OSL Pxr shaders and non-OSL Pxr shaders with different spline conventions ... but we seem to lose the shader type when round tripping to USD )?
• If we were going to drive this with a registry, there would be a bunch of questions about how to parameterize the registry - is the registry driven by a shader name prefix? Or does every shader name that contains splines need to get individually registered ( for greater flexibility )? Does the registry just return the suffixes for the 3 plugs that make up a spline, or do we allow for the possibility that a renderer might have a spline representation that doesn't directly map? Maybe all this is a good argument that we shouldn't create a registry yet, and wait until we have more data on what is required before we expose anything in the API.

If we're happy with this style of hardcoding, then potentially all that really needs to be done is adding in support for 3delight as well ( and potentially non-OSL Prman nodes ).

[danieldresser-ie]

I should follow up since I did notice the answer to one of my questions ... the interface for selecting the convention can't be quite as simple as the prototype lookupSplinePlugSuffixes, since 3delight converts the basis to an array of ints ( though that could just be one extra flag if we're OK with hardcoding things ).

[danieldresser-ie]

Oh, and right before bed, I finally put 2 and 2 together ... the reason why the shader type isn't round-tripping is probably because I broke that by removing the shader name prefix for USDView compatibility.

[johnhaddon]

Why do we prefix shader types when writing USD? I assume that just deleting this code is not an actual solution, but it does seem to be required if we want to write shaders that are compatible with USDView.

git blame wasn't of much use here, but I think the answer is that we were matching Autodesk's convention for Arnold shaders. We did all our initial testing with Arnold, so that would make sense.

In general, I guess anyone could choose any naming convention, because it's all down to how they register their shaders with RenderMan's Sdr registry? But we're currently working without that registry, to avoid having to ship everyone's USD plugins with Gaffer.

Is it OK to drive this just based on the shader name?

I think so. A quick glance at a mix of C++ and OSL Pxr shaders suggests that they all use the same convention, so I'm not sure we need to care about OSL vs C++, unless you've seen otherwise?

is the registry driven by a shader name prefix?

I'd suggest we use the same key as use for Gaffer's shader metadata registry - <type>:<name> as in ai:surface:standard_surface. Combined with wildcards that would let us register conversions for whole sets of shaders at once, and override for individual shaders.

Maybe all this is a good argument that we shouldn't create a registry yet, and wait until we have more data on what is required before we expose anything in the API.

That's fine with me. As things stand I think I'd be happier with the extra 3Delight-specific flag than I would a more complex mechanism, but a wait-and-see-approach seems wise anyway.

the reason why the shader type isn't round-tripping is probably because I broke that by removing the shader name prefix for USDView compatibility.

I don't think we've ever round-tripped shader type - see https://github.com/GafferHQ/gaffer/blob/main/python/GafferRenderManTest/RenderManShaderTest.py#L104-L134. I think this may be because we've been discussing removing the concept of type (as in surface vs shader etc) entirely, since OSL was moving away from it?

[boberfly]

Hey @danieldresser-ie not sure if you saw here but I did some initial testing here if it helps: #1450

What I've learned of the convention that Prman uses for splines is a common match to how Katana is doing them (maybe one influenced the other? Not sure) and KtoA tends to match this convention as well, despite the differently named inputs (and lack of interpolation arrays, it is just a constant remapped to the array). And yep C++ and OSL are 1:1 here as well.