Allow `RenderTargetStrategy` to be shared across prefabs via ScriptableObject?

[claytercek]

Problem

RenderTargetStrategy is a MonoBehaviour, so it can't be referenced across prefabs in the inspector. This makes sharing a PooledRenderTargetStrategy between panels in different prefabs awkward — you end up needing a scene singleton and a companion component to wire things up at runtime.

Suggestion

A thin RenderTargetStrategyAsset : ScriptableObject that holds pool configuration and manages the lifetime of the underlying runtime component. RivePanel would accept one alongside the existing RenderTargetStrategy field.

  [CreateAssetMenu(...)]
  public class PooledRenderTargetStrategyAsset : RenderTargetStrategyAsset
  {
      [SerializeField] private Vector2Int m_pooledTextureSize;
      [SerializeField] private int m_initialPoolSize;
      [SerializeField] private int m_maxPoolSize;

      private PooledRenderTargetStrategy m_runtimeInstance;

      public override RenderTargetStrategy GetOrCreateStrategy(GameObject host)
      {
          if (m_runtimeInstance != null) return m_runtimeInstance;
          var strategy = host.AddComponent<PooledRenderTargetStrategy>();
          strategy.Configure(m_pooledTextureSize, m_initialPoolSize, m_maxPoolSize, ...);
          m_runtimeInstance = strategy;
          return strategy;
      }
  }

The ScriptableObject stays thin — just config and a factory. The MonoBehaviour still does the actual work, so nothing about LateUpdate batching or render pipeline registration needs to change.

[damzobridge]

Hello,

Render Target Strategies can be assigned to Rive Panels at runtime, so you can dynamically assign them to your different panels in prefabs as needed once they're instantiated.

m_rivePanel.RenderTargetStrategy = myPooledStrategy;

We added that as an escape hatch to allow your kind of suggested workflow without requiring it as part of the official API/SDK. I think you could create a monobehavior that accepts your custom PooledRenderTargetStrategyAsset, and add that to the prefabbed panels to get something close to the behaviour you expect.

However, my larger concern here is whether you need to use the Pooled Render Target strategy in the first place. These Render Target Strategies were created way before databinding was introduced, as there weren't great options for controlling Rive files at the time. However, as our Best Practices page in the docs covers, you really shouldn't need multiple panels today unless you're working in worldspace/VR.

Is that the case in your project?

[claytercek]

Cool, thanks. Yeah I do have a couple of world-space prefabs that I'd like to use rive for. I also have a screenspace UI that isn't 100% rive, rather a couple of widgets distributed throughout. I have a couple of complex shaders and behaviors that would be difficult if not impossible to build in Rive, so I can't go all in on the 'single panel' strategy.

Totally understood that my setup is genuinely in the non-ideal territory. That said, it might still be worth smoothing out the escape hatch API a bit — the workaround works, but it's a noticeable rough edge for what seems like a fairly common scenario, especially for worldspace/VR as you mentioned.

[claytercek]

To maybe limit the scope of the suggestion here, I wonder if it would make more sense to refactor just PooledRenderTargetStrategy to accept a serializable ScriptableObject (PooledRenderTargetAsset?) that contains the pool config variables and runtime state (ObjectPools, dictionaries, panel metadata), while the update behavior, rendering calls, and pipeline registration stay in the MonoBehavior?

At a quick glance, the only logic that couldn't be easily moved would be the calls to CreateRenderTexture/ReleaseRenderTexture, as they live on RenderTargetStrategy.

The same might make sense for the atlas render strategy too?