update OrthographicProjection/Camera2dBundle default implementations

[Laocoon7]

Objective

I have seen or heard of at least 3 instances in the last week of people asking for help with things not appearing in their world due to Camera2dBundle::default() using a different orthographic projection settings than OrthographicProjection::default().
This causes many issues were objects don't display as expected when updating values inside the projection field (such as ScalingMode).
I say unexpected because:

commands.spawn(Camera2dBundle {
  transform: Transform::from_translation(Vec2::splat(10.0).extend(0.0)),
  ..Default::default()
});

commands.spawn(Camera2dBunde {
  transform: Transform::from_translation(Vec2::splat(10.0).extend(0.0)),
  projection: OrthographicProjection {
    ScalingMode: ScalingMode::WindowSize(200.0),
    ..Default::default()
  }
  ..Default::default()
});

Most people would not expect to be required to manually set the near / far fields after using Default::default().

Solution

Default OrthographicProjection.near to the value of -1000.0
This would bring the default orthographic projection into line with what is expected from most 2d cameras. I think OrthographicProjection should treat 2d as first class, and 3d should specify their near value at 0 if they don't want to see behind them.

Camera2dBundle could be changed to not override the near/far values in it's default implementation.
Camera2dBundle::new_with_far() would need to be discussed? and probably just left alone
examples/3d/orthographic.rs should be fine, however we may want to set near back to 0 for this so that one cannot see behind them in a 3d environment?
examples/3d/pbr.rs same as other examples
examples/3d/many_lights.rs same as other examples

---

Changelog

Changed

OrthographicProjection::default() now has a near value of -1000.0 from 0.0 bringing it into parity with expected results when building a Camera2dBundle

Migration Guide

Verify any OrthographicProjections built using ..Default::default() have your expected near field set to the value you would like.

[aevyrie]

It seems kinda weird to me for a 3d ortho cam to render things behind it. I've seen that cause bugs as well, namely in picking and rendering, because people expect the camera near plane to be at the same position as the camera origin, especially in 3D. E.g.: aevyrie/bevy_mod_picking#209 (comment)

Maybe it makes sense for us to have different camera projection types for ortho 2d and 3d? We could then warn if a 2d camera has a 3d projection component, or vice versa. Having a different projection type in Camera2dBundle would solve the issue you mention, where the bundle default is different from the component default:

commands.spawn(Camera2dBundle {
  transform: Transform::from_translation(Vec2::splat(10.0).extend(0.0)),
  ..Default::default()
});

// produces the same OrthographicProjection2d as below:

 commands.spawn(Camera2dBunde {
  transform: Transform::from_translation(Vec2::splat(10.0).extend(0.0)),
  projection: OrthographicProjection2d {
    ScalingMode: ScalingMode::WindowSize(200.0),
    ..Default::default()
  }
  ..Default::default()
});

As it stands, I think the proposed change would just end up causing the inverse problem for 3D users.

[Laocoon7]

I agree the inverse problem could occur, however, the code for a 3D orthographic perspective is far more likely to be scrutinized.

I'm willing to find a proper replacement, although I'm not sure more perspectives is the answer. This change was more motivated by multiple people having issues with objects not rendering, and hopefully making it better for the person new to bevy.

[aevyrie]

the code for a 3D orthographic perspective is far more likely to be scrutinized.

What makes you say that? The code and usage are effectively identical. Changing the defaults is just pushing the errors onto 3d users. From a quick search, it looks like Godot, Unreal, and Unity all use 0.0 or 0.01 as their default 3d ortho near clipping planes, so this would be a pretty surprising divergence from norms.

Current behavior of default impls is definitely a footgun for 2D users, but this looks more like a design problem than a problem with the default values. It seems to me that 2D ortho and 3d ortho have different semantic meaning, which could be a good argument for a split type. There is also an ongoing discussion in the math channel in discord, about improving bevy's Transforms, and potentially even having dedicated 2D transforms. This would certainly play into issues like this, where in 2d, the Z axis doesn't have the same meaning as in 3D.

The other reason to avoid changing the defaults as a solution is that this seems likely to become an issue that bounces back and forth, where 3D users want to change the default to 0.0, and we are back to the same problem with 2D. 🙂

[aevyrie]

It looks like there are a number of open issues/PRs related to this. Notably:

• Split OrthographicProjection::default into 2d & 3d #9915
• Explain Camera2dBundle.projection needs to be set carefully #11115

Additionally, it looks like the change you made here has already happened once, and I assume was reverted:

• Update defaults for OrthographicProjection #9537

Yup, looks like this exact change was made, then reverted due to how it would effect 3d:

• Revert change to default OrthographicProjection #9876

[Laocoon7]

the code for a 3D orthographic perspective is far more likely to be scrutinized.

What makes you say that?

This is worded better.

It looks like there are a number of open issues/PRs related to this. Notably:
I had searched, however apparently I didn't do such a good job..

As this has already been reverted, I'll close this and will probably drop in on the discussions on discord.

[aevyrie]

@Laocoon7, thanks for the link, I think I understand your point a bit better. Sorry to be the bearer of bad news, it looks like this issue is deceptively tricky to get right.