ID 337291 - Katana's built-in coshader handling is inflexible and hard to disable

Follow

Problem summary:

The intent of RendererInfoBase::getRendererCoshaderType() is apparently  to allow the renderer to set the shader type string that identifies coshaders. However Katana currently only calls (in the RenderPlugins module) to test if the return value is empty. If it is non-empty, then 'coshader' is added to list of shader types supported by the renderer.

It may be better if Katana didn't do anything automatic like this in terms of automatically populating types if co-shaders are supported. It should just enable/disable the *ShadingNode node.

The reason for some of this logic may be that no-one thought anyone would want to use the Material node to create a co-shader - while that might be true for some renderers, for others it is not and may end up being a limitation.

It should be up to renderer plugins to enforce any restrictions within the rendererInfo part of the plugins, instead of Katana making those assumptions at a global level.

Steps to reproduce:

  1. Build a renderer plug-in that returns something other than the empty string or 'coshader' from getRendererCoshaderType().
  2. In the Python console in Katana, run print(RenderingAPI.RenderPlugins.GetRendererShaderTypes('myRendererName'))

Expected behaviour:

The string returned by getRendererCoshaderType() is present.

Actual behaviour:

The string returned by getRendererCoshaderType() is not present; 'coshader' is.

Workaround:

No known workaround.

    We're sorry to hear that

    Please tell us why