Skip to content

3d coordinates,backgroundfixes (reverse-z) - #266

Merged
tychedelia merged 4 commits into
processing:mainfrom
tychedelia:camera-fixes
Nov 10, 2026
Merged

tychedelia merged 4 commits into
processing:mainfrom
tychedelia:camera-fixes

Conversation

@tychedelia

Copy link
Copy Markdown
Member

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 background from 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 background calls that aren't the first graphics command in a frame. In other words, a mid-draw call to background results 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:

  • The projection is now reverse-z, so 2D layer ordering (which rides on the draw index) no longer collapses against the clear. This is the actual fix for translucent 2D draws disappearing after a per-frame background().
  • The y flip mirrors triangle winding, so every pipeline (PBR, particles, points) now sets a clockwise front face. Culling and two-sided lighting behave as before.
  • Like Processing java, every frame starts with a cleared depth buffer. Depth is kept across mid-frame flushes within a frame so a readback in the middle of draw() doesn't disturb 3D occlusion.
  • Geometry that has used any translucent vertex colour stays in the blended phase rather than being promoted to opaque by a fully opaque fill().

@tychedelia
tychedelia requested a review from catilac November 9, 2026 19:57
@github-actions

github-actions Bot commented Nov 9, 2026 •

Copy link
Copy Markdown

Visual regression: 19 changed of 43 cases

case status detail
particles_noise ❌ changed 6.26% of pixels differ
py_particles_noise ❌ changed 6.28% of pixels differ
py_blend_modes ❌ changed 35.2% of pixels differ
py_curves ❌ changed 8.92% of pixels differ
py_custom_material ❌ changed 2.58% of pixels differ
py_flocking ❌ changed 0.12% of pixels differ
py_flocking_duck ❌ changed 3.53% of pixels differ
py_flocking_gpu ❌ changed 16.52% of pixels differ
py_particles_density ❌ changed 11.46% of pixels differ
py_particles_gpu_surface ❌ changed 7.46% of pixels differ
py_particles_gpu_surface_lit ❌ changed 2.93% of pixels differ
py_particles_points ❌ changed 6.53% of pixels differ
py_particles_scatter_volume ❌ changed 0.46% of pixels differ
py_particles_sphere ❌ changed 12.72% of pixels differ
py_particles_stress ❌ changed 100% of pixels differ
py_particles_surface ❌ changed 5.48% of pixels differ
py_primitives_2d ❌ changed 0.19% of pixels differ
py_shapes ❌ changed 0.7% of pixels differ
py_style_stack ❌ changed 1.52% of pixels differ

If these changes are intentional, add the deliberate-rendering-change label.

baseline b0feb71b4d · adapter llvmpipe (LLVM 20.1.2, 256 bits) (Vulkan, Mesa 25.2.8-0ubuntu0.24.04.4 (LLVM 20.1.2))

Open the visual report · workflow run

@tychedelia
tychedelia merged commit 94daefc into processing:main Nov 10, 2026
4 of 5 checks passed
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