Guard against ridiculously long animations?

[rdeits]

Accidentally trying to animate a trajectory of thousands or tens of thousands of seconds takes locks up both Julia and the viewer, as we end up producing an incredible number of samples. Maybe we can guard against this? Perhaps by limiting the animation sampling rate to some constant factor above the sample rate of the ts vector?

[tkoolen]

This is kind of a drawback of the MeshCat.setanimation! approach compared to the older animate. With animate you can do the interpolation and _render_state calls as you go, so you have up to 1000 seconds of CPU time for a 1000-second trajectory, while with setanimation! the user has to wait while everything is done in advance. This is compounded by the fact that we're creating MechanismVisualizers in the loop, that _render_state is not that efficient and that Animation's fields aren't concretely typed. So I think limiting the animation sampling rate wouldn't be the right solution here. Maybe we should focus on improving performance and/or dropping setanimation! in favor of animate.

[rdeits]

Mm, I think I disagree, and I definitely don't want to keep using animate(). Sure, you'd have 1000 CPU-seconds of time with the old animate(), but only if you're willing to (a) completely block Julia that whole time and (b) lose the ability to play, pause, or adjust the speed of the animation from the viewer and (c) lose the ability to re-play the animation after Julia has exited. The only way to keep the nice viewer speed and play/pause controls would be to have low-latency communication always open between the viewer and Julia, which isn't really something I want to force into the already-creaky WebIO framework.

In any case, I don't think a lower framerate would actually be that bad: The way setanimation!() works is that it records samples at whatever frame rate you give it and sends those samples to meshcat, but the meshcat viewer itself does its own interpolation of those values in javascript (three.js handles this natively for us). So even if you ran setanimation() at a framerate of 1 frame/s, the resulting animation would still play smoothly (up to the limits of linear interpolation). We could even tell three.js to do some slightly smarter interpolation if we want. So if setanimation() is actually slow for cases we care about, we can certainly drop the sampling framerate a little bit, and the resulting animation should be indistinguishable.

Last time I did some profiling, the abstract fields in Animation weren't important for performance (I tried a version where I concretely typed more of the MeshCat types, but it made essentially zero performance difference and I was concerned it would make compilation even slower). I think the bottleneck was

MeshCatMechanisms.jl/src/visualizer.jl

Line 106 in a215565

function _path(mechanism, body)

which I bet we could improve a lot by memoization. That could be a pretty easy win if performance is actually affecting our lives. But so far it hasn't been an issue for me, except when I accidentally made my timesteps exponentially too large :-p

[tkoolen]

I assume Three.js doesn't allow you to 'stream in' frames of an animation? As in, send it frames from Julia one at a time as fast as possible and have the viewer record them in a buffer that can also be replayed later, while the viewer starts playing whatever frames are in the buffer straight away.

Re: _path, yeah, that sounds like a good thing to memoize.

[rdeits]

Not that I'm aware of, but I'm sure we could build something like that. The fundamental datatype is the KeyframeTrack: https://threejs.org/docs/#api/en/animation/KeyframeTrack which is essentially a vector of times and vector of poses. We could probably just append directly to an existing keyframe track, as long as its interpolation process doesn't try to read past the end of the data.