Skip to content

Using a raw Camera component is a footgun #19299

Open
@alice-i-cecile

Description

@alice-i-cecile

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.

Originally posted by @cart in #16248 (comment)

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-RenderingDrawing game state to the screenC-UsabilityA targeted quality-of-life change that makes Bevy easier to useD-ModestA "normal" level of difficulty; suitable for simple features or challenging fixesS-Needs-DesignThis issue requires design work to think about how it would best be accomplishedX-ContentiousThere are nontrivial implications that should be thought through

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions