Inserting multiple keyframes in sequencer properties is broken on x64 Windows 7 #25020

New Issue

A Saurus1 · 2010-12-03T03:42:05+01:00

A Saurus1 commented

2010-12-03 03:42:05 +01:00

%%%Open blender (Default blend) and go to the sequencer, add a scene strip and keyframe any property (say "strobe"). Now move ahead a few frames and try to drag the slider to a different value. It works, but as soon as you let go, the slider returns to the value that has already been keyframed, before you can insert a new one. Note two things:

If you insert two keyframes, you are able to move them in the graph editor and everything works fine. The value of the property that is animated seems to 'snap' back to whatever value is currently defined by the curve.
I have only experienced this on my Windows 7 computer, my XP, 32bit works as it should.

version 2.55 (sub 1), revision 33405M. Release
build date: 2010-12-01, 00:02:12
platform: Windows:64bit
binary path: C:\Users\mardgase\DOWNLO~~1\BLENDE~~1\blender.exe
build cflags: /nologo /Ob1 /J /W0 /Gd /we4013 /wd4018 /wd4244 /wd4305 /wd4800 /wd4065 /wd4267 -O2 -DNDEBUG -O2 -DNDEBUG -DWIN32 -D_CONSOLE -D_LIB -DFTGL_LIBRARY_STATIC -D_CRT_SECURE_NO_DEPRECATE
build cxxflags: /nologo /Ob1 /J /W0 /Gd /we4013 /wd4018 /wd4244 /wd4305 /wd4800 /wd4065 /wd4267 /EHsc -O2 -DNDEBUG -O2 -DNDEBUG -DWIN32 -D_CONSOLE -D_LIB -DFTGL_LIBRARY_STATIC -D_CRT_SECURE_NO_DEPRECATE
build linkflags: /SUBSYSTEM:CONSOLE /MACHINE:X64 /INCREMENTAL:NO /NODEFAULTLIB:msvcprt.lib /NODEFAULTLIB:msvcprtd.lib /NODEFAULTLIB:glut32.lib /NODEFAULTLIB:libc.lib /NODEFAULTLIB:libcd.lib /NODEFAULTLIB:libcpd.lib /NODEFAULTLIB:libcp.lib /NODEFAULTLIB:msvcrt.lib /NODEFAULTLIB:msvcrtd.lib /NODEFAULTLIB:msvcmrt.lib /NODEFAULTLIB:msvcurt.lib
build system: SCons
%%%

%%%Open blender (Default blend) and go to the sequencer, add a scene strip and keyframe any property (say "strobe"). Now move ahead a few frames and try to drag the slider to a different value. It works, but as soon as you let go, the slider returns to the value that has already been keyframed, before you can insert a new one. Note two things: 1. If you insert two keyframes, you are able to move them in the graph editor and everything works fine. The value of the property that is animated seems to 'snap' back to whatever value is currently defined by the curve. 2. I have only experienced this on my Windows 7 computer, my XP, 32bit works as it should. **** version 2.55 (sub 1), revision 33405M. Release build date: 2010-12-01, 00:02:12 platform: Windows:64bit binary path: C:\Users\mardgase\DOWNLO~1\BLENDE~1\blender.exe build cflags: /nologo /Ob1 /J /W0 /Gd /we4013 /wd4018 /wd4244 /wd4305 /wd4800 /wd4065 /wd4267 -O2 -DNDEBUG -O2 -DNDEBUG -DWIN32 -D_CONSOLE -D_LIB -DFTGL_LIBRARY_STATIC -D_CRT_SECURE_NO_DEPRECATE build cxxflags: /nologo /Ob1 /J /W0 /Gd /we4013 /wd4018 /wd4244 /wd4305 /wd4800 /wd4065 /wd4267 /EHsc -O2 -DNDEBUG -O2 -DNDEBUG -DWIN32 -D_CONSOLE -D_LIB -DFTGL_LIBRARY_STATIC -D_CRT_SECURE_NO_DEPRECATE build linkflags: /SUBSYSTEM:CONSOLE /MACHINE:X64 /INCREMENTAL:NO /NODEFAULTLIB:msvcprt.lib /NODEFAULTLIB:msvcprtd.lib /NODEFAULTLIB:glut32.lib /NODEFAULTLIB:libc.lib /NODEFAULTLIB:libcd.lib /NODEFAULTLIB:libcpd.lib /NODEFAULTLIB:libcp.lib /NODEFAULTLIB:msvcrt.lib /NODEFAULTLIB:msvcrtd.lib /NODEFAULTLIB:msvcmrt.lib /NODEFAULTLIB:msvcurt.lib build system: SCons %%%

A Saurus1 commented

2010-12-03 03:42:05 +01:00

Changed status to: 'Open'

Davis Sorenson commented

2010-12-03 07:38:31 +01:00

%%%Confirmed, 32bit Ubuntu 10.10. I would have reported this myself but I am very new to the sequencer and don't know what to expect from it yet.%%%

Ton Roosendaal commented

2010-12-03 18:41:10 +01:00

%%%This is caused by the opengl preview, it evaluates the animation system (= full drawing of shot) on every change... that then also resets values. Now how to fix that...
%%%

%%%This is caused by the opengl preview, it evaluates the animation system (= full drawing of shot) on every change... that then also resets values. Now how to fix that... %%%

Ton Roosendaal commented

2010-12-03 19:06:30 +01:00

%%%Campbell: you added a ifdef to prevent this in commit 30188 (sequencer.c)

It still happens though. I think we have a design conflict here. Scene-strips have to evaluate time, because you can move them around in sequencer.The temporary cfra is being evaluated, and then needs reset.

At this moment I wouldn't know a solution though... apart from bad hacks to not update the preview for animated values of scenes... only in insert key.

%%%

%%%Campbell: you added a ifdef to prevent this in commit 30188 (sequencer.c) It still happens though. I think we have a design conflict here. Scene-strips have to evaluate time, because you can move them around in sequencer.The temporary cfra is being evaluated, and then needs reset. At this moment I wouldn't know a solution though... apart from bad hacks to not update the preview for animated values of scenes... only in insert key. %%%

A Saurus1 commented

2010-12-05 01:01:45 +01:00

%%%The weird thing is that I just tried it again, but this time using a color strip instead of a scene strip and it worked fine (the value didn't jump back). Odd.%%%

Ton Roosendaal commented

2010-12-05 11:19:33 +01:00

%%%Not odd, the scene strip is special case, it does a full animation render.%%%

Campbell Barton commented

2010-12-06 06:51:29 +01:00

%%%Aside from disallowing a scene to use its self in a sequence the only reasonable way I can think of avoiding this is to add the update call in again and use a flag to skip evaluating animsys sequencer fcurves.%%%

Campbell Barton commented

2010-12-06 07:26:10 +01:00

%%%Aside from disallowing a scene to use its self in a sequence the only reasonable way I can think of avoiding this is to add the update call in again and use a flag to skip evaluating animsys sequencer fcurves.%%%

A Saurus1 commented

2010-12-10 17:23:31 +01:00

%%%Another thing to note is that obviously, this works if the current frame is outside the scene (I.E. the scene is not being updated then). But also, if I try to insert channels for the Channel property, when I drag the channel property after inserting the first keyframe, it snaps back as expected, but the scene strip, which has changed channels in the actual sequencer window, stays where it is (until you pan). So something is updating the sequencer properties window, but not the sequencer itself. Maybe you could use this same something to not update the sequencer properties window either.

However, this brings up another problem, which is that even if you do put something in to not update the sequencer properties right away, if somebody wants to add a driver to a sequencer property that is based on another sequencer property (which is animated, and why they would want to, I don't know, but somebody probably will), then you have to update the driven value, but not the one that's being changed by the user. That's when things start to get messy.

Maybe you could have a separate, hidden 'scene' that stores all the sequencer animation, and also which scene/strip each f-curve is linked too. This would be really difficult to then show in the graph editor with the current system, but it would help the problem of the update issue (perhaps). Probably just as messy as the flag or the hack, though.%%%

%%%Another thing to note is that obviously, this works if the current frame is outside the scene (I.E. the scene is not being updated then). But also, if I try to insert channels for the Channel property, when I drag the channel property after inserting the first keyframe, it snaps back as expected, but the scene strip, which has changed channels in the actual sequencer window, stays where it is (until you pan). So something is updating the sequencer properties window, but not the sequencer itself. Maybe you could use this same something to not update the sequencer properties window either. However, this brings up another problem, which is that even if you do put something in to not update the sequencer properties right away, if somebody wants to add a driver to a sequencer property that is based on another sequencer property (which is animated, and why they would want to, I don't know, but somebody probably will), then you have to update the driven value, but not the one that's being changed by the user. That's when things start to get messy. Maybe you could have a separate, hidden 'scene' that stores all the sequencer animation, and also which scene/strip each f-curve is linked too. This would be really difficult to then show in the graph editor with the current system, but it would help the problem of the update issue (perhaps). Probably just as messy as the flag or the hack, though.%%%

Campbell Barton commented

2010-12-20 08:34:14 +01:00

%%%Assigning to Janne, I'm not keen to work on sequencer problems.%%%

Janne Karhu commented

2010-12-20 11:28:59 +01:00

%%%I think currently there is no way to solve this nicely. The main problem here is that currently changing animated values works only because the animation system update isn't (hopefully) called before the user keys the value. When a scene strip is (preview) rendered the animation system update is done, so the values set by the user are lost forever. This can't really be handled nicely without copying the whole main data for the rendering as anything could have been changed by the user.

The only sensible solution I can think of would be to use the "animation overrides" that apparently were planned for the animation system update (there is some code for them in anim_sys.c, but the functions don't actually do anything yet). The "overrides" would store the user changed values so that the animation system update could be called while still preserving the user made changes. These overrides would normally be cleared on frame changes (like the frame change comming from seq preview render), but this clearing could be easily overridden for the case of sequencer preview rendering.

I don't know what the fate of the overrides will be, but anyways the solution needs a proper design behind it so adding this report as additional info for the todo-list entry.%%%

%%%I think currently there is no way to solve this nicely. The main problem here is that currently changing animated values works only because the animation system update isn't (hopefully) called before the user keys the value. When a scene strip is (preview) rendered the animation system update is done, so the values set by the user are lost forever. This can't really be handled nicely without copying the whole main data for the rendering as anything could have been changed by the user. The only sensible solution I can think of would be to use the "animation overrides" that apparently were planned for the animation system update (there is some code for them in anim_sys.c, but the functions don't actually do anything yet). The "overrides" would store the user changed values so that the animation system update could be called while still preserving the user made changes. These overrides would normally be cleared on frame changes (like the frame change comming from seq preview render), but this clearing could be easily overridden for the case of sequencer preview rendering. I don't know what the fate of the overrides will be, but anyways the solution needs a proper design behind it so adding this report as additional info for the todo-list entry.%%%

Janne Karhu commented

2010-12-20 11:28:59 +01:00

Changed status from 'Open' to: 'Archived'

Janne Karhu closed this issue

2010-12-20 11:28:59 +01:00

Sybren A. Stüvel referenced this issue

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

Blender development todo list -- Editors #55366

Sign in to join this conversation.