The current docs, for reference https://docs.rs/bevy/latest/bevy/prelude/struct.Camera.html. I'm in favor of this direction. The important part is that the existing 2d/3D cameras are still called "cameras".

I would like if we could also take this opportunity to rename the Camera::hdr field to something that doesn't imply HDR output to an HDR monitor.

@cart may or may not have thoughts on this based on the discussions around splitting and/or renaming Camera a month ago, starting here. My understanding was that he overall likes Camera as the defining and driving type for cameras, e.g. Camera2d "is a" Camera, and that it'd be good for people to think of it that way. I feel like renaming Camera to RenderSurface moves away from the concept of what people think of as a "camera" a bit, for better or for worse. Although the two are heavily related of course.

Personally, I would be in favor of the rename. I think RenderSurface is more fitting and accurate in this case, and the reasoning listed in this PR makes sense. I also just find the semantics of Camera and the associated compositional inheritance pattern re: Camera2d and Camera3d to be somewhat confusing currently.

I also just find the semantics of Camera and the associated compositional inheritance pattern re: Camera2d and Camera3d to be somewhat confusing currently.

Agreed, a camera entity currently has multiple Camera_ components, which is a bit odd.

My understanding was that he overall likes Camera as the defining and driving type for cameras, e.g. Camera2d "is a" Camera, and that it'd be good for people to think of it that way.

To me Camera is more like the "film" than the "camera". Camera (or RenderSurface) doesn't "capture" anything, it's just the surface the camera films onto, which we can then stack and composite. Camera3d and Camera2d make total sense to me as "cameras", they are the components that drive "capturing" the ECS, either by rendering 2d, or 3d entities.

Looking at the linked discussion, I don't think this change runs amok of Cart's reasoning - the fields are still monolithic and kept together, it's more about giving this a more accurate name for how it is already being used, and make it more obvious to newcomers how it is intended to be used.

e..g if I start a new project and search for a Camera component, I would see the multiple camera types, in addition to the Camera. After this change, only the actual "cameras" would show up. Additionally, thinking about what this would look like in the editor, I keep coming back to the idea of UX that allows you to reorder the RenderSurfaces on each render target. The name RenderSurface better conveys that you aren't shuffling and resizing cameras, you are modifying the surfaces that are rendered to, from cameras or otherwise. E.g. a compute shader, or 3rd party UI like bevy_egui might want to use a RenderSurface that can be ordered relative to everything else.

The film analogy is 🤌

I don't outright hate it (as it does resolve the Camera vs Camera2d concerns), but I do have a number of sticking points that make it feel like a major downgrade to me:

1. Camera to me does not feel like the "film". RenderTarget feels like the film (although the line is blurry, especially for the hdr field). The majority of Camera feels like the "camera" domain to me: selecting what film to write to (render target), selecting what lenses / filters / views of the world to use (CameraRenderGraph), choosing what part of the film is exposed (viewport), choosing whether or not the aperture is open (is_active), etc. Much like a camera, you can take out the film and put it in another camera (using render targets across multiple cameras, defining the order the cameras render in).
2. RenderSurface feels way too ambiguous with RenderTarget. These both read as "the thing you render to" to me. People will find this confusing.

To me, it seems like the right "conceptual framing" is for something that has Camera to "be a camera". CameraRenderGraph is a bit like configuring the lens and choosing where to point. If you have those two things you are ready to film with your camera!. Camera2d and Camera3d are just the stock configurations with presets you buy off the shelf.

If Camera was a base class, I don't think we would be having this conversation. This whole conversation seems like resistance to the "required components / inheritance by composition" idea. And that is concerning because we have been using this pattern elsewhere (ex: MaterialNode requires Node, ImageNode requires Node, etc).

The concern that people will reach for an "empty" base Camera (ex: missing a lens) is reasonable. But I don't think the best solve to that problem is contorting the design to make less sense. I think our "camera" just needs a warning light when you try to film without a lens.

Thanks for the great explanation! How would you prefer to see this resolved? Professionals buy a camera expecting to also need to give it a lens, so how do we create that expectation for Camera? Documentation?

I think the "warning light" should be a "warning log entry".

triage: Has merge conflicts, received SME feedback. Probably needs to be closed and converted into a discussion where the design can be further discussed.