Repository navigation
3d coordinates,backgroundfixes (reverse-z) - #266
Merged
Merged
Conversation
|
Visual regression: 19 changed of 43 cases
If these changes are intentional, add the baseline |
catilac
approved these changes
Nov 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Previously, 2d's coordinate system was classic processing origin top-left and y down. 3D was bevy's native frame, origin at the canvas center and y up. Every ported 3D sketch carried manual flips to bridge the two, which is what the removed comments say: "the world is y-up, so the y of every position and direction is flipped", "rotations about x run the other way in the y-up world". etc. Y down makes sense for parity with 2d and makes some math easier for artists. We are now matched 1:1 with processing.
Additionally, we change our approach to
backgroundfrom attempting to draw an NDC quad to just doing a regular clear. The quad approach worked for 2D but had all kinds of unfortunate edge cases in 3D, especially when paired with custom projections, etc.What this means in practice is that we use the gpu clear for opaque solid background and insert a flush for any
backgroundcalls that aren't the first graphics command in a frame. In other words, a mid-draw call tobackgroundresults in its own pass. This is rare and so I think a reasonable trade-off for correctness.A few smaller things fell out of the above:
background().draw()doesn't disturb 3D occlusion.fill().