Restrict Frame Range not being obeyed #36950

New Issue

Nick Adams · 2013-10-04T10:53:35+02:00

Nick Adams commented

2013-10-04 10:53:35 +02:00

%%%--- Operating System, Graphics card ---
Windows 7 Pro, nVidia Quadro 4000

- Blender version with error, and version that worked ---

Official BF version 2.68 (r58368)

- Short description of error ---

Restrict Frame Range does not appear to work: driven item still follows its driver even outside restricted frame range.

- Steps for others to reproduce the error (preferably based on attached .blend file) ---

The attached simplified blend file demonstrates the issue (drag the time line marker in the Graph editor):

Sphere's Z-Loc has been animated between frames 1-20.
Cube's Z-Loc is driven by sphere's Z-Loc. In general, cube correctly follows sphere as sphere moves.
BUT: Although Restrict Frame Range has been set to Start: 5, End:15, cube still follows sphere outside this frame range, even though the red driver graph shows there should be a step change at frames 5 and 15.

Expected behaviour:
a) Cube should remain static until frame 5.
b) Cube's Z-Loc should then jump to match sphere's Z-Loc, and follow sphere's Z-Loc until frame 15.
c) After frame 15, cube should stop following sphere and remain static.

%%%

%%%--- Operating System, Graphics card --- Windows 7 Pro, nVidia Quadro 4000 - Blender version with error, and version that worked --- Official BF version 2.68 (r58368) - Short description of error --- Restrict Frame Range does not appear to work: driven item still follows its driver even outside restricted frame range. - Steps for others to reproduce the error (preferably based on attached .blend file) --- The attached simplified blend file demonstrates the issue (drag the time line marker in the Graph editor): 1) Sphere's Z-Loc has been animated between frames 1-20. 2) Cube's Z-Loc is driven by sphere's Z-Loc. In general, cube correctly follows sphere as sphere moves. 3) BUT: Although Restrict Frame Range has been set to Start: 5, End:15, cube still follows sphere outside this frame range, even though the red driver graph shows there should be a step change at frames 5 and 15. Expected behaviour: a) Cube should remain static until frame 5. b) Cube's Z-Loc should then jump to match sphere's Z-Loc, and follow sphere's Z-Loc until frame 15. c) After frame 15, cube should stop following sphere and remain static. %%%

Nick Adams commented

2013-10-04 10:53:35 +02:00

Changed status to: 'Open'

Dalai Felinto commented

2013-10-04 15:02:56 +02:00

%%%bug confirmed. This goes back as far as 2.60 at least, but probably even more.
the sample file has a 'lib missing' warning, but nothing that affects the result.%%%

%%%bug confirmed. This goes back as far as 2.60 at least, but probably even more. the sample file has a 'lib missing' warning, but nothing that affects the result.%%%

Dalai Felinto commented

2013-10-12 23:48:19 +02:00

%%%Actually I don't know if it's a bug or how the features is designed to work.

Basically the modifiers are only affecting fcurves, not drivers.
attached RestrictFrameRangeWorking.blend showing the modifier in the fcurve as it was supposed to work.

@Joshua, any final say on it? If this is really the designed case I think we should hide the modifiers from the interface for drivers.%%%

%%%Actually I don't know if it's a bug or how the features is designed to work. Basically the modifiers are only affecting fcurves, not drivers. attached RestrictFrameRangeWorking.blend showing the modifier in the fcurve as it was supposed to work. @Joshua, any final say on it? If this is really the designed case I think we should hide the modifiers from the interface for drivers.%%%

Joshua Leung commented

2013-11-01 14:17:54 +01:00

%%%This really isn't working "as intended" or any logical way.

It took a bit of digging to figure out what is actually going wrong here:

Currently, with no keyframes or modiifers, drivers default to using the "evaltime" as their value. This is done by setting "cvalue" to this value before doing any evaluation of keyframes or modiifers
The restrict range option simply restricts when the F-Modifier is allowed to write/overwrite the results of cvalue.
This bug occurs when cvalue already has some non-zero value, but the modifier is not producing any output to overwrite this

It's not sufficient to have unapplyable modifiers clearing cvalue when they can't run (i.e. this will break the ability to use mutliple modifiers for different segments), or to not set cvalue at all (i.e. this breaks when a generator is set to additive on top of the raw results). Any other solutions I've missed?%%%

%%%This really isn't working "as intended" or any logical way. It took a bit of digging to figure out what is actually going wrong here: - Currently, with no keyframes or modiifers, drivers default to using the "evaltime" as their value. This is done by setting "cvalue" to this value before doing any evaluation of keyframes or modiifers - The restrict range option simply restricts when the F-Modifier is allowed to write/overwrite the results of cvalue. - This bug occurs when cvalue already has some non-zero value, but the modifier is not producing any output to overwrite this It's not sufficient to have unapplyable modifiers clearing cvalue when they can't run (i.e. this will break the ability to use mutliple modifiers for different segments), or to not set cvalue at all (i.e. this breaks when a generator is set to additive on top of the raw results). Any other solutions I've missed?%%%

Joshua Leung commented

2013-11-04 05:18:46 +01:00

%%%Fixed in svn.%%%

Joshua Leung commented

2013-11-04 05:18:46 +01:00

Changed status from 'Open' to: 'Resolved'

Joshua Leung closed this issue

2013-11-04 05:18:46 +01:00

Nick Adams commented

2013-11-09 11:49:42 +01:00

%%%Does 'Fixed' mean the driver will now work as described in "Expected behaviour" above? If so, that's fantastic and many, many thanks! :-)

It will now be very easy to make my robot appear to pick up an object and put it down elsewhere, simply by restricting the frame range during which the object follows the robot hand's location. %%%

%%%Does 'Fixed' mean the driver will now work as described in "Expected behaviour" above? If so, that's fantastic and many, many thanks! :-) It will now be very easy to make my robot appear to pick up an object and put it down elsewhere, simply by restricting the frame range during which the object follows the robot hand's location. %%%

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Restrict Frame Range not being obeyed #36950