Repository navigation
fix: CameraFrame and clustered lighting manage only their own passes - #9786
Conversation
CameraFrame replaced the frame passes of its camera with its own pass when enabled, and destroyed every frame pass of the camera when disabled, including passes added by others. It now adds its pass to the camera's frame passes, and removes and destroys only that pass, leaving the others to whoever added them. The pass updating the clustered lighting destroyed its cookie pass but not its local shadow pass. It now destroys both.
Build size reportThis PR changes the size of the minified bundles.
|
mvaligursky
left a comment
mvaligursky
left a comment
There was a problem hiding this comment.
Automated PR review by Codex (OpenAI AI agent), posted through the account holder's authorized automated review process.
Reviewed 90b19e13a against adc8b995a. No actionable findings.
The ownership changes are consistent: CameraFrame removes its pass by identity and destroys that owned instance even if another caller has already replaced the camera's pass list. Assigning the resulting list through the camera setter preserves composition/shader invalidation. Clustered-lighting teardown destroys both child passes and clears its references without destroying their shared render targets.
The intentional behavior is worth retaining: external passes left in the list keep the camera in custom-pass rendering while CameraFrame is disabled; re-enabling appends the new CameraFrame pass to that list.
Validation:
- Full unit suite: 4,389 passing, 43 pending.
- Full WebGPU/Metal suite: 4,388 passing, 39 pending.
- Declaration build, consumer type tests, and lint of all changed files passed.
- Additional browser checks on WebGL2 and WebGPU covered pre-existing external passes, passes added afterward, three disable/re-enable cycles, externally replacing the pass list, and destroying an already-disabled CameraFrame. External passes were never destroyed, each owned instance was destroyed once, and no duplicate CameraFrame passes accumulated. These checks reproduce the old ownership failures on the base.
- Renderer teardown destroyed the cookie and shadow passes once each and emptied their parent's before-pass list.
- Runtime-inspection/pixel-verification checks found 0 / 16,384 differing pixels per backend for ordinary rendering and CameraFrame with a depth prepass at two camera poses. Repeated baseline captures also matched exactly.
This branch was successfully deployed
1 participant
Fixes two frame pass owners managing passes they do not own, or not all the passes they do own.
Changes:
CameraFramenow adds its pass to the frame passes of its camera when enabled, and removes and destroys only that pass when disabled. Before, enabling replaced the passes already set on the camera, and disabling destroyed every frame pass of the camera, including passes added by others. Passes added by others now stay in the list, for whoever added them to remove. Typically the camera has no other frame passes, and the list is empty again once the camera frame is disabled, returning the camera to its own rendering.