Sequencer strips ignore drivers on rendering (works in playback) #26560

New Issue

Daniel Salazar · 2011-03-21T06:29:32+01:00

Daniel Salazar commented

2011-03-21 06:29:32 +01:00

Duplicates: #27788

%%%play animation on provided file. see how the color is driven by the cube's zloc
now render an animation. see how animation is stuck in one color

cheers%%%

**Duplicates**: #27788 %%%play animation on provided file. see how the color is driven by the cube's zloc now render an animation. see how animation is stuck in one color cheers%%%

Daniel Salazar commented

2011-03-21 06:29:32 +01:00

Changed status to: 'Open'

Joshua Leung commented

2011-03-21 11:02:12 +01:00

%%%Clarification of the problem:
When the file is loaded, scrubbing the timeline shows the color strip's color being affected by the driver (the strip in the sequncer, the property, and the sequencer preview all show the color changing).

Once the scene is rendered (animation render), the strip adopts a color (it looks like the one that was active when the rendering started) and won't change again until the file is reloaded. By "won't change again", I mean that although the strip display in the sequencer and the property still change, the sequencer preview (and the rendered clip) both show only a single color (vs color changing in response to the driver).

Attempted fixes I've tried:

I firstly checked whether it was just a case of something that relied on a RNA update call, which could be hacked around by inlining the update code in the setter for the color. This caused crashes if loading the file at startup (i.e. loading the file with blender from the filesystem directly)
Enabling all instances of places where animation updates for stuff affecting the sequencer, forcing driver updates too (i.e setting those to ADT_RECALC_ALL)

Since it seems that the animation system side is functioning fine (properties update ok), I suspect it might have something to do with some imbuf locking tricks that sequencer uses when it thinks something won't change. Leaving for a sequencer guru to hack...%%%

%%%Clarification of the problem: When the file is loaded, scrubbing the timeline shows the color strip's color being affected by the driver (the strip in the sequncer, the property, and the sequencer preview all show the color changing). Once the scene is rendered (animation render), the strip adopts a color (it looks like the one that was active when the rendering started) and won't change again until the file is reloaded. By "won't change again", I mean that although the strip display in the sequencer and the property still change, the sequencer preview (and the rendered clip) both show only a single color (vs color changing in response to the driver). --- Attempted fixes I've tried: 1) I firstly checked whether it was just a case of something that relied on a RNA update call, which could be hacked around by inlining the update code in the setter for the color. This caused crashes if loading the file at startup (i.e. loading the file with blender from the filesystem directly) 2) Enabling all instances of places where animation updates for stuff affecting the sequencer, forcing driver updates too (i.e setting those to ADT_RECALC_ALL) Since it seems that the animation system side is functioning fine (properties update ok), I suspect it might have something to do with some imbuf locking tricks that sequencer uses when it thinks something won't change. Leaving for a sequencer guru to hack...%%%

Daniel Salazar commented

2011-03-21 11:04:36 +01:00

%%%when you clear cache after rendering the preview starts working again%%%

Daniel Salazar commented

2011-03-21 11:06:05 +01:00

%%%by clearing the cache I mean hit the Refresh Sequencer button%%%

Ton Roosendaal commented

2011-03-21 17:00:25 +01:00

%%%Maybe Peter can help!%%%

Daniel Salazar commented

2011-03-21 17:11:27 +01:00

%%%Ive attached SequencerDriversRand.blend. In it Ive modified the driver to print a random value every time it runs, and guess what, it never stops printing right after opening the blend file!%%%

Lukas Tönne commented

2011-03-21 17:27:50 +01:00

%%%After a quick debugging session we came to the conclusion that the sequencer does not do scene updates before rendering, probably because it was assumed that scene properties have no influence on the sequencer outcome, but not taking drivers into account. I found this little piece of code excluded in sequencer.c: seq_render_strip_stack, which was apparently meant to do just that, but disabled:

if 0 /* commentind since this breaks keyframing, since it resets the value on draw */

if(scene->r.cfra != cfra) {
	// XXX for prefetch and overlay offset!..., very bad!!!
	AnimData *adt= BKE_animdata_from_id(&scene->id);
	BKE_animsys_evaluate_animdata(&scene->id, adt, cfra, ADT_RECALC_ANIM);
}

endif

Looking at how regular rendering handles scene updates, i tried to make a quick patch using the scene_update_for_newframe function (attached), but since i'm not familiar with rendering or sequencer code, i have no idea if this is a proper fix.

The constant driver updates in the most basic system call are creepy, is this really intended? Potentially dangerous too i guess ...%%%

%%%After a quick debugging session we came to the conclusion that the sequencer does not do scene updates before rendering, probably because it was assumed that scene properties have no influence on the sequencer outcome, but not taking drivers into account. I found this little piece of code excluded in sequencer.c: seq_render_strip_stack, which was apparently meant to do just that, but disabled: # if 0 /* commentind since this breaks keyframing, since it resets the value on draw */ if(scene->r.cfra != cfra) { // XXX for prefetch and overlay offset!..., very bad!!! AnimData *adt= BKE_animdata_from_id(&scene->id); BKE_animsys_evaluate_animdata(&scene->id, adt, cfra, ADT_RECALC_ANIM); } # endif Looking at how regular rendering handles scene updates, i tried to make a quick patch using the scene_update_for_newframe function (attached), but since i'm not familiar with rendering or sequencer code, i have no idea if this is a proper fix. The constant driver updates in the most basic system call are creepy, is this really intended? Potentially dangerous too i guess ...%%%

Janne Karhu commented

2011-03-22 15:06:00 +01:00

%%%The main problem is the sequencer preview renderer and the fact that the sequencer can contain it's owner scene as a strip.

The piece of code Lukas found is problematic (and #iffed out) because if the animation system is evaluated when the preview render runs it becomes impossible to keyframe pretty much anything as an update call (and thus a redraw of sequencer preview) is issued immediately when a value is changed. This update then resets any user changed value.

There could of course be exceptions to make preview and actual rendering do different things, but I'd much rather see the whole preview rendering implemented properly with the job system (this is already on the todo list). However not to make things too simple using the job system for preview rendering will currently face the same kinds of problems as normal rendering with sharing the scene data between rendering and ui threads (with the added complication that users will change values that effect the preview rendering pretty much constantly while the sequencer is rendering the preview).

The nice random value example Daniel found is most probably due to the preview rendering being called from the ui drawing update call.. basically anything that sends a redraw call will also start a sequencer preview rendering. After the first render this will be very quick as the images are just read from the sequencer cache, but it's still a full preview rendering each time none the less.

So basically this is a todo item (with a solution that relates quite a bit to how normal preview rendering will be brought back), but I'd love to hear Peter's opinion on all this too before closing the report.%%%

%%%The main problem is the sequencer preview renderer and the fact that the sequencer can contain it's owner scene as a strip. The piece of code Lukas found is problematic (and #iffed out) because if the animation system is evaluated when the preview render runs it becomes impossible to keyframe pretty much anything as an update call (and thus a redraw of sequencer preview) is issued immediately when a value is changed. This update then resets any user changed value. There could of course be exceptions to make preview and actual rendering do different things, but I'd much rather see the whole preview rendering implemented properly with the job system (this is already on the todo list). However not to make things too simple using the job system for preview rendering will currently face the same kinds of problems as normal rendering with sharing the scene data between rendering and ui threads (with the added complication that users will change values that effect the preview rendering pretty much constantly while the sequencer is rendering the preview). The nice random value example Daniel found is most probably due to the preview rendering being called from the ui drawing update call.. basically anything that sends a redraw call will also start a sequencer preview rendering. After the first render this will be very quick as the images are just read from the sequencer cache, but it's still a full preview rendering each time none the less. So basically this is a todo item (with a solution that relates quite a bit to how normal preview rendering will be brought back), but I'd love to hear Peter's opinion on all this too before closing the report.%%%

Sergey Sharybin commented

2012-01-30 17:01:50 +01:00

%%%There're already several bugs related on how preview system works in tracker. It's indeed need to be re-thinked. There was already a note in our todo list which referenced to 4 different bugs. Added another one link there http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Tools#Sequence_Editor
So wouldn't consider this is really a bug, just thing which needs major improvements. Thanks for the report, but will close it now.%%%

%%%There're already several bugs related on how preview system works in tracker. It's indeed need to be re-thinked. There was already a note in our todo list which referenced to 4 different bugs. Added another one link there http://wiki.blender.org/index.php/Dev:2.5/Source/Development/Todo/Tools#Sequence_Editor So wouldn't consider this is really a bug, just thing which needs major improvements. Thanks for the report, but will close it now.%%%

Sergey Sharybin commented

2012-01-30 17:01:51 +01:00

Changed status from 'Open' to: 'Archived'

Sergey Sharybin closed this issue

2012-01-30 17:01:51 +01:00

Tobiasz Karoń commented

2013-05-23 00:44:07 +02:00

%%%I just hit this issue in 2.67a - I tried to use drivers in the sequencer and they behave lazy. They update rarely, and randomly. The values don't change while I play the sequence back in Blender almost at all.%%%

Sybren A. Stüvel referenced this issue

2023-03-30 15:30:10 +02:00

Blender development todo list -- Editors #55366

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

Sequencer strips ignore drivers on rendering (works in playback) #26560

if 0 /* commentind since this breaks keyframing, since it resets the value on draw */

endif