Retiming Particle Animation Using The PRT Loader

Available in Krakatoa v1.0.0 and higher

Overview

• The PRT Loader object can be used to load a particle file sequence not only exactly the way it was saved, but also to
  • Offset the sequence back and forth in time without changing its animation speed;
  • Load a single frame as listed in the PRT Loader without changing its frame number;
  • Define a validity interval for the frame number to be loaded via a Custom Range;
  • Hold a frame before and/or after the saved sequence or output no particles instead;
  • Use an animation curve to decide which frame to load at what time, allowing for complete control over the time flow of the saved particle animation.
• This topic will discuss the basic workflows related to these capabilities of the PRT Loader.

Offsetting Animation

• The PRT Loader object can be used to load one or more particle file sequences which capture the positions of particles on specific frames.
• Each particle file has a frame time stamp in the end of its file name which describes the original time the file was saved at.
• Normally, the PRT Loader uses the current time (either the animation slider’s time when playing back in the viewport, or the current render time when rendering) to load the corresponding particle file, e.g. if the current time is frame 42, it will attempt to load the file with time stamp 0042.
• Sometimes though it is useful to be able to shift the loading time back or forth to start the playback earlier or later.
• The PRT Loader’s User Interface provides an Offset value which defines the particle file to be loaded on scene time 0.
  • Due to this definition, the positive and negative values might feel counter-inuitive as entering 100 shifts the sequence backwards to play back frame 100 on scene time 0, while entering -42 shifts the animation forward to get frame -42 aligned to scene time 0.

Retiming Animation Using Playback Graph

• If the Velocity channel is present in the particle files, the PRT Loader has some information about the direction the particle was moving in on the current frame and can extrapolate linearly the particle positions up to half a frame before the current frame and half a frame after.
  • While this position extrapolation based on a single position sample and a single linear velocity is not absolutely precise, it is a fairly good approximation and is normally used by the Krakatoa Motion Blur effect to draw particles on sub-frames without reloading them from disk.
  • This information can also be used to speed up or slow down the particle animation recorded in the particle file sequence.
• The PRT Loader provides a “Graph” value which is similar to the Playback Graph value of the 3ds Max Point Cache Modifier.
  • The Graph value is animatable and can be keyframed to define which frame of the file sequence to load at what scene time.
  • The key times of the animation curve (X) define the scene time, the key values (Y) define the frame number to load.
  • Thus, a linear Graph curve with a key on frame zero with a value of 0 and a key on frame 100 with a value of 100 will load all frames just like the PRT Loader would do without retiming.
  • But changing the Graph curve’s second key on frame 100 to a value of 50 will slow down the animation to half the speed, while changing the second key on frame 100 to 200 will play back the animation twice as fast (as it has to display 200 frames within 100 frames scene range)
    • By default, the PRT Loader will extrapolate the new positions of the particles based on the closest full frame’s position and velocity, and will scale the velocity to match the change of speed, so in the above cases the velocities will be scaled down to half the original velocity and to twice the original velocity to produce consistent results.
    • Optionally, in Krakatoa MX v2.0.0 and higher, the new position of the particle can be interpolated based on the two closest neighboring frames, one before and one after the interpolation time - see the Interpolating Sub-Frames section below.
  • If both keys contain the same value, for example on frame 0 and frame 100 both keys have a value of 50, frame 50 will be shown constantly on all frames. Since the particles are not moving at all between scene time frames, the velocities will be scaled down to zero (if Velocity display is shown in the Viewport as lines, the particles will become invisible, so switching to Dot mode would be advisable).
  • Changing the key values to have a value of 100 on frame 0 and a value of 0 on frame 100 will invert the flow of the animation and result in backwards playback.
  • Using Bezier keys and tangents can cause slow downs and speed ups in the animation and so on.
• The Playback Graph mode will also respect the Offset value to produce the final frame number to load from disk - the value can be seen in the “Loading Frame:” test field at the bottom of the Timing group of controls.
  • This means that you can create a complex playback graph animation curve and then use the offset to shift it back and forth to match the actual particle files’ frame range without the need to slide all keys left or right along the time line.

Interpolating Sub-Frames

Available in Krakatoa MX v2.0.0 and higher

• By default, the PRT Loader will use only one reference frame’s Position and Velocity data to extrapolate particle positions requested at sub-frames when using the Playback Graph feature.
• The default mode is fast, but can produce a discontinuity around the middle of the saved frame interval when the linear forwardextrapolation from the previous frame switched to backwards linear extrapolation from the following frame, esp. if the particle is not moving along a straight line.
• When the “Interpolate Sub-Frames” option is checked in the PRT Loader, and if the ID channel is present in the PRT files, the new Positions and Velocities can be interpolated smoothly using the two closest surrounding frames.
• In this mode, there is no discontinuity since both the previous and the following frames are taken into account during the whole interval, but the processing can be slower since it requires the loading of two PRT files and more calculations to produce the results.

The following images show a Particle Flow system with a few particles moved by a Vortex force over two frames - all particle positions were accumulated into a single image to represent the actual trajectories.

The yellow particles show the original Particle Flow system:

The red particles show the same Particle Flow saved to PRT files and loaded in a PRT Loader with default settings (Interpolate Sub-Frames OFF). NOTE the discontinuity in the trajectories of particles moving on a curve trajectory when the extrapolation crosses the center of the interval between two PRT frames:

The green particles show the same PRT Loader, but with the Interpolate Sub-Frames option turned on. Note that there is no discontinuity in the positions anymore:

Here are the same three particle systems (PFlow, PRT Loader without and with Sub-Frame Interpolation), but displayed as Velocities:

Using the Before and After Conditions

• The particle file sequence contains a limited number of files that cover a range from the lowest frame number to the highest frame number saved to disk.
• The PRT Loader though can often attempt to load a frame that was not saved, either because the current time was changed to a value outside of the existing file sequence range, or because the timing of the sequence was changed via the controls described in this topic to load a non-existing frame at the current time.
• By default, attempting to load a non-existent frame at the current time will cause an error at render time and will show no particles in the viewport.
  • In addition, the status indicator found under the Particle Counts rollout of the PRT Loader will turn from green to red to show that a frame is being loaded that could not be found.
• To avoid such errors, the PRT Loader provides an options to limit the range of frames that would be loaded between a minimum and a maximum value.
  • The values are typically set to the first and last frames available in the file sequences listed in the PRT Loader, but they could be changed manually to a shorter sub-range within the available range.
  • There is a button to let the PRT Loader figure out the lowest and highest possible range values based on the existing frames on disk.
• When a frame is requested that lies outside of the allowed Custom Range, the PRT Loader can handle in one of two possible ways:
  • It can either Hold the frame defined by the Custom Range value, thus stopping the animation and presenting a static particle cloud to the viewport and renderer, or
  • It can output no particles at all - this is especially useful if the particles inside the range are changing count from few to many and back to few again but you haven’t saved the first and last frames to contain zero particles.
  • There are two drop-down lists that define this behavior separately for frames before the Custom Range and for frames after the Custom Range, so you can for example output no particles before the sequence starts but hold the last frame of the range after the range ends.

Loading A Single Frame

• The PRT Loader allows the loading of a single particle file on each frame via the “Load Single Frame Only” option.
  • When this option is on, the PRT Loader will load EXACTLY the frame(s) picked and displayed on the file sequence list and will not attempt to modify their file name by adding a frame counter to it.
  • Thus, if you loaded a PRT file that does not contain a frame number in its file name and enabled the “Load Single Frame Only” option, the file will load correctly.
  • If you would uncheck the “Load Single Frame Only”, the PRT Loader would try to append the frame number suffix to the base file name and if that file does not exist, it would fail to load and render it.
• Normally, when “Load Single Frame Only” is checked, the particle Velocity data will be discarded and set to no velocity because particles loaded on every frame will go nowhere and this cannot produce motion blur.
• For the cases where the generation of Motion Blur is necessary despite the particles not moving between frames, or when the Velocity channel is needed by Krakatoa Channels Modifiers for calculations, the checkbox “Keep Velocity Channel” can be enabled to preserve the Velocity data.
• The “Load Single Frame Only” method has drawbacks too - it disables all Retiming options like Offset, Custom Range and Playback Graph (because no timing information is applied to the file name being loaded).
• In the cases where you want to load a single frame from a sequence and also want to have full access to the retiming options, you can enable the “Limit To Custom Range” option and enter the same value for first and last frame of the range, while setting the two drop-down lists to “Hold First” and “Hold Last”.
  • This lets you load exactly the frame you want by entering its number in the two Range values.
  • Another side effect of this approach is that the frame will be reloaded on each frame, causing full reevaluation of all channels and modifiers, while the “Load Single Frame Only” caches the particles of the frame for viewport display and does not enforce a full update.

SEE ALSO

• PRT Loader Object
• Particle Deformations Effect On Velocities