Conflict between UiCamera and OrthographicCamera

[chrisburnor]

The current camera query for the update_post_orth system doesn't distinguish which camera is being queried. This is because both UiCameraBundle and OrthographicCameraBundle implement the exact same components, with the exception of the Frustum component on Orthographic Camera.

This leads to bugs given the different coordinate systems of different cameras. UI Cameras have origin in lower left while regular orthographic cameras origin is in the center of the screen.

Current workaround is to filter out non-UI camera via Frustum component until bevyengine/bevy#1854 is addressed.

However, given Bevy's support for multiple windows and cameras, this plugin should implement a means by which the MousePosWorld can be retrieved for any arbitrary camera.

[chrisburnor]

Brainstorming a few ways to do this:

1. Attach MouseWorldPos as a component on the Camera entity itself so that it is queryed via querying the camera.
2. Add a HashMap of different Cameras to MousePosWorld that would key on the camera entity id and have their own pos for each camera. Could also have a 'current' camera which could be used to not break existing APIs.
3. Create a new resource for choosing which camera is queried.

[joseph-gio]

I think the best solution would be to add a MainCamera marker component that you can add to your game's main camera in case you have multiple cameras. If you only have a single (non-UI) camera, this component should be optional. I think that this would allow you to disambiguate multiple cameras without compromising the ease of use that this crate aims to provide.

To allow tracking the world-local mouse position for multiple cameras concurrently, I think the best option would be to automatically add a MousePosWorld component to each camera entity in the World, and update it every frame. This way you could directly query for it in your systems without having to look it up in a HashMap.

Thoughts?

[chrisburnor]

I really like the proposal in the second paragraph. That approach is much more idiomatic to an ECS than a HashMap (and keeps everything Copy and light). I think the use case for multiple cameras is a pretty common one, given that there might be a UI and Game Camera, and perhaps even multiple game 'views' with their own cameras.

The first paragraph I think makes sense. Though it's unclear how the system should act if there is no MainCamera but there are multiple cameras. I'd suggest that failing clearly and loudly would be the right approach rather than trying to guess the right 'magic'. Therefore, I'd suggest that Res<MousePosWorld> should only be populated if exactly one MainCamera component exists.

[chrisburnor]

If I get a chance, I can work on that this week.

[joseph-gio]

No need, I've been working on it today, and it's mostly done. Thank you though :). I'll link the PR here before merging it in case you wanna give feedback.

[chrisburnor]

Added some thoughts. Feel free to reach out in discord if you want to discuss some of those in more detail.