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. If you are rendering from a Physical Camera you need to set the motion blur offset to negative half the motion blur duration in order to center the total motion blur interval on the current frame. For example, if your Physical Camera’s motion blur duration is 0.5 and its motion blur offset is 0.0, its total motion blur interval will be [frame] to [frame + 0.5] which is not a valid interval for the tyVertexVelocity modifier! In that example, if you set the motion blur offset to -0.25 (negative half the duration), then the total motion blur interval will be [frame - 0.25] to [frame + 0.25] which is a valid interval. Alternatively, if you don’t want to change the offset, you could set the duration to 0.49 so that the total motion blur interval will be [frame] to frame + 0.49.
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.
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).
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.
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.
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.
No deformation: velocity vectors will be computed (and optionally stored to a UVW channel), but no deformations will be applied.
Subframe interpolation: meshes will be deformed on subframes by smearing their vertices along the computed velocity vectors. This mode allows any renderer to compute motion blur by interpolating vertex positions at subframes, even if the source topology changes.
Motion trails: meshes will be deformed by smearing their vertices in the opposite direction of computed velocity vectors at every frame. This mode allows you to generate geometric motion trails.
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.
Normal thresh min/max: these thresholds control which vertices will be smeared in the opposite direction of computed velocity vectors. The greater the value, the closer any given vertice’s normal must point towards the nearest negative velocity vector. These values typically prevent forward-facing vertices to be displaced by forward motion.
Velocity thresh: the minimum velocity of a vertex in order for it to be smeared.
Velocity multiplier: a multiplier applied to vertex velocities that specifically applies to the overall smearing amount for motion trails.
Clamp multiplied velocities: when enabled, the magnitude of a vertex smear will be clamped to the length of the vertex’s velocity vector.
Use vertex selection: when enabled, vertex smear amounts will be multiplied by vertex selection values.