refactor(srp): align urp renderer feature ownership model

This commit is contained in:
2026-04-21 20:17:08 +08:00
parent 0d0919b276
commit e527ca4e3a
6 changed files with 201 additions and 76 deletions

View File

@@ -0,0 +1,103 @@
# SRP URP Renderer Feature Authoring Model Plan
Date: 2026-04-21
## Background
The last few SRP stages already cleaned up the following seams:
- shared native backend substrate ownership
- renderer feature lifecycle invalidation
- renderer feature runtime-state synchronization
However, the managed URP side still has one architecture mismatch against the
Unity-style direction:
- `ScriptableRendererData` still exposes two feature ownership paths:
- persistent configured field: `rendererFeatures`
- runtime factory seam: `CreateRendererFeatures()`
That dual model makes the current design harder to reason about:
- the renderer-data asset is not the single source of truth for feature config
- feature lifetime semantics are blurred between "configured object" and
"runtime-created helper"
- project probes and managed probes still encode a non-Unity authoring style
- future editor integration and SRP asset editing will inherit this ambiguity
If the engine is meant to converge toward a Unity-style `SRP + URP` model,
`ScriptableRendererData` should own a stable set of feature configuration
objects, and runtime invalidation should rebuild renderer runtime state from
that configured list rather than from an alternate feature factory seam.
## Goal
Make the managed URP renderer feature model closer to Unity:
- `rendererFeatures` becomes the single configured source of truth
- `ScriptableRendererData` no longer creates an alternate feature collection via
`CreateRendererFeatures()`
- renderer runtime rebuild continues to work by snapshotting and releasing the
configured feature instances correctly
- `ScriptableRendererFeature` is modeled as a managed engine object rather than
a plain helper class
- managed probes and project probes are migrated to explicit feature
configuration instead of runtime feature factory overrides
## Why Now
This is the right point to do it because:
- the lifecycle and dirty/version chain is already stable enough
- the next SRP stages need a clearer asset/config model, not more invalidation
patches
- future renderer authoring, editor exposure, and custom URP feature workflows
all depend on a clean ownership model
If this seam stays open, later SRP work will keep mixing:
- asset configuration logic
- runtime cache rebuild logic
- probe-only factory patterns
That would move the codebase away from the Unity-style architecture the project
is aiming for.
## Scope
This stage stays focused on managed SRP/URP ownership cleanup.
Included:
- `managed/XCEngine.RenderPipelines.Universal/Rendering/Universal/ScriptableRendererData.cs`
- `managed/XCEngine.RenderPipelines.Universal/Rendering/Universal/ScriptableRendererFeature.cs`
- affected managed probes under `managed/GameScripts/RenderPipelineApiProbe.cs`
- affected project probes under `project/Assets/Scripts/ProjectRenderPipelineProbe.cs`
Not included:
- deferred rendering
- native render backend changes
- new editor work
## Implementation Plan
1. Collapse renderer feature ownership onto `rendererFeatures`
2. Remove the `CreateRendererFeatures()` seam from `ScriptableRendererData`
3. Keep runtime rebuild safe by retaining the last runtime-bound feature
snapshot for disposal
4. Make `ScriptableRendererFeature` inherit from managed engine `Object`
5. Migrate probes to constructor/config-field based feature assignment
6. Rebuild `XCEditor`
7. Run old editor smoke for at least 10 seconds and verify a fresh
`SceneReady`
8. Archive the plan, commit, and push
## Expected Result
After this stage:
- renderer data is the authoritative owner of renderer feature configuration
- runtime invalidation semantics remain intact but are simpler to reason about
- custom URP-style feature authoring is closer to the Unity mental model
- the next SRP stages can build on a cleaner managed asset/config substrate