Paraview Animation Proposal

Development
1

Paraview Animation Proposal

TLDR

This post describes the improvement plan proposed by the Kitware Europe Sci-Viz team regarding the animation feature of paraview. It is absolutely open to debate in any of its main points, which are:

  • Smoothing the basic user interactions
  • Rethinking the time values and the different modes
  • Improving the smart/graphical editing of the animation tracks, especially camera movements

These proposals have been partly inspired by other softwares’ animation features, mainly Unity and KeyShot.

Before going further, let us define some terms that will be used all along the post:

  • Keyframe: A couple time/property value registered by the user.
  • Animation track: A set of keyframes on the same property that are interpolated. The track’s start is the first chronological Keyframe and the track’s end is the last chronological keyframe.
  • Timeline: in the interface, it is the part of the animation view that displays the animation tracks and their chronological progression thanks to the time cursor.
  • Time cursor: in the interface, it is the vertical black bar on the timeline. It sets the current animation time.

Smoothing the basic user interactions

These changes are non-breaking, either in terms of GUI workflow or python scripting.

Smart Timeline

Smart Tracks

  • Click and drag any existing keyframe on any track to shift it through time in the limit of the previous and next keyframe.
    keyframesweep

  • Click and drag a whole animation track along the timeline in order to shift all of its keyframes through time.
    blocksweep
    (KeyShot snapshot)

Smart Menus

  • A new dock widget replaces the old pop-up menus. This dock widget is linked to the current animation track selected in the timeline (therefore it introduces a notion of an active animation track).

    propertiesswitch
    propertiesswitch1378×233 102 KB

  • Any animatable property can be right-clicked to add a keyframe at the moment pointed by the animation time cursor at the current value of the property. In case the corresponding track doesn’t exist yet, a new one is created. This is similar to the Animation shortcuts widgets that can be enabled in settings.

    addkeyframe
    addkeyframe926×188 106 KB

    (Unity and Paraview montage)

Rethinking the time values and the different modes

Edit
Discussion about the Time Refactoring is superseded by this thread : ParaView Time Refactoring

These changes completely break existing GUI workflow and python scripts and may even not fully reimplement all features available in the previous implementation.

Reminder

Before going further, we remind you that 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 real time (in seconds) perceived by the user.

In addition, there are two types of animated data: temporal and non temporal data. Finally, there are three animation modes: Sequence, Real Time and Snap 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.

Changes

The following update plan relies on this goal : to unify all the existing possibilities under a real-time-oriented system, which is most of the time the expectation of the user. If the user still wants to configure the frames generation, or the variation of the pipeline time relative to the animation time, it can still be done as complementary parameters.

Now, here is the main plan:

The main idea is that the animation time and the real perceived 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 single mode.

cancelView
cancelView917×173 27.9 KB

This new mode has a Start Time and an End Time (in seconds) defining the animation time space. A FPS setter is available, letting the user choose the smoothness of the animation and reduce the number of frames if needed. The following picture only gives a general idea of this new interface.

newView
newView917×173 25.8 KB

There are some consequences:

  • With too high a FPS, the computer will not be able to generate frames fast enough, in this case, we keep the animation time correct but reduce the number of frames and inform the user with a warning.
  • When loading a temporal data, start time and end time are initialized to the min and max time values of the data. This will change how certain temporal datasets are played by default. This could cause issues with small time values (eg: can.ex2) or dataset with time values not in seconds (months, years). This can be fixed by modifying the timekeeper properties. We could imagine that this problem could be detected and fixed automatically with a variable time in the timekeeper.
  • The previous mode “realtime” let the user speedup or slow down the animation, which will not be directly available with this new simple mode. This could be fixed by adding a multiplier setting to the animation time. 0.5 would slowdown, 2.0 would speedup, -1 would invert. This multiplier would apply to what has already been configured in the timekeeper.
  • The previous mode “realtime” generated frames as fast as possible. This mode could be kept with a checkbox disabling the FPS setting and generating frames as fast as possible.

Use cases

Here are some different common use cases:

  • The user wants to load a temporal data. It is the variation of the water level in a lake over a long time. His unit is in months, and the water level is tracked over more than 50 months. When the data is loaded, the animation is way too slow, since one month has been associated to one second in the animation time. To correct this, he opens the timekeeper widget and adds an entry to the variable time with the time set to 12,5 and the value set to 50. The animation will then run 4 times faster.
  • The user is working on non temporal data. He has set many keyframes on properties that will probably slow down the rendering process a lot. The animation length is set to 5 seconds since the Start time is 0 and the End time is 5. The user has set 35 FPS originally. As he runs the play button, the user gets a warning next to the FPS setter and the frame generation scales down.
  • The user has lidar data that is animated overtime and wants to move the camera on a camera path within the data. The camera path is correctly synchronized with the lidar data, however, the user wants the whole animation to move faster for communication reasons. To fix this, the user can speed up the animation by using the multiplier setting. He sets it to 1.76 and now the whole animation takes less times to be shown.

Improving the smart/graphical editing of the animation tracks

These changes are new features that may impact slightly GUI workflows.

Graph Editor

Each animation track can be edited through a graph editor. The user can add and modify the keyframes and their interpolations by manipulating the corresponding points and curves on the graph. If this is done well enough, the usual “keyframe table” could be hidden as an advanced setting and let the graph be the main way to edit keyframes.
grapheditor
(KeyShot and Paraview montage)

Camera Animation Process

Camera animation tracks are a particular case among the properties allowed to be animated. As the current state of Paraview provides five different animation modes for the camera, they are often redundant and disunited while they have many things in common. Here is our proposition of a new unified process:

  • The user can open a wizard responsible for the configuration of Camera path presets. Many presets are available: orbit, panorama, dolly, follow data… The user can also load any custom path from file or field data from a source.

    wizard
    wizard630×557 1000 KB

    (KeyShot snapshot)

  • Once the wizard has generated this preset animation track, the user is free to modify its keyframes in the corresponding dock widget. This property widget is universal to any camera animation and as many details as possible will be available in a single Qt widget. The following picture is only a glance at what it could look like. We hope to make it more user-friendly in the future.
    NewCamKey1

  • When not playing the animation, the camera path is visible as previously, however an interactive camera 3D widget is visible at each camera position. Adding a camera keyframe can either be done by manipulating a new camera widget on the path, or by saving the current render camera position.

  • Finally, a new type of view will be available to open from the camera property widget. This type of view will show the same camera path and widgets as said before, but will always render it from a fixed point of view, whatever the current camera position is during the animation.
    cameditor5
    (KeyShot snapshot)

This post has been elaborated in team work with @mwestphal and @nicolas.vuaille.

4 Likes
2

Thanks a lot @Guillaume_Gindre for this detailed work.

FYI @utkarsh.ayachit @cory.quammen

3

@bastien.jacquet @lvauchier

4

That’s a very nice list of improvements. The thing that may be missing and that comes to mind when seeing all this is the possibility of toggling a quad view with projections (as in Blender), which is very useful (I believe) for manually setting animation points.

Capture d’écran 2020-09-28 à 16.27.15
Capture d’écran 2020-09-28 à 16.27.152670×1808 632 KB

1 Like
5

This looks great!

My only concern is this bit:

When loading a temporal data, start time and end time are initialized to the min and max time values of the data. This will change how certain temporal datasets are played by default. This could cause issues with small time values (eg: can.ex2) or dataset with time values not in seconds (months, years). This can be fixed by modifying the timekeeper properties. We could imagine that this problem could be detected and fixed automatically with a variable time in the timekeeper.

Many simulations require significant scaling in time to have a reasonable duration. Without something more automated, there are a lot of customers who will be confused or annoyed. Examples:

  • Many combustion and atomistic simulations may have units of seconds but durations of microseconds or less.
  • Hydrological and/or atmospheric simulations often have units of hours and can span years. NetCDF (a common format for these simulations) provides units for time but VTK & PV don’t read them.

The latter case is especially frustrating because users must take 2 scaling factors into account: scaling due to units and scaling for presentation in a reasonable time.

6

Indeed, that is why we suggest to detect this and rescale the animation in an “reasonable” time frame.
This is not worse than the current implementation that will just render the timesteps as fast as possible by default.

If you have suggestion about how to detect and rescale, we are all ears.

7

These look like a nice set of improvements to me, but like David Thompson I suspect that part may need some careful thought.

One feature request I have can be thought of an expanded case of your animateable property keyframe/track creation. I forget the name now, but I recall a domain specific scivis tool where the main entry point to animation setup was a simple “keyframe now” button. Behind the button it would find all of the changed properties and keyframe all of them for the user.

I.e. make an image you like using the UI you are already familiar with, keyframe it, move to another timestep, keyframe that, et voila, a decent animation setup that you can refine with lower level controls as you like.

8

I had the same thought as @dcthomp when I read this proposal. I really like most of what is proposed. But I don’t think changing the mode to always be real time is a good idea. I see several problems with that.

  1. As mentioned previously, simulations generally don’t time stamp their data in a time scale that is expected to be animated. If the animation has the appropriate time scale, that will be a complete coincidence. This will frustrate many users.
  2. Simulations commonly do not write out the simulation time. In this case, ParaView generally stamps the time as the time index. That will update the data at a rate of 1 Hz, which is almost certainly not what user’s want. You could work around that problem by changing the stamp to fractional numbers, but that would be confusing, because now the time does not match the index.
  3. It can be the case that the simulation writes out time steps at uneven intervals. Even so, it is common to want to play these time steps as a sequence of frames (i.e. Snap to TimeSteps). This does not seem practical with the proposed method.
  4. I’ve taught the tutorials of the ParaView animation several times. Even though I’d often recommend the Real Time mode for specifying the animation time, I found that users either didn’t quite get the point or preferred using Sequence for controlling the time sequence. I think users just like explicitly setting where the frames lie.
  5. One of the features lost is the ability to speed up or slow down time during the animation. Although not super common, users sometimes like to stop the pipeline time for a bit during the animation (for example, to stop the simulation data, move to a new camera position, and resume the simulation data).
  6. The time stamps real-time mode visits vary depending on the speed of the computer and will vary from play to play. This makes specifying what times the animation visits, which is important to users, extremely awkward.
9

I agree what everyone’s saying: all the UI improvements are fantastic, but I too would recommend leaving time unchanged. Time in ParaView does indeed warrant some rethinking esp since it fails to support use-cases where data is being dynamically ingested into the application e.g Catalyst – both in situ and Live – or staging readers like the on-going (or proposed) ADIOS/ParaView reader. I’d recommend leaving time changes out of this effort may be start a fresh conversion to collect all use-cases and come up with a new solution.

As far as the UI changes go, a few things to keep in mind:

  • make sure all forms of state (pvsm, python) and trace capture the changes. as you drag things around, make sure you trace the changes are appropriate.
  • make sure undo/redo continues to work correctly. All changes that you make between mouse-press to release should be captured as a single undo/redoable action instead of multiple ones.
  • I am not sure about clicking and dragging cursor on the timeline to immediately trigger render. For small visualizations, sure, but for larger ones it can get very slow and unuseable. However, since one can double-click to move the time cursor to move it in single step, it probably is not a big deal.
10

I found a small bug that should be fixed in this context:
https://gitlab.kitware.com/paraview/paraview/-/issues/20236

SaveGeometry does not seem to save timesteps correctly.

11

About this matter, we noticed that the next/previous frame buttons aren’t traced by the undo/redo.By the way, it raises the question about conserving the tracing of the current time value.

To all the paraview animation users: is it natural for you to undo a click in the timeline or any action modifying the current animation time ? Wouldn’t you expect to undo some other stuff that you did before this time set (like setting a property, a keyframe…) when you press ctrl+z ?

12

Another issue that is loosely related : https://gitlab.kitware.com/paraview/paraview/-/issues/20241

ParaView should have a “AddTimeSteps” filter to provide dummy time steps in a static dataset.

1 Like
13

Thanks for your replies!

Concerning the time refactoring, I opened another thread here : ParaView Time Refactoring, so we keep this one for the animation interface part.

So, what we are going to do:

  • improve interaction in timeline,
  • simplify keyframe creation,
  • add a graph editor for animated parameters,
  • refactor camera track : configure with preset, visual path in render view, widgets …
14

Sorry for being slow to the party. Took me a while to get through these threads.

I disagree with the handling of time stated above, but will pass my thoughts into the Time Refactoring thread. Ken’s discussion above is right on, and every bullet he lists states why changing time as proposed is not the right way to go.

I am very excited, and thrilled with the GUI changes additions stated. We have needed better camera track controls for a long time. Very nice. The widgets to control cameras are what I have imagined forever. Once we have this for camera, it would be wonderful to use the same controls for placing lights (without the camera tracks, of course.)

15

Maybe late, but here are my two cents anyway :
I always did struggle to set up the ligths correctly in the GUI, as well as the camera paths. I think it’s because with a given camera position, I was expecting the “points” to move in a plane perpendicular to the camera view axis.
But from what I red, some of my concerns are already adressed with much more interaction allowed with the “graph editor”, and the camera animation presets.
Also, can’t wait for the “Smart tracks”, to be able to “move” in time some animations without having to go through the animation keyframes!

1 Like
16

@mwestphal @nicolas.vuaille @utkarsh.ayachit @wascott @Kenneth_Moreland

As I had a discussion about it with Walter Scott, maybe we could remove the Animation Time Inspector and insert the missing information in the animation view. It would simplify things and centralize everything in one timeline.

No more:
timeInspector

But instead:

alltracks
alltracks900×168 32 KB

1 Like
17

I wonder if that’ll be more confusing. Now the the Animation View will not only show the keyframes but also time times provided by readers in the pipeline. Enabling/disabling this reader track is not same as enabling/disabling an animation track.

18

I have really struggled with an answer to Utkarsh’s thoughts above. I think that having two views that do and show almost the same thing is very confusing. Further, the Time View has wide data in a narrow format. It just doesn’t work.

I see three possibilities for the Time View. 1) Get rid of it. It does nothing special, and what functionality it has is backup and redundant. I didn’t even know it existed until this discussion. 2) Change it to be a wide, short view, as is the Animation View. It would then use tabs to bring to the top. 3) Merge it as proposed by Guillaume.

I think I like 1) the best.