3.5.0 dev animations

[St0rm26]

Added support for smooth node animations on maps and visibility toggle options for the nodes. Also modified timeControl to allow controlling features of the smooth animation.

[luisvasq]

Hey @St0rm26, I ran into a few issues with the time control while testing:

1. The slider extends one unit beyond the available data. The thumb behavior looks correct when looping is enabled, as it only reaches the second-to-last mark:

2. With looping turned off, the thumb continues all the way to the end of the slider, instead of stopping at the last valid data point.

3. If we turn on looping while the animation is running or paused, the thumb jumps back to $t_0$, instead of continuing from the current position.

Both issues are shown here:

[luisvasq]

By the way, I'm seeing this with our current time and timeValues data. I wanted to test further, but couldn't find any example data for the new feature.

Do you have API data I could use to test the smooth node animation and visibility toggle? If so, could you push it to a branch in cave_app?

[St0rm26]

Hi @luisvasq , to address your first point, I'm assuming you're looking at kitchensink.py. If so, the slider goes up to 3 seconds because it is defined by the timeLength value under settings (line 120), not by the last valid time. As for the rest of the looping logic, I will have to look over that! I am currently creating some API data right now but am also running into some visibility problems, so I will also have to fix that.

[luisvasq]

@St0rm26, not a problem! Let me know when the fixes are in, and I'll run some more tests.

About timeLength, since it represents the amount of time values we want to display, could you also look into a fix for this behavior in the time control? No rush on this, since I'm also looking into a few other things on my end. Thanks!

[St0rm26]

@luisvasq, I see. I initially misinterpreted timeLength as the duration of the animation. For example, when I incremented the slider by 1, I treated it as increasing the animation time by 1 second rather than jumping to the next time value. However, with the way I implemented smooth animations, it relies on real time in seconds rather than just a sequence of time values. In order to easily integrate smooth animation logic with the time control panel, I feel like it is better to change the control panel to display a slider for the animation from 0 to n seconds, where clicking on the ith increment will skip the animation to the ith second. This would require redefining some parts of the API, such as timeLength and timeValues as seconds in the animation rather than the ith element in the sequence of animations. However, it would be a nice interface for controlling parts of the animation. I can push a branch to cave_app with the time control working for both the old discrete animated nodes and smooth ones (the visibility logic has not been fixed yet so ignore it for now).

API with smooth & discrete node animation: https://github.com/MIT-CAVE/cave_app/blob/3.5.0-dev-animations/cave_api/cave_api/examples/map_node_animations.py

[luisvasq]

Ah, that makes sense! I'm fine with updating the time control component, but these API + doc changes will likely be a breaking change. In that case, @connor-makowski will probably want us to hold off till 4.0, so it's worth checking with him first.

In the meantime, feel free to debug the other issues. Happy to help/test whenever anything comes up.

[St0rm26]

Alright, I just fixed the visibility and looping issues. Feel free to test it out!

[luisvasq]

Great, this is coming along well. One more thing: could you check the speed control logic? It doesn't seem to work when I switch between different speeds. I also noticed that after the first loop, the displayed changes appear shifted relative to the current time on the slider. This might be related to the pending timeLength redefinition, but it only happens when the animation is running. If I manually adjust the slider, the corresponding changes are displayed correctly.

[St0rm26]

I was able to get the speed control logic working, but I am unsure of what your other issue exactly is. I'm having some trouble replicating it on my end. Could you go into further detail on this problem?

[luisvasq]

@St0rm26, I tested again and have mostly confirmed that this is related to the timeLength issue. I also tested the smooth animation example, and it works well. That said, I'll chat with Connor today and bring up the redefinition of the discrete animation in our conversation. I might propose deprecating the existing API for timeLength + timeValues while introducing new <time-length> and <time-values-at> attributes to align with animation times. Then, as a breaking change, we can drop support for the old API keys in 4.0, while encouraging the use of the new keys starting in 3.5.0. I'll keep you posted on whatever we agree on.

So far, this is looking really good. 🚀

[luisvasq]

In the meantime, here are a couple of the last issues I tried to capture in the GIF below:

1. When playing the discrete animation with looping off, the node remains at its previous position when the animation ends.
2. During playback, the animated node doesn't always match the current time. This is probably due to a delay, so it may not be an easy fix. I don't think this is a high priority now.

[connor-makowski]

@luisvasq @St0rm26 is this ready to merge?

[St0rm26]

@luisvasq the issues should be fixed now. I think it was due to inconsistencies and disagreements between the old discrete and new continuous animation logic, so I merged as much of the logic as I could.

[luisvasq]

Just tested and everything seems to be working great! Thanks, @St0rm26! @connor-makowski, merging this one now.