Rendering proper 3D motion blur is a surprisingly complex and nuanced topic. In reality, it is a visual artifact caused by the movement of a subject within a camera’s field of view over the total duration of the camera’s shutter interval. In 3D, it is the simulation of that phenomenon, achieved by sampling geometry across a similar interval. However, because 3D motion blur simulation typically relies on the ability of a renderer to smoothly interpolate geometry across the motion blur interval, any changes to the topology (face or vertex count) of that geometry over time can cause the whole process to break down. This can make it difficult to render proper 3D motion blur in a variety of situations - many of which you may encounter in common tyFlow workflows. This page offers a breakdown of these situations and proposes ways to configure a scene so full 3D motion blur will still be possible.
Since motion blur is an artifact of an object’s motion through space over an interval of time, particles must actually move through space over a motion blur interval in order for motion blur to be calculated. If particles merely snap to their new locations at each whole frame (and are static at sub-frames), they will not undergo proper motion blur. And in other cases, where particle velocities are used to transfer motion blur to dependent meshes, if particle velocity values are 0 (even if particle positions are changing), then motion blur will not be computed properly.
Within tyFlow, you can use a Display Data operator to view particle data in the viewport (ex: velocity values and/or velocity vectors). By examining this data, you can determine whether or not particles have the sufficient velocity data required to derive proper motion blur from their dependent meshes.
Every renderer handles motion blur differently. 3ds Max’s Scanline renderer, for example, does not perform full geometry interpolation when computing motion blur - it offers only stepped motion blur or vector motion blur modes. These methods are not well-suited for high-quality rendering. The Scanline renderer does not support geometry instancing either. On the other hand, raytracing renderers like Arnold, Octane, Redshift, VRay, etc, are able to compute proper 3D motion blur on both regular geometry and instanced geometry. This page assumes you’re using a tyFlow-compatible, raytracing renderer that supports instancing to render motion blur. This page also assumes you already understand how to enable basic motion blur (and tyFlow instancing) for the renderer of your choice.
Most renderers support some form of subframe/deformation/curved motion blur. This type of motion blur can produce a curved blur trajectory as a result of subframe mesh sampling that occurs across the motion blur interval (as opposed to linear sampling that only samples input meshes at the start and end of the interval - interpolating linearly between those two states). This type of motion blur is typically only needed for fast-moving particles - slower particles, or particles moving linearly, won’t benefit (visually) from the extra samples taken. A typical case for this type of motion blur would be something like sparks, whose chaotic, curved trajectories are very apparent even across short motion blur intervals. Similarly, spinning objects like propellors can benefit from curved motion blur calculations, so that their motion blur appears curved/circular, rather than rectangular.
If you are rendering particles as meshes (and follow the no-topology-changes criteria outlined below), this type of motion blur should be supported for both tyFlow and tyCache objects across all compatible renderers. If you are rendering particles as instances, this type of motion blur is only officially supported for tyFlow objects (not tyCache objects), when rendering using VRay or Redshift.
For renderers to acquire the subframe data they need to compute proper subframe/deformation/curved motion blur for fast-moving particles, tyFlow subframe caching must be enabled in combination with a timestep less than 1 frame. The smaller the time step, the more accurate the resulting motion blur computations will be (at the expense of computation time).
The tyVertexVelocity modifier is a modifier that can be used to “smear” geometry in a topology-preserving way, across a motion blur interval. By applying this modifier to an object with changing topology, and transfering velocity from the object’s underlying geometry to its vertices across the motion blur interval, 3D motion blur can be computed for any mesh. However, the accuracy of the motion blur is dependent on the method that the tyVertexVelocity modifier uses to extract the mesh velocities. See the tyVertexVelocity modifier’s documentation for more info.
If you are rendering particles as meshes (ex: using a Mesh operator in triangle mesh mode), you must ensure that the topology of your particles does not change over time in order to render them with proper 3D motion blur (no change in topology allows a renderer to smoothly interpolate vertex positions over time, by matching vertex IDs at different frames). This means that your particle count must not change and each individual particle’s shape mesh must not change either. As long as these two criteria are met, any renderer should be able to interpolate your particle meshes in a way that is compatible with motion blur computations. So, for example, if you birth 50 particles on frame 0 and move them around until frame 100 (without deleting/birthing any particles within that interval, or changing their shape mesh), any renderer should be able to compute proper 3D motion blur for them at any time between frame 0 and 100.
If your particle count needs to change over time, there are a few tricks you can use to restore their proper motion blur:
Modify your setup so that instead of being born over time, particles simply scale up from zero when they need to appear. This way, particle topology won’t change over time. Same goes for particle deletion: scale to zero instead of deleting.
Use a Mapping operator to bake particle velocities to a mapping channel, then use a tyVertexVelocity modifier on the particles to transfer the velocity from the mapping channel onto their combined mesh. Note: this method will only account for linear velocity (not spin).
Set particles to render as instances instead of meshes.
If you are rendering particles as instances (ex: using a Mesh operator in instance mode), particle counts/topology can change over time, because renderers will use each particle instance’s transform to interpolate geometry over the motion blur interval, rather than a direct interpolation of particle topology. In this case, each particle is treated as an individual entity, rather than a combination of entities collapsed into a single mesh. Instance rendering is internally supported by both tyFlow and tyCache objects, and is the easiest way to get proper 3D motion blur on particles with static meshes.
However, if your shape geometry changes over time, these changes will not be smoothly interpolated when rendering as instances. For example, if you enable shape animation in a Shape operator and then render those particles as instances, motion blur will be computed for changes to the particles’ transforms over time, but not for changes to the particles’ meshes over time (ex: vertex animation on particle shape meshes will not generate its own motion blur). If you want a particle’s shape mesh animation to undergo motion blur, the particle will need to be rendered as a mesh, not an instance.
If this distinction is not clear, imagine you are rendering a group of butterflies where the motion of their overall bodies through space is controlled by transform (position/rotation) changes on their particles, but the flapping of their wings is controlled by animation applied through a Shape operator. If they are rendered as instances, only the motion of their bodies will generate motion blur - the wing flapping will not. To get full-body motion blur that affects both their motion through space and also the motion of their wings, they would need to be rendered as meshes instead of instances so that the renderer could perform full mesh interpolation (and thus, all the caveats that come with particle mesh rendering would need to be considered).
If you are exporting particles as objects, the resulting objects will be treated as individual entities by renderers, and their motion blur will be computed from changes to their transforms alone (and will therefore be subject to fewer caveats). However, if you are exporting fast-moving particles to objects and want to compute subframe/deformation/curved motion blur on them, make sure you follow the steps outlined above relating to subframe caching/timesteps, and enable the subframe key setting in the Export Particles operator - otherwise objects will be exported without subframe transform data and any extra subframe motion blur calculations made by the renderer will provide no additional visual fidelity.
So, for example, if you are exporting fast-spinning propellor particles to objects, ensure subframe caching is enabled in the flow, and that the flow’s timestep is set to a value less than 1 frame, and that you’ve enabled the subframe key option in the Export Particles operator’s object export settings as well.
Splines created by tyFlow (ex: splines created with a Spline Paths operator and meshed with a tySplineMesher modifier) can be difficult to render with proper 3D motion blur, due to the common ways in which their topology can change over time. For spline motion blur that requires no extra intervention, users must ensure that spline segment/knot count doesn’t change over time, and that adaptive/auto interpolation is disabled in the spline base object’s Interpolation rollout. However, most common spline rendering use-cases do not cohere with such stringent criteria.
A more forgiving spline-rendering workflow would be to transfer source particle velocities to splines using a Mapping operator, then generate motion-blur-compatible spline deformations with a tyVertexVelocity modifier (similar to how you would for particle meshes, above). Using this method allows splines to render with proper 3D motion blur, even if their topology changes over time.
Blob meshes created by tyMesher objects have internal mesh-smearing enabled by default at rendertime (similar to the smearing performed by the tyVertexVelocity modifier). This smearing transfers underlying particle velocities up into the resulting blob mesh, allowing for proper 3D motion blur calculations to occur.
Default blob mesh motion blur will only be as good as the particle velocity data underpinning it. If source particle velocities are not accurate, or particles have no velocities assigned, blob mesh motion blur may not be accurate. In these cases, either ensure the blob mesh’s source particles have proper velocity values assigned, or use a tyVertexVelocity modifier to perform mesh smearing using an alternative velocity source (ex: inter-frame mesh proximity).