Opt-in HDRP Forward comparison

-rampageForwardRendering requests HDRP Forward rendering on the application's main camera. The first test did not activate Forward: the pipeline asset is DeferredOnly, so HDRP overrides the camera request back to Deferred. The earlier version of this document incorrectly interpreted the asset value 2 as Both. This was a source-audit error; the actual enum values and observed runtime behavior are corrected below. The run 235140 is not a Forward comparison or a crash-fix validation.

Normal launches retain their existing rendering path. Following that failed activation, the flag now checks the selected pipeline asset before changing any camera component or setting. It resolves QualitySettings.renderPipeline ?? GraphicsSettings.defaultRenderPipeline and requires an HDRP asset whose supported-mode bitmask includes ForwardOnly (1). Missing HDRP or DeferredOnly produces RAMPAGE_FORWARD_RENDERING status=unsupportedPipeline, requests exit code 2, and throws InvalidOperationException to stop the calling RampageApp.Awake before the garage/world is built. It does not mutate the pipeline asset at runtime.

With a supported asset, the flag changes only HDAdditionalCameraData.customRenderingSettings, the camera's litShaderMode, and its LitShaderMode override bit. Existing effect settings, the asynchronous-compute override, quality, MSAA, geometry, shaders and other override bits remain intact. A successful guard proves build configuration support, not actual GPU pass execution or crash repair.

The pinned source examined is Library/PackageCache/com.unity.render-pipelines.high-definition@700710090fa9 (HDRP 17.3). RenderPipelineSettings.cs:36 defines ForwardOnly = 1, DeferredOnly = 2, Both = 3. The asset used by run 235140 had supportedLitShaderMode: 2 in Assets/Rampage/Settings/RampageHDRP.asset:255, therefore DeferredOnly. FrameSettings.cs:673 explicitly replaces any camera request with Deferred for that asset. The serialized camera defaults in Assets/HDRPDefaultResources/HDRenderPipelineGlobalSettings.asset:340 also use Deferred. The application's existing RampageApp.cs:102 override changes AsyncCompute only; it does not replace the default frame settings wholesale. HDRP first copies its defaults, applies only marked overrides, and then sanitizes them (FrameSettings.cs:816). The ineffective Forward request is explained by that sanitization, not by an initialization error or a failure of the recorder.

A valid comparison requires an isolated build using a pipeline asset with Both (3) support and retained Forward shader variants. A runtime asset-mode change alone is insufficient evidence: Editor/Material/Lit/LitShaderPreprocessor.cs:71, :90, and :96 strip Forward-related normal-buffer/opaque variants for DeferredOnly. After rebuilding, acceptance must inspect HDCamera.frameSettings.litShaderMode and require the effective value Forward, not just the requested camera field. The build configuration and manifest must establish the supported asset mode; the runtime guard does not repair or rebuild stripped shader variants.

What effective Forward would remove

The following applies only once a rebuilt player actually reports effective Forward for the affected camera; it did not apply to run 235140:

• HDRenderPipeline.Prepass.cs:843 skips the GBuffer pass in Forward. Forward retains a full depth prepass (:230) and normal/depth data required by screen effects.
• HDRenderPipeline.LightLoop.cs:893 returns before adding the Deferred Lighting pass. Consequently its direct or indirect Deferred.compute lighting dispatches do not execute for that camera.
• Lighting/LightLoop/LightLoop.cs:672 enables light/material feature classification only in Deferred. Forward therefore skips the classification and indirect-dispatch-argument construction guarded by enableFeatureVariants in HDRenderPipeline.LightLoop.cs:314. The serialized ComputeLightVariants/ComputeMaterialVariants bits need not be rewritten.
• HDRenderPipeline.RenderGraph.cs:875 selects both Forward and ForwardOnly material passes. Stock HDRP/Lit surfaces and the existing custom billboard's ForwardOnly pass remain eligible to render.

Deferred.compute:170 calls the GBuffer decoder; Material/Lit/Lit.hlsl:884 reads _EnableLightLayers in that decoder. Removing this path is relevant to the earlier out-of-range global-constant-buffer read near that field. It does not prove that the old unnamed dispatch was this shader, or that the Vulkan/D3D11 TDRs share the old D3D12 validation failure's cause. supportLightLayers is already false in the pipeline asset: disabling the feature again would not remove the shader's read of the runtime flag.

What remains

Forward is not a compute-free HDRP path. HDRenderPipeline.RenderGraph.cs:177 still calls BuildGPULightList; the sequence in HDRenderPipeline.LightLoop.cs:684 contains screen-space light bounds, the big-tile prepass, FPTL light lists and voxel/cluster light lists. The light count includes local lights, environment probes and decals (Lighting/LightLoop/LightLoop.cs:1754), not simply directional lights. Individual dispatches depend on the light count and existing settings.

Relevant camera bits are:

Turning off FPTLForForwardOpaque would select clustered forward lighting and avoid the per-tile FPTL build; clustered/voxel work would remain. Turning off BigTilePrepass would remove that separate optimization. Neither extra change is part of this comparison. See FrameSettings.cs:595, HDRenderPipeline.LightLoop.cs:520, and HDRenderPipeline.RenderGraph.cs:929.

SSR, SSAO, contact shadows, volumetrics, subsurface scattering, post-processing, TAA and motion vectors keep their existing settings and may still dispatch compute shaders. No MSAA is enabled: HDRP sanitization at FrameSettings.cs:694–:704 would otherwise alter SSR and screen-space-shadow availability. This switch retains the current anti-aliasing choice rather than introducing that second variable. Forward and Deferred need not produce pixel-identical lighting.

The main-camera override does not change independent reflection-capture settings. SceneLighting.cs:176 creates an on-demand garage HD reflection probe, which retains the pipeline's reflection defaults. A process using this flag can therefore still execute Deferred during a probe capture. This comparison must be described as main-camera Forward, not as elimination of every Deferred dispatch in the process.

Evidence and limits

RAMPAGE_FORWARD_RENDERING records the symbolic and numeric asset support mode, application status, prior custom-settings flag, prior LitShaderMode override, prior stored camera field, requested/resulting stored field, resulting override bit, stored MSAA mode and its override bit. Successful application logs status=requested; rejection logs status=unsupportedPipeline and cameraOverrideApplied=false. A stored field, even with an override, is not necessarily the resolved pipeline setting. Accordingly the successful log says effectiveRenderingPath=unverified; it does not claim observation of GPU pass execution. The updated flight recorder reads the existing render-loop HDCamera without creating one and records the last aggregated effective mode separately. In run 235140 it correctly reported requested Forward and effective Deferred after camera rendering had begun. Those samples exposed the incorrect asset-mode assumption.

The shader audit found no differing current billboard material-buffer layout between depth, motion and color passes. AlpineFirBillboardProperties.hlsl:16 retains the stock Unlit material fields and appends both stem parameters inside the same unconditional UnityPerMaterial buffer. It does not redefine HDRP's ShaderVariablesGlobal layout. The authored scene code does not bind its own constant or compute buffers. A Forward result would narrow the executed engine path; it would not establish a material-buffer source error.

Validation: offline managed compilation passed for 119 Runtime and 25 Editor files with warnings treated as errors; zero warnings/errors. The source hashes and compiler scope are preserved in forward-managed-compile.json. This verifies compilation only, not rendering-path activation. No Unity editor, player or GPU workload was launched by this source verification. The subsequent 235140 runtime attempt did not activate Forward and cannot validate this proposed repair.

After adding the unsupported-pipeline guard, offline managed compilation again passed for 119 Runtime and 25 Editor files with zero warnings/errors. The separate forward-guard-managed-compile.json records that source snapshot. No runtime/GPU test was performed for the guard by the source-audit agent.