Sprites not being rendered with translation.z < 0.0

[juliohq]

Bevy version

0.11

[Optional] Relevant system information

`{ name: "AMD Radeon RX 560 Series", vendor: 4098, device: 26607, device_type: DiscreteGpu, driver: "AMD open-source driver", driver_info: "2023.Q2.3 (LLPC)", backend: Vulkan }`

What you did

Just changed the Z axis of a Transform translation to something < 0.0.

What went wrong

It doesn't render the sprite.

Additional information

Some examples with a tilemap (but also doesn't work for regular sprites):
Z = 0.0:

Z < 0.0:

[alice-i-cecile]

Note that this previously worked in Bevy 0.10.

[Selene-Amanita]

This is intended behavior:

• the default for Camera2dBundle is to have a z-coordinate of 999.9 and a far (in projection) of 1000., so all sprites with a z-coordinate < 0.1 won't be rendered
• same for the default of OrthogonalProjection, far has value 1000.
• this was "working" in 0.10 because frustum culling was ignored for sprites, it was introduced with Add Aabb calculation for Sprite, TextureAtlasSprite and Mesh2d #7885

It is a problem though because many people expect negative z-values to work out of the box.

Proposed changes:

• Make the default far value equal to 2000., so z-values between -1000.1 and 999.9 work?
• Maybe change the default z-value from 999.9 to 1000 too. My guess is that it was set to this value so stuff at a z value close to 0., but slightly negative because of rounding errors, would still show up. This "failsafe" wouldn't be necessary anymore.

Also, #7885 is a breaking change and should be mentioned in the migration guide! (I just added the Breaking Change label to it)

[opstic]

Sorry about that, this was mentioned in #3944 (comment) before already, so I tested with the default Camera2dBundle before the AABB pull request, but it worked the same way (due to the default far value of 1000.. and default z of 999.9 as mentioned in @Selene-Amanita's comment), thus I didn't take notice.

@alice-i-cecile
What can I do to add an entry in the migration guide? (Since 0.11 has already been released)
Or are there other things I can do to fix this issue?

[Selene-Amanita]

@opstic I think the behavior changes only for sprites (/2d meshes/texture atlases) with a z<0.1 in 0.11.0 compared to 0.10.1, for the default camera transform, and it also changes for people who don't use the default camera transform.

The migration guide can be edited on the bevy-website repo, see a PR I made to add missing information: bevyengine/bevy-website#700

[cart]

@Selene-Amanita

Proposed changes: [ .. ]

I'm on board for both of these. People do like negative z values. And the "near zero failsafe" stuff seems like it wouldn't be necessary anymore. If we're going to support a -1000 to 1000 range, we just need to make sure it doesn't clip on the exact 1000 and -1000 values (both in shaders from the view projection and from frustum culling on the cpu) .

Migration Guide

Given that we're considering this a "bug", we probably shouldn't update the migration guide.

[Selene-Amanita]

Given that we're considering this a "bug", we probably shouldn't update the migration guide.

The fact that negative values don't show up is confusing and that's what this issue is about, but from my perspective, by introducing frustum culling for 2d objects, #7885 is a breaking change. Code that "worked" before, even if it technically should never have, doesn't anymore in 0.11, so that should be mentioned in the migration guide.

[cart]

Maybe worth calling out in the migration guide to make people aware. But idk if encouraging people to migrate their "valid but regressed" logic to something that we plan on "silently" fixing (as in, it will get picked up in a patch release) is the right call.

I guess as long as we call out our intent to "fix" in the migration guide, thats fine.