Page MenuHome

Fix T52586: Rendering a frame range no longer modifies the scene

Authored by Campbell Barton (campbellbarton) on Aug 30 2017, 3:52 AM.



With this patch - command line arguments [--frame-start, --frame-end, --frame-jump] no longer write into the scene.

Instead, they modify local variables in creator_args.c which override the scene's values (when set),
the overrides are reset on loading a new blend file or scene switching.

This resolves:

  • Setting frame range messing with sequencer rendering (reported as T52583)
  • Changes to the render in the case of scripts using the start/end frame in their operations.

Since this is an obscure bug, submitting to get second opinion.

The main down-side to this change is existing usage that relies on existing arguments modifying the scene. Setting the frame range then baking physics for eg.

Note updated patch to avoid an error when loading a blend file or switching a scene is done without command line arguments, otherwise this wont work:

blender -b foo.blend -s 1 -e 20 -a --python -a

Diff Detail

rB Blender
Build Status
Buildable 786
Build 786: arc lint + arc unit

Event Timeline

Campbell Barton (campbellbarton) edited the summary of this revision. (Show Details)
  • Move reset into a callback so we can ensure it always runs
Campbell Barton (campbellbarton) edited the summary of this revision. (Show Details)

I see the point of the fix, but yeah, think some user would loudly complain about that change… Isn’t it rather possible to add some option here to control that? Either a set of --frame-render-start/--frame-render-end/--frame-render-jump options, or a single toggle option to choose between affecting scene or not (--shallow-frame-settings ?). Such that current behavior would not change.


Even though not an issue currently, shouldn't it check against NULL funcpointer before trying to call it?

Campbell Barton (campbellbarton) abandoned this revision.EditedAug 31 2017, 5:51 AM

Why would users complain loudly?

Having 2x command line inputs feels a bit odd/redundant.

To review own patch, the main thing I don't like is how it fakes behavior, pretending to set values that are not really set - only to workaround a bug/crappy behavior. If we remove support for scenes using themselves - T52586, Then the problem mostly goes away.

The root cause of the problem is adjusting blend-file data, only to execute an operator (effectively) that may read the modified settings, causing a feedback loop.
This is such a rare problem that we can almost ignore it (scene output settings are almost never used elsewhere in the middle of the render pipeline).

I think a cleaner solution would be to not adjust scene frame ranges and have render accept an optional range.

--render-anim or --render-anim $START:$END:$STEP

Where --render-anim takes an optional argument (only needs to check if values contain 0-9/-/:).

But its not really worth spending time on if we keep previous frame range options - since this is a problem we can avoid, maybe 2.8x could use modified argument parsing but I'm not all that motivated to push for this.

So abandoning this patch.