This thread is intended to continue the discussion started here Paraview Animation Proposal, about the time support in ParaView.
Using time can be very confusing for some user, specially when using animation. For instance, it is hard to control frame-per-second settings when playing or saving an animation.
Current state of ParaView
Paraview currently interacts with three different time values:
The current Pipeline Time.
The Animation Time, usually the same as Pipeline Time unless modified in the timekeeper.
The User Time (in seconds) perceived by the user.
AnimationScene object is responsible for the time consistency within the application.
It is updated when a new dataset is loaded and it exposes available timesteps to the user. Those timesteps are read from files and ParaView does not know about their units (so it can be seconds, hours, months …).
The Timekeeper is used to map Animation Time and Pipeline Time. By default their are equal. (but they still don’t have a unit)
From the doc:
TimeKeeper can be thought of as an application wide clock.
Time in the GUI
Mainly, the user has access to the Animation Time.
VCR Controls: play / stop / … buttons allow to navigate through the timesteps.
When using the
Play button, frames are generated as fast as the pipeline can process the new timestep.
Current Time Control: a combobox and a spinbox to read / write the Animation Time. These are the values of the Pipeline Time mapped by the TimeKeeper.
Views (aka Dock Widgets)
- Time Inspector
A timeline with temporal sources, showing a tick for each timestep.
This includes the previous toolbars as control widgets.
- Animation View
A timeline with timekeeper and manually added properties. One track represents one property over Animation Time. Specifically, the TimeKeeper represents Pipeline Time over Animation Time. If the Timekeeper is disabled here, the pipeline is not anymore updated with new time values (but nothing is shown in the toolbars / time inspector)
Time in Animation
There are three animation modes:
- Sequence: define a number of frames, evenly distributed, to be played between a start and an end Animation Time.
Effective User Time depends on the time needed to compute the pipeline and render each frame. Pipeline Time is set as the nearest existing timestep. If no timestep exists, pipeline is not recomputed.
- Real Time: define the user-perceived duration for the animation.
Nb frame is adjusted at runtime depending on the time needed to compute pipeline and render scene. Pipeline Time is set as the nearest existing timestep. If no timestep exists, pipeline is not recomputed.
Duration is in User Time, but the number of frames can vary wildly depending on the time to render a single frame.
- Snap To Timestep: render successively one frame per data timestep.
Effective User Time depends on the time needed to compute pipeline and render each frame.
Note that all those modes (including snap to timesteps) do not take into account the data time value. It only goes timestep to timestep.
The Pipeline Time entry can be modified using the variable time in the timekeeper. It lets the user modify it relatively to the Animation Time. It is only useful in the case of temporal data, since a non temporal data does not rely on the Pipeline Time, but only on Animation Time.
These settings are very flexible, however they are confusing and can have unpredictable behaviours for the user, especially in the case of non temporal data.
We want to easily setup the User Time of the animation while keeping a control on the framerate for performance / quality purpose.
It is an intermediate between the current ‘do as much as the you can’ in term of frame (Real time mode) or in term of user-perceived time (Sequence mode and Snap to Timestep mode).
The main idea is that the Animation Time and the User Time are now one and the same.
Animation Time now has a unit, seconds (s).
The Real Time, the Sequence and the Snap to Timesteps modes are removed and replaced by:
- a Frame per Second control (in Animation User Time).
** !! ** In this mode, Pipeline Time will be set to the previous existing timestep.
- an option to use only exactly frame per existing TimeSteps
If the FPS and the duration are not compatible due to compute time, we can drop frames and warn the user.
If the data time is not at a human scale (i.e. not in sec / minutes), This can be detected and corrected automatically by the timekeeper while informing the user.
We could also support a unit converter in the timekeeper (is Pipeline Time in sec ? or in a month ?) to avoid human conversion.
Also note that the timekeeper is not only a factor between times but an actual mapping, that can use several interpolated points.
We also need to configure the animation writers to respect the FPS and the targeted User Time.