Skip to content

Revert "Resolve one compositing space per camera stack (#25481)" - #25676

Open
beicause wants to merge 2 commits into
bevyengine:mainfrom
beicause:revert-camera-stack-check
Open

Revert "Resolve one compositing space per camera stack (#25481)"#25676
beicause wants to merge 2 commits into
bevyengine:mainfrom
beicause:revert-camera-stack-check

Conversation

@beicause

@beicause beicause commented Sep 3, 2026

Copy link
Copy Markdown
Member

This reverts commit 8a83227 (#25481).

Objective

There is currently minor bugs in the camera stack resolution. Although it could be fixed by #25646 and #25661, I still have some reasons to want to revert it for now:

  1. To make the behavior of multi-cameras and main textures explicit and configurable, in #24280 I plan to store main textures in entities, and the shared behavior between cameras and main textures will be represented through relationships/entity references. After that, the current camera stack resolution code may need a complete rewrite and will no longer need to determine sharing based on MainTextureKey. The current special‑case code is somewhat fragile and complicated.
  2. I think the code doesn't seem worth the complexity just for a diagnostic check. And the error isn't very hard to avoid, since multi-camera is a relatively advanced use case.

cc @stuartparmenter

Solution

Revert it.

Testing

CI

@stuartparmenter

Copy link
Copy Markdown
Contributor

It isn't just a diagnostic check, and it is needed by a whole stack of PRs both currently open and to come. I'm fine improving it further and/or simplifiying it as time goes on but would rather get the two bug fix PRs in than revert this and break a bunch of the PRs already open

@beicause

beicause commented Sep 3, 2026

Copy link
Copy Markdown
Member Author

It isn't just a diagnostic check, and it is needed by a whole stack of PRs both currently open and to come. I'm fine improving it further and/or simplifiying it as time goes on but would rather get the two bug fix PRs in than revert this and break a bunch of the PRs already open

Actually, I hope we can implement a minimal HDR output MVP first and then make improvements on these smaller issues.

@stuartparmenter

Copy link
Copy Markdown
Contributor

Skipping the rendering pipeline fixes will cause real bugs and real regressions, which I've already spent months working through and addressing. I'm happy to make changes or adjust if you have specific feedback, but I don't think "ship HDR and have lots of things not work" is a good strategy.

Also we are pretty close to the actual HDR parts going in, the first of wave 3 is already up for review and the two after it are ready to go once it merges.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants