Sprites not being rendered with translation.z < 0.0 #9138
Comments
juliohq
added
C-Bug
alice-i-cecile
added
A-Rendering
|
Note that this previously worked in Bevy 0.10. |
|
This is intended behavior:
It is a problem though because many people expect negative z-values to work out of the box. Proposed changes:
Also, #7885 is a breaking change and should be mentioned in the migration guide! (I just added the Breaking Change label to it) |
Selene-Amanita
added
the
D-Trivial
|
Sorry about that, this was mentioned in #3944 (comment) before already, so I tested with the default @alice-i-cecile |
|
@opstic I think the behavior changes only for sprites (/2d meshes/texture atlases) with a The migration guide can be edited on the bevy-website repo, see a PR I made to add missing information: bevyengine/bevy-website#700 |
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) .
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 |
|
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. |
|
Made a pull request to add it in the migration guide. |
|
@cart @alice-i-cecile Another pitfall with 2D frustum culling that I saw several people encounter (for example here: https://old.reddit.com/r/bevy/comments/14x37ov/after_updating_to_011_from_0101_i_cannot_see/ and here: https://discord.com/channels/691052431525675048/1131259863775850557/1131259863775850557 but I encountered at least one other case, maybe two) is that they set the transform of the 2D camera to z=0 and it doesn't display anything (even stuff at z=0 because the bisecting plane is out of the half-space in Frustum's methods). Other proposed change: make the default z-coordinate of the camera I tested it and it works, it's a bit unconventional to have a negative |
|
Yeah that seems reasonable to me! Having a non-zero position always felt a bit weird anyway. |
# Objective - Fixes #9138 ## Solution - Calling `Camera2dBundle::default()` will now result in a `Camera2dBundle` with `Vec3::ZERO` transform, `far` value of `1000.` and `near` value of `-1000.`. - This will enable the rendering of 2d entities in negative z space by default. - I did not modify `new_with_far` as moving the camera to `Vec3::ZERO` in that function will cause entities in the positive z space to become hidden without further changes. And the further changes cannot be applied without it being a breaking change.
# Objective - Fixes #9138 ## Solution - Calling `Camera2dBundle::default()` will now result in a `Camera2dBundle` with `Vec3::ZERO` transform, `far` value of `1000.` and `near` value of `-1000.`. - This will enable the rendering of 2d entities in negative z space by default. - I did not modify `new_with_far` as moving the camera to `Vec3::ZERO` in that function will cause entities in the positive z space to become hidden without further changes. And the further changes cannot be applied without it being a breaking change.
Note that the z range is limited from `-1000` to `1000`, see bevyengine/bevy#9138
Adopted PR from dmlary, all credit to them! #9915 Original description: # Objective The default value for `near` in `OrthographicProjection` should be different for 2d & 3d. For 2d using `near = -1000` allows bevy users to build up scenes using background `z = 0`, and foreground elements `z > 0` similar to css. However in 3d `near = -1000` results in objects behind the camera being rendered. Using `near = 0` works for 3d, but forces 2d users to assign `z <= 0` for rendered elements, putting the background at some arbitrary negative value. There is no common value for `near` that doesn't result in a footgun or usability issue for either 2d or 3d, so they should have separate values. There was discussion about other options in the discord [0](https://discord.com/channels/691052431525675048/1154114310042292325), but splitting `default()` into `default_2d()` and `default_3d()` seemed like the lowest cost approach. Related/past work #9138, #9214, #9310, #9537 (thanks to @Selene-Amanita for the list) ## Solution This commit splits `OrthographicProjection::default` into `default_2d` and `default_3d`. ## Migration Guide - In initialization of `OrthographicProjection`, change `..default()` to `..OrthographicProjection::default_2d()` or `..OrthographicProjection::default_3d()` Example: ```diff --- a/examples/3d/orthographic.rs +++ b/examples/3d/orthographic.rs @@ -20,7 +20,7 @@ fn setup( projection: OrthographicProjection { scale: 3.0, scaling_mode: ScalingMode::FixedVertical(2.0), - ..default() + ..OrthographicProjection::default_3d() } .into(), transform: Transform::from_xyz(5.0, 5.0, 5.0).looking_at(Vec3::ZERO, Vec3::Y), ``` --------- Co-authored-by: David M. Lary <dmlary@gmail.com> Co-authored-by: Jan Hohenheim <jan@hohenheim.ch>
Bevy version
0.11
[Optional] Relevant system information
What you did
Just changed the Z axis of a
Transformtranslationto 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:
The text was updated successfully, but these errors were encountered: