Time-loop: can it do this?

Support Synfig related help
1

Hi,
I’m trying to use the Time loop layer to loop a part of my animation and can’t find how to achive this correctly…
I’m probably doing something wrong, or maybe this is not possible to do this way, so I ask your help please.

I’ve replicated my issue on a simple sifz file.

What I want to do: I want the first 6f to animate “normally”, then from 6f to 1s6f I want to loop this part again and again and again…

I’ve tried different settings in the time loop layer, to animate those with constant type waypoints, with different combinations of values… no way.

So please if this is something possible show me how to do it on this example file.
Until then I’m stuck with copying loop keyframes one by one again and again, much more tedious :stuck_out_tongue:
TimeLoopExample.sifz (1.99 KB)

2

Easypeasy. :slight_smile:

In the modified file attached I’ve looped between fr.50-65 so you see that you can animated normal first, then there is a pause without animation and then a loop which is breaked at 65 after which you can animate again.

At fr.0 set duration to 0f. Also make sure you have “Only for positive duration” ticked.
Then at fr.50 set duration to 6f and set waypoints to constant.
At fr.65 set duration to 0f.

Without positive duration it loops 0 frames, but when ticked it loops only when time value is more than 0.
TimeLoopExample_2.sifz (3.22 KB)

3

Weird. I cannot make it loop properly neither!
I’ll take a deeper look when arrive home.
-G

4

Thank you both for your answers!

rylleman: That’s already globally what I tried, but now I know better what those options do thanks to your explanation.

Genete: indeed, I’m not crazy :smiley: ! I can’t get it to loop properly, it always either have the first 6 frames in the loop, or the loop is “delayed” from 6 frames (looks like “local time” has no effect)
Thank you for checking this when you can :.)

5

Ah, I misunderstood. Now I see what you mean, and Indeed I can’t get a proper result neither.

6

you can setup a animated TimeLoop layer to get the result you want.
enclosed for your ref.

TimeLoop layer hurts synfig user’s brain cells as Genete said before :mrgreen:
In another word, it shows the power of synfig :laughing:
TimeLoopExample_3.sifz (2.25 KB)

7

Thanks for your try jcome, but I already tried that and it still doesn’t match the loop properly → loop start with 6 frames forward
(go on frame 6, and check with/without loop layer activated on canvas panel, you can see that the frame displayed there with the loop layer activated is frame 12 instead of 6)

Again from what I can see it looks like Local Time parameter has no effect (ie. I can change it with any value, I see no change affecting the loop, and it’s this parameter that is supposed to be in charge of when the resulting loop begins, right?)

8

Darn! I give up!
Animate the Time Loop parameters is absolutely crazy.
Maybe encapsulate the stuff and animating the time offset would produce one easier to handle solution.
-G

9

Even without animating the time loop layer, the “local_time” parameter value has no effect at all, so this IS a BUG :.P
I’ve tried to look at timeloop.cpp but of course as I don’t know more than a few C++ basics I couldn’t see what’s wrong.
Please someone take a look at this; maybe I should report a bug on some bugtracker?

(PS: on a side note, I installed the release deb on a Ubuntu 12.04 “testing”, synfigstudio crash at launch; building from source from git did work fine hopefully)

EDIT: ok after more reading of timeloop.cpp, I found:
if (!symmetrical && time < local_time)
t -= duration;

so I did more tests and OK local_time has one effect at least : if symmetrical is unabled, and local_time>link time, it has some weird effect.
But Local_time is described as “The time when the resulted loop starts”, so I expect it to map the loop begining on the frame time set here.
So in my opinion it still a bug… Genete, I’d like your opinion on this please.

10

I DID IT! :mrgreen: :mrgreen: :mrgreen:

Well I managed to make it loop properly, but it needs two strange key values at each loop to get it right (check the file to see what I mean…)
But I more see it as a workaround for now, as it would be so much better if local_time could do “properly” the job :.P
(because with this workaround, it may still be easier to just copy/paste keyframes to loop manually, though it’s still more flexible with loop layer)
TimeLoopExample_Yeee.sifz (2.94 KB)

11

The problem is that the example that dooglus did when he fixed the time loop layer seems to continue working fine.
wiki.synfig.org/wiki/Time_Loop_Layer
You can see that there is not much modifications of that layer since long time ago.
I don’t know if it is a bug. See the example and notice that all the parameters work. If local time is later than link time it has no effect I think because the loop already started… Confusing.
-G

EDIT: Congratulations!

12

Thanks ^^

I’ve examined carefully dooglus’s example at wiki.synfig.org/wiki/Time_Loop_Layer,
and actually it confirms exactly what I say: the screenshots don’t match anymore with current results!
Look again, on first screenshot at time=2s the circle is on link time, here it’s not… and so on for all screenshots. exactly what I said.
I’m kinda reassured, but indeed there’s a bug to fix here now ;.)

13

I don’t promise to start to try to fix it in a short term but if you write down one simpler example of what’s achieved with the current behavior and what’s supposed to be obtained by user logic, it would help to file the bug later.

You can make the explanations here and file a bug report that points here for details.

Thanks!
-G

14

Ok… (when I said “there’s a bug to fix here now”, I meant “now” as in current synfig version, not as in “right now” :stuck_out_tongue: )

I can try to describe more simply what is supposed to happen and what is happening instead in Time-loop-demo-0.2.sifz in dooglus example:

-The second circle (the one that have the loop layer on it), with loop layer disabled, goes from 0 to 10 in a linear way from 0s to 10s (is at 1 at 1s, at 2 at 2s, at 3 at 3s etc…).

-“Time loop” is set on 5sec, and duration is 1,5s (1s12f), so the resulting loop shows frames from 5sec to 6,5sec of the child layer (so loop start with circle at 5, and finish with circle at 6,5)
-“Local time” is 2sec, so the resulting loop must start from 2s, that is when at 2s on the timeline, the circle is at 5, and so is every 1,5s starting from 2s (that is it must be at 5 at 0,5s, 2s, 3,5s, 5s, 6,5s, 8s, 9,5s).

Bug is: currently, the resulting loop starts at 0s instead of 2s as defined above, so when at 2s on the timeline the loop is not at its starting point (and so the circle is at 5 at 0s, 1,5s, 3s, 4,5s, 6s, 7,5s, 9s ).

That’s it.

Tell me if you need more explanation (you can ping me on irc -Animtim- if you need to discuss it)

PS: reported here: sourceforge.net/tracker/?func=d … tid=757416
PS bis: a real life example of the issue on this topic: viewtopic.php?f=6&t=3536&p=14988#p14988

15

Thank you very much for taking your time on this!
I hope this can be solved someday!
-G

16

Hi.
I know that this topic is old but I think I have to post here my findings.

Timeloop layer is buggy right now and as I was trying to implement it to the html5 player I found a solution to the problem. Right now it is just running right in the sifPlayer. If you download the dev branch of the sifPlayer you will see that it animates the Timeloop layer as it was supposed to. In setPosition method of timeloop layer you will find out the code that returns the new position for the timeloop layer.

I never compiled synfig before to try to fix the timeloop.cpp but I plan too.

Also I wand to request a change in the timeloop params. I beleive we have to swap the link_time with local_time. Cause it makes more sense. Local_time must be the first frame of the loop and link_time the time the timeloop will link with the over all animation. It’s just a swap of functionality and I think it can be done just in the timeloop.cpp.

I have to learn to compile synfig to see if I can fix it for synfig. Just because I am a trial and error coder I tested it in the sifPlayer first.

17

Just made the change and compiled it in Ubuntu.
I just changed the set_time method in the file synfig/synfig-core/src/modules/lyr_std/timeloop.cpp

Looks like it works allright.

18

I was not sure how to do this so I forked synfig in my github account and created a branch timeloop.

https://github.com/haramanai/synfig

19

Time Loop has been always very confusing. :slight_smile:
I always do a sanity check:
"When duration is huge (infinite) I would expect that no loop happens and the animation starts at local time copying the cycled material starting at its link time.

That’s equivalent to a time offset of:
t_result=t-local_time+link_time

When t= local_time t_result=link time (that is the cycled material starts to cycle)

In your case, when duration is infinite (huge) then
t_result=t+local_time+link_time

what gives a wrong result when t=local time

Just one reminder: if the meaning of any parameter would change, there should be a backward compatibility checking.

Finally, according to Wikipedia, sign of fmod is “implementation defined” in C++ so it’s better to replace the code by the explicit calculations taking in consideration the duration sign.

-G

20

This is quite confusing!!. :imp:
I propose to don’t code anything more and just define the blue prints of what it is supposed the time loop layer should do.

This afternoon I have some free time and can’t code so I’ll sketch down the “time loop blue prints”.
Then when everyone agree the behavior we could check if the current implementation does what its supposed to do.

(Of course, the blue print would be for non animated parameters) :open_mouth: :open_mouth:

-G