How to make Cyclic option work for custom animation nodes?

How does Damper know what to animate to when Cyclic is turned on? When LFO changes its output from 0.99 to 0.1, what does Damper computes so that its result into 0.99 to 1.1?

I suppose it uses SubtractCyclic somewhere to account for cyclic range that can go into negatives (-0.5 to 0.5) too.

I tried using a combination of SubtractCyclic, FrameDelay, Frac/FracSawtooth, Integrator/Counter but I couldn’t figure out the core logic.

Is that core logic extracted into a node somewhere? I’m creating my own animation utilities and I want to include cyclic logic in it.

I think I figured it out!

cyclic2.vl (19.3 KB)

Update: Nope I didn’t. The above attachment has issues. See the messages below.

@ajitid Be careful

Welp, back to the drawing board. 😅 I have spent too much time to come up with the logic already…

Perhaps if you come up with a solution, then do let me know!

1 Like

Cyclic functions are quite complex.
Unfortunately the API is not public.

What are you trying to create? What do you need it for?

Thanks for putting in the screenshots, I didn’t search that deep!
The first screenshot you provided has GetCyclicValue which looks remarkably similar to the code here. I’m wondering why they have the same logic at two different places.

I don’t think the cyclic logic is complicated, it just happened to be quote involved for Damper.

My use case is that I want to create custom animation nodes as the inbuilt ones aren’t enough for me (for eg. I want to port this lib). The porting part is comparatively simpler than understanding how to make the Cyclic option work in it.

Update: What I think I’m doing wrong here is that HandleCyclic should take a difference between Goto Position and Damper’s current value, and not between Goto Position and previous frame’s Goto Position.

Motivated by inertia…

I wrote those animation nodes so that they as well can drive to the target with as few energy and sudden changes as possible. However, you could also have different motivations in mind. It’s your animation node.

So, if your animation currently has a high speed, you could do some more cycles or favor the shortest distance to the goal. It’s up to you.

from the lab back then:
here you can see how the starting velocity is the driving factor in which cyclic target point to select.


OscillatingFilter.pdf (warning: highly unreadable formulas generated by mathematica) (294.4 KB)

2 Likes

Thanks for the insight @gregsn! I didn’t think of taking velocity into account like this.

1 Like

@gregsn Absolutely stunning article
Basically in a good way

1 Like