...

The "Reves" technique, which was the algorithm used for deformation motion blurred volumes prior to 23.45, is more accurate than the Eulerian technique and has a faster convergence time after the renderer has started. Unfortunately, it has a very high preprocessing cost, very high memory requirements, and is inherently a biased technique. As such, it requires the micropolygon length to be set to low numbers (exacerbating both the time and memory costs) in order to avoid visible biasing which manifest as blurry volumes. In most cases, the Eulerian technique should be preferred unless the velocity boundary conditions mentioned above cannot be satisfied for some reason.

The velocity vector value is expected to be relative to the entire shutter range. If you are working with velocity data measured in units per second and the shutter is not set to an entire second's worth of time, you may need to scale the data by the number of frames per second (i.e. 1/24.0) for a correct picture. We supply a control as a Velocity Multiplier to aid in conversion should your data be in the wrong measurement or allow you to make artistic tweaks to the motion blur. Alternatively, the Attribute "volume" "fps" may be set on the geometry directly to accomplish the same thing; in this case, the value of this attribute would be number of frames per second directly (24), not the inverse.As noted above: unlike other parameters to PxrVolume, the accuracy of deformation motion blur is directly related to and controlled by the  dice attribute  micropolygonlength . If you find that the fine detail of a motion blurred volume is lost, you may need to decrease this attribute in order to regain the detail. This will have a direct effect on render times and memory.

The following images were rendered using Eulerian motion blur, in conjunction with an OpenVDB file containing a velocity grid. Image on the left was rendered with no blur, while the image on the right has velocity supplied by a connection to the PxrPrimVar node reading a velocity grid from the file. The velocity has been exaggerated by a factor of 10. Note that this OpenVDB file (from openvdb.org) does not satisfy the boundary requirements of having velocity data in all areas of movement - this can be seen in the fact that the silhouette edges of the volume do not change significantly despite the exaggerated movement. However, there are no obvious objectionable artifacts, and area of the volume away from the boundary convey the desired velocity detail.

...