tyVertexVelocity Modifier

The tyVertexVelocity modifier offers several ways to generate motion-blur-friendly subframes or veloctiy map data for deforming meshes.

Calculating motion blur vectors for deforming meshes can be a surprisingly complex and difficult process. There are many different changes that a mesh can undergo, which will prevent proper motion blur from being computed during rendering. Changes to vertex count, vertex order, face count, or face order between frames can all lead to motion blur artifacts. The tyVertexVelocity modifier attempts to provide workarounds to these problems, allowing you to restore motion blur on meshes that would otherwise not support it. The theory behind how this modifier works is relatively simple: it attempts to calculate per-vertex velocity data for a mesh (using various available operations) and then uses this data to ‘smear’ the mesh across a subframe interval, overriding any sub-frame topology changes in the process (that part is key - this modifier ensures no topological changes will happen in the sub-frames surrounding any given whole frame). In doing so, it is often able to generate proper sub-frame mesh deformations that should be compatible with all renderers which are capable of rendering deforming meshes with motion blur.

The maximum per-frame motion blur duration that this modifier can gaurantee for any given whole frame, is approximately 0.98 frames. In other words, if your are rendering frame 20 of a sequence, compatible subframes generated by this modifier will exist from frame 19.51 to 20.49. So if your motion blur duration is greater than 0.98 (or your motion blur interval center is not 0.0), this modifier may not be able to generate compatible subframes for the input mesh.

To see exactly what type of sub-frame data this modifier has generated for a mesh, enable ‘FRAME:TICK’ display in 3ds Max’s Time Configuration dialog box, then scrub the timeline across sub-frame intervals.


  • Velocity from faces: the modifier will match corresponding faces (by index) to determine which vertices (with different indices) correspond to each other between frames, then calculate vertex velocities by measuring position changes between those vertices between frames.

Use ‘velocity from faces’ when vertex count between frames changes, but face count does not. Example scenario: vertices along an open seam are welded between frames, changing vertex count but not changing face count between frames (which normally prevents renderers from being able to compute deformation blur).

  • Velocity from proximity: the modifier will measure the closest distance between a vertex of a mesh and the mesh at a past/future time, to approximite the required trajectory to transform the current frame’s mesh into the mesh at the next frame.

Use ‘velocity from proximity’ as a last resort when there is absolutely no coherence between vertices or faces in a mesh from one frame to the next. This method can lead to the most artifacts, since it brute-forces a solution which may not be correct, but it also offers the ability to generate subframe data for meshes that would otherwise be impossible to calculate motion blur for.

  • Velocity from UVWs: the modifier will generate vertex velocities directly from velocity data stored in a mapping channel.

Use ‘velocity from UVWs’ if you’ve previously stored vertex velocity data in a mapping channel of the mesh. This method allows you to ‘restore’ vertex velocity data in a mesh, across topological changes, as long as the data has been preserved in the mesh’s specified mapping channel.

  • Velocity from vertices: the modifier perform a straight-forward vertex velocity calculation, by measuring position changes between vertices across frames.

Use ‘velocity from vertices’ if a mesh’s vertices are not interpolated across sub-frames. For example, some geometry cache loaders do not interpolate sub-frame deformations, even if mesh face/vertex counts remain consistent (no topological changes). This mode can restore that interpolation motion, allowing for accurate vertex velocities to be generated.

Velocity from UVWs

  • Channel: the specified map channel from which to retrieve vertex velocity data.

Velocity from proximity

  • Sample type: controls which sampler will be used to determine closest-surface proximities for vertices.

  • Max search dist: the maximum distance to search for a point on the surface of the mesh at the previous/next time interval. Decreasing this value can prevent artifacts where the closest point on the surface of the previous/next mesh is too far to be a possible candidate for a past/future state of deformation.

  • Time offset %: the percent of a single frame’s tick count, to add to the current whole frame, used to extract past/future meshes used for proximity searches. For example, if a frame has 200 ticks and ‘time offset %’ is set to 10%, the past/future meshes for the current frame will be extracted at +/- 20 ticks from the current whole frame.

Lower time offset values may yield better results for meshes which undergo a lot of deformation. High values may yield better results for meshes which undergo little deformation. A value of 100% is required for meshes with no sub-frame motion (ie, meshes whose topological changes ‘snap’ from frame to frame).


  • Velocity multiplier: a multiplier for vertex velocities calculated by the modifier.

  • Assign to map channel: when enabled, resulting vertex velocities will be saved to the specified mapping channel.

  • Show vectors in viewport: when enabled, velocity vectors will be displayed in the viewport as lines extending from mesh vertices.