This is a very good initiative, we usually need to take different renders at different resolutions and aspect ratios for our static renders, and this would make it WAAAAY easier :)

Renaming the panel to "Resolution override"

Harbormaster completed remote builds in B14990: Diff 37918.Jun 5 2021, 9:31 PM

Colin Marmond (Kdaf) edited the summary of this revision. (Show Details)Jun 5 2021, 9:32 PM

Fix render init resolution error

Harbormaster completed remote builds in B14994: Diff 37924.Jun 6 2021, 1:43 PM

Evan Wilson (EAW) awarded a token.Jun 7 2021, 5:05 AM

Adding this kind of override adds the possibility for confusion and makes it more difficult to understand scene setups. But I know this is something that users have asked for and see how it is helpful.

This needs to do a better job of communicating things. The output properties should somehow indicate they are overridden.
The camera panel is missing presets.
It may be better to keep "size" global, so that you can lower the entire resolution?
Aspect ratio may best stay global as well? The choice of that depends on the output file format, I don't see the need to override it per camera.
Border rendering may need to be per camera, though it's annoying to have to duplicate that too.
You can't update camera parameters automatically whenever scene resolution changes. Cameras may be linked datablocks which can not be modified. For the same reason, you can't read just the camera resolution like this in Cycles and assume it is correct. Syncing for user convenience is fine, when a users changes something, but not for correctly retrieving the resolution.
For animation rendering with camera switching, this can cause problems. Writing a video file with resolution changing over time is not going to work, and may need an error message if none exists. Currently resolution is marked as non-animatable avoiding that, but this adds an indirect way.
This is probably going to break many add-ons and scripts, it will need to explained in the Python API release notes.
Don't duplicate logic so much, add utility functions to get the effective resolution from a scene. That also lets you check access to scene xsch / ysch is properly replaced everywhere, it's not clear now if all cases are handled. Might also be worth adding to the Python API.

release/scripts/startup/bl_ui/properties_data_camera.py
212	Capitalize "override".
source/blender/makesrna/intern/rna_camera.c
705	Booleans start with `use_`, and "custom" should be changed to "override" to match terminology in the UI.
762–804	These properties could be grouped in a nested struct similar to DoF.

This revision now requires changes to proceed.Jun 7 2021, 1:58 PM

rsgnz (rsgnz) added a subscriber: rsgnz (rsgnz).Jun 8 2021, 1:29 PM

The aspect ratio is different for each camera, because of the lens. The idea is to make possible to insert in blender a gopro like camera next to an anamorphic like camera. For that purpose, it would be useful to have pixel aspect override, no ?

I may not understand well the purpose of the pixel aspect.

I'm wondering whether we should go the complication root of render settings override (not to be confused with the override system :) instead of moving resolution to Camera. Here is some though process:

Think it fits mental model better, and makes it more straightforward to investigate and create camera setups.
It does not add any code complexity compared to the "override" behavior: settings override means data from the camera is already available.
Compositor already knows output resolution, and the scene settings simply crops that. It could be more flexible and straighforward to use compositor's resolution for file IO and such.
Sequencer would still need own settings, as you might want to make sequencer setup without any camera in the sequencer's scene. But think it could be done as a nicely reusable data structure/accessor/whatever is needed.

Think it worth investigating such design change before committing to the complexity (both code and mental) of the settings overrides.

In D11511#296986, @Colin Marmond (Kdaf) wrote:

The aspect ratio is different for each camera, because of the lens. The idea is to make possible to insert in blender a gopro like camera next to an anamorphic like camera. For that purpose, it would be useful to have pixel aspect override, no ?

I may not understand well the purpose of the pixel aspect.

Pixel aspect does not simulate anamorphic lenses, you will not get e.g. anamorphic boken with that. It's more a setting to output to certain legacy video file formats. Though for simplicity it may be best to just have the pixel aspect available in the camera.

Following what @Sergey Sharybin (sergey) said, a reflexion about the resolution (and some settings that are currently linked to compositor, sequencer, and rendering) is highly prefered than directly code.

Not sure why you abandoned this revision, since there's no design decision made yet. We can keep discussing the best solution here.

Moving the settings to the camera entirely is an interesting option. However it's not fully clear to me how the sequencer and compositor will work then, and what the trade-offs are.

The sequencer and compositor are not that fundamentally different I think, for both you might load or procedurally generate images without relation to the scene and camera. And both compositor nodes and sequences strips do already use the render resolution, not just for output.

For example the Mask or Texture nodes can generate images at scene resolution. Often the purpose of that is to match the resolution of render output, and it would be fine to get it from the active camera in such cases. But when there is no camera or the camera is unrelated to the compositor or sequence, it's not so obvious how that would be communicated in the UI.

In some way you could turn it around. Get the resolution from the camera by default, but then having an option to override that for the compositor or sequencer? Not sure it's ideal either.