- 1 Overview
- 2 Features
- 3 Use Case Notes and Example Plots
- 4 Implementation Ideas
There is a desire for animated plots VisIt. Here I've got some features, a couple use cases, and some implementation ideas. These could all use discussion and fleshing out.
note that these are really infrastructure features -- for specific animations see the use cases and example plots below
features I'm taking as requirements
- Ability to animate interactively without re-executing a plot
- (note: this will typically require a custom renderer)
- Ability to animate plots that do require re-execution
- Ability to just "hit play" and watch the plot animate
- Saving any movie can optionally have the plots animate
features I'd like input on
- Have some plots animate and some not
- When keyframing, have the ability to have plots start/stop animating
- Ability to have different plots animate at different rates in keyframing
features I view as unnecessary for now
- animating two or more features in a single plot
- ? (I forgot what I was thinking of....)
features which might either be a useful restriction or impossible to require in general
- random-access and reverse animation (see use cases below)
- if we require it, then it might make keyframing more simple ...
- ... but then we might not be able to make the plots animate the way we want to support
Use Case Notes and Example Plots
Is it possible to create a particle-flow plot?
Here's what I'm thinking:
- when it's first created, it initializes a bunch of particles at random positions
- for each next animation frame, it moves the particles one step forward (e.g. euler step)
- and for stalled particles or those that leave the problem (or domain), it can kill them off
- and create new ones if it has too few
Assuming this particle calculation is done on the engine, the problem is that the engine filter isn't going to be persistent in general.
Also, if we're in keyframing mode, we might be expected to jump around randomly. This simply doesn't seem possible.
If instead we do something like resample the original data onto a grid, we could ship it off to the viewer for recalculating every frame. This seems more feasible, but there's still a problem about random access to "animation index N": you can calculate a start position, and go forward one step, but you can't got backward, and you can't jump around. (It's like having only a forward iterator in STL, I guess.)
The only real way to do this is to make it more like an animated streamline plot: precalculate the particle paths, send those to the viewer, and have a custom renderer animate something along those paths. This gives us the original data, and the possibility for random access to animation indices (just modulo the index with the streamline length).
custom renderer only
My original plan was to tie this to custom renderers, and have a button comparable to the "Spin" button, but all it did was continuously re-draw the current scene with an incremented index.
The downside is that this could not animate plots which required recalculation, and so I'm abandoning it as too limiting.
new top-level time slider
This is the version I've got mostly working right now:
One step up from the first version was to create a new top-level time slider called "Realtime animation" It's basically a cross between database-time-sliders and the keyframing-time-slider. Specifically, it's a new, special time slider like the keyframing one, but it's always available. I created it with a whole bunch of time states (say 9999) so even that time slider didn't loop, it would still play for a good long time.
When a new time slider state occurs (e.g. through the "play" button when that slider is active), it tells the avtPlots what the new animation index is, and if the plot says it needs to recalculate for animating, we clear the actor (and it will cause a re-execution).
This could also work with keyframing: since this is like the database time sliders, we can just add a new slot to the keyframing attributes which has a sequence of animation key states, which will be very similar to the db key states. Just set the animation time slider to a new value when in KF mode, and it adds the new key, so you can make it animate as fast/slow as you want. Obviously there's some question if that set of states is global or per plot, or what.
other option: real plot attribute
Another option is to make any animated plot have a REAL field which is the animation index. This may be a small twist on the previous one (my current plan), but it's very easy to integrate with the idea of renderer-animation versus execution-animation (and might avoid some pitfalls of having it controlled by a new paradigm, which could have unintended interactions with keyframing, pipeling caching, etc.). Plus, it could allow for multiple animation modalities in a single plot.