Page MenuHome

UI: add option to render preview range instead of full range
AcceptedPublic

Authored by Andrew Charlton (Scaredyfish) on Feb 16 2020, 2:46 AM.

Details

Summary

Currently Blender has the option to either:

  • Render the full frame range of the scene
  • Viewport render the full frame range of the scene
  • Viewport render a preview range

This revision adds an option in Output Properties to render the preview range.

This is useful because when the timing of the scene is already determined, you would have to overwrite that frame range in order to do a test render of only a portion of it, thus losing the information about when the scene is supposed to end. It's analogous to having to change your scene's resolution, rather than having the "render region" option.

Diff Detail

Repository
rB Blender
Branch
render-preview-range (branched from master)
Build Status
Buildable 7357
Build 7357: arc lint + arc unit

Event Timeline

I've found myself wanting this feature, when I want to test render a section of my animation, but I don't want to mess with the range of the full scene. Hopefully you agree this is a useful option to have.

@Andrew Charlton (Scaredyfish) Press P in timeline editor to select preview range, than click 3D view eitor > View > Viewport Render Animation to render preview range. hope that can help you.

@Leroy (Leroy) That would be a viewport render, not an actual render.

William Reynish (billreynish) requested changes to this revision.EditedFeb 18 2020, 9:35 PM

Thanks for submitting a patch.

First, the basic idea of this feature overall seems reasonable. I know other timeline-based apps often have the ability to only export a subset of the full scene length, and since we already have a preview range feature, I think this makes sense.

As for the details, there are some things that seem a little inelegant that we might be able to do nicer - at least there are some questions to consider.

  • When this option is enabled, I wonder if we should show the preview range in the output Dimensions panel then? Similar to how we show those values in the Timeline with Use Preview Range enabled.
  • We could make it a bitflag-enum so it's clearer what happens when it's off. It could be 'Time Span: [Scene Length / Preview Range].
  • Small note that we use capitalized style for properties. So it would be 'Render Preview Range' - although if you make the above changes that name is obviously moot.

Here's an image of the UI reworked a bit:

Feel free to ask any questions.

This revision now requires changes to proceed.Feb 18 2020, 9:35 PM

I find a bit strange that we can preview range and render that preview, so ultimately that is not a preview range but more an "alternative" frame range. Then from the user point of view, how can you tell them apart?

For example, if you link a scene strip from a scene that has "use preview range" on, which range do you use? the scene length or the preview range? Same for view layers in the composite.

I find a bit strange that we can preview range and render that preview, so ultimately that is not a preview range but more an "alternative" frame range. Then from the user point of view, how can you tell them apart?

Agree it can be a source of confusion. But it's not different than the existing preview range for animators, just extended to also work for lighting and rendering tasks. There is some visualization in the timeline to show the preview range.

For example, if you link a scene strip from a scene that has "use preview range" on, which range do you use? the scene length or the preview range? Same for view layers in the composite.

You would only use the preview range for the current / top-level scene, anything else seems unpredictable. For compositing there should be no issue, the current scene already dictates the frames for those.

For me command line renders are less clear, using either -a or the calling the animation render operator from a script. Probably you would not want the preview range to be rendered in those cases, and at least for the operator that will happen now.

In some other software it's called a 'work area' - as in "this is what I'm currently working on, and it's the region I want to playback and render". Perhaps a change in terminology to something similar would help.

For me command line renders are less clear, using either -a or the calling the animation render operator from a script. Probably you would not want the preview range to be rendered in those cases, and at least for the operator that will happen now.

Good point.

Andrew Charlton (Scaredyfish) edited the summary of this revision. (Show Details)

This implements William's suggestions. Still thinking about how best to handle command line rendering.

I guess the simplest solution would be to just not use the preview range in background mode (if (G.background)).

We could also add a property to the animation render operator that says to use the preview range or not, and then only enable that for the menus and shortcuts. But I don't see that as really a better solution.

release/scripts/startup/bl_ui/properties_output.py
135–141

text = " -> text="

source/blender/makesrna/intern/rna_scene.c
7362

Change span -> range, for consistency.

The label for properties should also be shorter and fully capitalized.

  • Change use_preview_range_for_render to render_time_span
  • Render full scene range if in background mode
  • rename render_time_span to render_time_range
  • Use scene length for background renders
Andrew Charlton (Scaredyfish) marked 2 inline comments as done.Tue, Mar 3, 8:38 AM
Andrew Charlton (Scaredyfish) added inline comments.
release/scripts/startup/bl_ui/properties_output.py
135–141

Removed, as the property now uses the default text

Brecht Van Lommel (brecht) added inline comments.
source/blender/editors/render/render_internal.c
364–365

Suggest to change code like this:

const int start_frame = (G.background) ? SFRA : RSFRA;
const int end_frame = (G.background) ? EFRA : REFRA;

There's no need to define the variables earlier, and might as well use more readable names.

Andrew Charlton (Scaredyfish) marked an inline comment as done.

Addressing Brecht's comments

Andrew Charlton (Scaredyfish) marked an inline comment as done.Tue, Mar 10, 9:04 AM
This revision is now accepted and ready to land.Tue, Mar 17, 7:59 PM