Timeline Control about anigen

[aibosan]

Interesting idea. I'm seeing several potential problems;

• Without set loop time, there is no logical timeline end point. The widget could scale to always show some slack on the right, but this would also reduce the usefulness since the times would keep moving, and precision would drop.
• The timeline might be too large. If the loop time is significant, the length of the slider is such that any precise time control is basically impossible.
• It'd clutter the interface a bit, which is mainly an aesthetic concern I could probably find a workaround for.

Most importantly, there is a way to adjust time slightly, in a convenient manner. (+)/(-) keyboard buttons allow you to seek back and forward, with alt mask increasing the precision and shift mask decreasing it. When paused, the smallest step is 10ms.

Furthermore, in upcoming version 0.8.1 (which is almost done), there is also the option to use alt+mouse wheel to achieve similar effect. This time, the smallest step (with ctrl+alt) is 1ms.

But it might be worth it to have another way to use this, and I'll definitely consider the timeline idea or another UI element to highlight this for people who don't see it (slightly obscure) in the manual.

[doctormo]

Thank you for the consideration. I guess I figured it would only be visible if you set the loop variable. Maybe if the loop setting not only set the duration but also the "offset time", so you'd be focusing on a certain part of the animation from say 32.5s to 39.1s and only that part would be shown.

Another brainwave I had after posting this entry was about placing the "start time" points on the line. So you can sort of see where items are animating in temporal distance. But that's certainly something of a nice to have and maybe someone will add an extension to add this widget.

[aibosan]

I think expanding the loop time to loop begin, loop end is a good idea, and I think I'll implement it for 0.8.1.

As for a timeline, I actually had one a while ago, but I found it clumsy.

The way I work, I mostly create a large number of animations with start at 0s and indefinite repeat, so a timeline would be just a wall of same-y elements. I considered only having the timeline show animations in the currently selected element, but that means doing a deep search for animation nodes every time you click something, which for a large file (and clicking the root node) leads to a considerable lag. Maybe there could be an optional "track this animation" checkbox, but that reduces the utility a lot. I'm just not sure how to tackle it.

[doctormo]

I agree with timelines being clumsy. Most non-linear video editors only get away with them because they're using square bricks. SVG is very different in the kinds of animation it does. This line would be more like a status line I guess.

Doing deep searches can be pretty bad, it depends how good your selection js is vs. indexing the animation elements, you could use a negative index, which is a list of nodes you exclude from being looked up because they contain too many children. I guess a delay of 1-3s after clicking on a new node would be acceptable delay in the widget appearing.

I started with a bunch of animations at zero (absolute temporal animation) but I had to refactor half way through to offset animations as they made more sense. Anything more than two wouldn't really be that useful.

How about you make the widget in svg? make a line, stick a start-marker and end marker on it, then populate the x parts of each path node based on the times with either a small mid-marker for one animation or a larger mid-marker for more than one? (I'm just throwing out ideas now)

[aibosan]

I've had an animation timeline in version 0.7.0 - you can see it here: anigen.org/versions/0_7_0/ (You can open it with the little stopwatch button.) Just keep in mind it's really old, but it shows the basic way I thought about it. But as I said, not that useful for my kind of animation, and a pain to redraw.

Indexing animations would be more efficient, of course, and it's what I did with the timeline I had. It doesn't exactly solve the dynamic "only animations in selected element" problem, even though it mitigates it.

The negative index idea might work, but then the inclusion rules would be very arbitrary. Where do you draw the line? 10 children? 50? 1000? Or maybe the method could have a forcible timeout, which would stop propagation to lower levels terminate it if it ran for more than certain time, but again, it sounds arbitrary.

I had similar problem with the XML tree - it could take seconds to redraw, which is what it'd be forced to do when you made new animation, pasted an object, deleted it and so on. In 0.8.1, I seed the tree dynamically - only the necessary level - which spreads the load, but that wouldn't work for the timeline.

Using the SVG method for the widget isn't very practical, as there's no way to catch events specific to a marker. But I have pretty robust UI library, so that's not really an issue.

[doctormo]

Ah, interesting. In once glance I was able to see that I had forgotten to fix one of my animations in 0.7.0, but that information was obscure in 0.8.0. I'm not sure if this is telling that there is useful information there or not, but it's one data point.

Maybe what a timeline needs to be is not an interactive element, but maybe a optional dialog that can just lay the animations timeline out there. No signals needed perhaps, just display of what other parts of the program can control.

[aibosan]

The problem with that is that once you make a timeline, people who know flash will expect it to do things other than allow you to select animations by clicking them. :)

But like I said, the main issue is the timeline gets really cluttered really quick in practical use. I still want to bring it back, but it's definitely a tough nut to crack.

[doctormo]

Damn flash animators, I've never had access to flash because of it's non-linux releases. But hopefully you'll be able to be bold with what ever design you come up with.

[aibosan]

We shall see.