Evaluation / animation of f-curves does not correct for a scene's position within another scene
Open, NormalPublic

Description

System Information
Linux (Fedora 23 x64)

Blender Version
Broken: 2.78, latest in git as of 2016-10-14

Short description of error
If you embed a scene within another scene ("use sequence") at any position other than at the start, evaluation of f-curves is incorrect for the embedded scene - values calculated are for the frame number being rendered in the master scene, not relative to the start of the embedded scene.

Exact steps for others to reproduce the error
scene 1) add some kind of visible strip (e.g. text), add keyframe for strip opacity 0 (transparent) at 0s and 3s, 1 (opaque) at 4s from start of scene.
scene 2) insert scene 1 as sequence, at position 2s from start of scene.
result: render scene 2, text becomes opaque at 4s rather than 6s as you would expect.

Example attached - "sub" scene counts from 1 to 5 by way of animated opacities of text strips, but when embedded starting at 2s in the "master" scene it starts counting at 3 because the 2-second offset is not accounted for.

Affects 2.78 and the latest that I have built from git today.

F-curves do not appear to have any pointer to anything that could tell them what scene they belong to, so it is impossible to work out the correct value for evaltime (animsys_evaluate_fcurves, anim_sys.c line 1691).

Err... I don't know how to create a diff on here, sorry!

https://developer.blender.org/P413

This fixes it for this one specific use case, but I have tested in exactly zero other circumstances so don't even think about applying it.

Bastien Montagne (mont29) triaged this task as Normal priority.Oct 14 2016, 6:37 PM

Eeeeh… @Sergey Sharybin (sergey), wasn’t your recent fix (rB57a2015) supposed to handle those cases?

That fix did sort out a lot of the odd stuff that was going on with scene strips, but F-Curves appear to be evaluated completely independently of that system.

Okay, I'm very sorry for what I've just done to your source code. It's Friday afternoon, I'm about to go home and was hoping to have some kind of proof-of-concept, and this is what I ended up with:

https://developer.blender.org/P414

It doesn't work (the guess at working out the frame difference in anim_sys.c isn't right), I don't know how to make it save the new member of the FCurve struct to the .blend file, and I've touched waaaay too much stuff. But it does kinda show the idea, if someone could slap me onto the right track I'll work on it next week.

Okay, I've undone all that nonsense I pasted last week and have come up with a solution that seems sensible. However I am happy to be told that I've done everything wrong because to be fair I have no idea what I'm doing.

https://developer.blender.org/D2308

Could someone review this? It does work! Also Blender doesn't randomly crash when I do some other stuff but I've hardly tested this exhaustively.

I have attached a more challenging test case which inclues nested nested strips:

Hi all,

I've been using Blender a fair bit since making my fix in D2308 above, and I haven't found any problems so far.

Is there any chance someone could review it? I didn't want to step on anyone's toes by randomly assigning review to someone.

Many thanks!

Found a crash while looking at a slightly dodgy file, updated the diff to fix it.

This is essentially the same as T49261

I created a less invasive patch, which seems to work for me, here: D2558

I'm attaching a blender test file which can be used to test the fix. Open the "master scene" and scrub through the VSE: the text indicating the color should always match the background color.