Description
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:
Camera
to me does not feel like the "film".RenderTarget
feels like the film (although the line is blurry, especially for thehdr
field). The majority ofCamera
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).RenderSurface
feels way too ambiguous withRenderTarget
. 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)