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

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

Details

Reviewers

Bastien Montagne (mont29)
Sergey Sharybin (sergey)

Summary

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 script_that_loads_a_blend.py -a

Diff Detail

Repository

rB Blender

Branch

TEMP-FRAME-RANGE-FIX

Build Status

Buildable 786
Build 786: arc lint + arc unit

Event Timeline

Campbell Barton (campbellbarton) created this revision.Aug 30 2017, 3:52 AM

Campbell Barton (campbellbarton) edited the summary of this revision. (Show Details)Aug 30 2017, 4:01 AM

Campbell Barton (campbellbarton) added reviewers: Bastien Montagne (mont29), Sergey Sharybin (sergey).

Campbell Barton (campbellbarton) added a project: BF Blender.

Move reset into a callback so we can ensure it always runs

Campbell Barton (campbellbarton) edited the summary of this revision. (Show Details)Aug 30 2017, 4:24 AM

Campbell Barton (campbellbarton) edited the summary of this revision. (Show Details)Aug 30 2017, 4:30 AM

Campbell Barton (campbellbarton) edited the summary of this revision. (Show Details)

Campbell Barton (campbellbarton) mentioned this in T52583: Background rendering with frame jump and sequencer is broken.Aug 30 2017, 4:33 AM

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.

source/blender/blenkernel/intern/blender.c
294	Even though not an issue currently, shouldn't it check against NULL funcpointer before trying to call it?

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.