Upstream bevy_editor_cam

[alice-i-cecile]

Background

@aevyrie's bevy_editor_cam is a high quality, editor/CAD focused camera crate.

The Bevy Editor will need one of these, and after some prototyping work, I'm confident that this is an excellent base for what we're going to need. There's no need to NIH, when we can instead EEE ;)

Because we intend to keep the Bevy Editor source code inside of the bevyengine/bevy repo, and keep it up to date with main, we cannot rely on external crates which depend on Bevy itself due to circular dependencies and synchronization challenges.

Proposal

Given this confidence, I think we should upstream this crate now. Even before we have an official Bevy Editor, having a polished first-part editor camera crate will:

1. Provide the basis for simpler tools, such as a toggleable fly camera for inspecting the scene while the game is paused.
2. Be very helpful in examples, by allowing us to reduce boilerplate and improve the ability for users to navigate the scene using a consistent set of controls.
3. Be generally useful to end users building tooling, CAD-style software or even some forms of games.

Implementation strategy

1. Create a PR adding a new bevy_editor_camera crate, clearly crediting @aevyrie and the original crate. There will be a small amount of work required to get it compiling, but no other changes should be made in that PR.
2. Create a PR or three to use this in our example code and remove existing camera controller code. As part of this, we should add a ExampleCameraControlerPlugin, which hard-codes various inputs in a standardized way.
3. Create follow-up PRs to fix bugs, improve docs and so on in the ordinary fashion.

[alice-i-cecile]

Note for anyone tackling this: this plan is not yet blessed, even though I personally think this is a great idea. You may want to wait for that, or you can dive straight in, and help make the case that it's time.

[cart]

My one hesitance is that we'd be merging this "out of context" from an editor perspective. We're operating under the assumption that it can slot into that context, but that context doesn't actually exist yet. We have good reason to think its a good fit, given that it is "battle tested" in other contexts (and given our current prototypes). But part of me thinks "why not just wait so we can review and iterate within the context of its primary intended use case".

Only a minor hesitance though. I don't think its a huge risk. Its just one more thing we need to design / review / support, it could be staged later, and we have a lot of other stuff in the pipeline atm.

[cart]

I do endorse the path in general though. And if theres enough sentiment to kick this off now, I wouldn't stand in the way.

[IceSentry]

Yeah, I feel like I'd prefer a different name that doesn't contain "editor" in it. Something like bevy_camera_controller or something like that.

This is useful on it's own without the context of an editor. Just using it in examples would be great, but also for any users wanting some camera controls.

[alice-i-cecile]

My one hesitance is that we'd be merging this "out of context" from an editor perspective. We're operating under the assumption that it can slot into that context, but that context doesn't actually exist yet. We have good reason to think its a good fit, given that it is "battle tested" in other contexts (and given our current prototypes). But part of me thinks "why not just wait so we can review and iterate within the context of its primary intended use case".

Yeah, I feel like I'd prefer a different name that doesn't contain "editor" in it. Something like bevy_camera_controller or something like that.

I'd be on board with a bevy_camera_controllers crate. Note the plural: this camera controller won't be a good fit for something like an FPS or 2D platformer camera, and this is reasonable home for those in the future. Gate each different camera controller behind a feature flag to split the crate of course :)

[alice-i-cecile]

Consensus seems to be pretty firmly on "we should also have a fly camera that can be toggled", so I think that bevy_camera_controllers is the way to go.

[aevyrie]

The controller as designed tries very hard not to retain any state relating to transforms, all smoothing, for example, is done at the input level. This means it works with crates like big_space without any integration needed, but it also means you can run the camera controller at the same time as other controllers without them fighting for control.

The defaults and behavior are very much defaulted to engineering contexts, where expectations are going to be different from what people are used to from game editors. My hunch is that you probably want to pair this with a flycam, as mentioned, but I wanted to drop by to note that these can be running at the same time. So, you can use the mouse to quickly zoom up to things, and rotate around them, but you might want to use WASD to fly around interiors. There are some considerations for navigating interior spaces, where the defaults on this controller aren't great for, but I think those problems are pretty easy to solve, and I have some ideas. If you get to that point, I'm happy to share my thoughts. I've spent a lot of time working with 3d navigation as a user and a developer.

I also wanted to say that I think game engines and editors like blender have a few things they could learn from engineering CAD. The way you navigate spaces, use clipping planes, and default to orthographic makes designing in 3d way faster and more precise than using a flycam.