Pvelocity splat confusion?


Max 2014

I’m wondering if this is actually an issue, or if it’s working how it’s meant to be. This “issue” seems to be present whenever I use PVS (PvelocitySplat)
In the scene/preview linked below I have simplified it down to a single pflow particle moving in a 45 degree straight line up and to the right through the stoke field. The velocities displayed only update every 7 or so frames. Also, I would have expected the velocities to look like lines that are heading in the same direction as the particle, rather than what they are doing. Turing on “remove divergence” makes it look a little nicer, but still only updates every 7 or so frames and doesn’t do what I would like it to. I’ve tried changing the solver timestep in PVS and also the scene FPS to see if that makes any difference, but it doesn’t seem to. Also, changing the StokeField grid size to something ridiculously small doesn’t seem to make a difference either which was my first guess.

Here is a max file:
dl.dropboxusercontent.com/u/604 … gIssue.max

And a preview of the issue:
dl.dropboxusercontent.com/u/604 … ling.0.mp4

Also, during testing I thought I’d give spray and superspray a try to see if this was related to pflow. But the “InputParticles” node in stoke field magma won’t let me pick those systems.

Le Sigh,


This is not really a problem with the PVS, but with the sampling, quantisation and display of the field data.

First, you have a grid with a spacing of 1.0 cm.
Then you have a PVS which uses Absolute 10.0 cm, so its voxels are affecting 10x10x10 = 1000 qubic centimeters of the Stoke Field’s grid. But your display is forced to Automatic Reduction of 3 because the number of voxels to be drawn in the grid is over 30 million, and we have limited the number of point samples to draw in the viewport in Max 2015+ to only 1 million.

Here is what happens - your sole particle is moving through a large internal velocity grid with voxel size of 10cm (the PVS). The value splatted onto the grid is then transferred to the 1000 corresponding voxels of the Stoke Field object, whose display is then reduced by dropping a lot of lines to show only every 4th row of the grid!

The result is a large visible voxel with velocities pointing in the general direction of the particle’s motion, and some neighboring voxels with slightly blurred values, drawn as a bunch of smaller voxel samples, but missing a lot of the actual dots that would represent the grid you have set up. The display only changes when the particle moves into the next large voxel of the PVS.

You could evaluate in the MAXScript Listener the expression

StokeGlobalInterface.MaxMarkerCount = 10000000

to draw up to 10 million samples. That will change the Automatic Reduction to 1, skipping only every second row, but will make the playback much slower. Now if you also change the PVS to Relative mode with factor 1.0, each voxel of the grid will have its own velocity value. On each frame played, the velocity display will change because you will be seeing enough samples to actually see most of what is going on. Setting the MaxMarkerCount to 31 million will draw every line of every voxel in existence, but it will be painfully slow. However, this will display the actual internal state of the PVS grid.

It might be a better idea to resize the grid along most axes so it encloses only the area where the single particle is moving. I got the grid down to 312,480 voxels and with PVS set to Relative mode 1.0, it showed an update on every frame since all affected samples were actually drawn (Reduce: 0).


If you take my original scene, and turn the PVS to relative:1 so that it’s the same as the stoke grid and the Stoke grid to 5 so that it’s nice and quick, hit play, why are there some vectors that show as pointing directly along the X and Z along with the pink ones that point in the exact direction of the particle? I would have thought that since there are no other vectors to “blur” with, that I should only see pink 45 degree vectors of varying lengths?

The reason I had the spacing to absolute and set to 10 in the first place was because I was testing the stoke atmospheric and the absolute value of 10 gave me a nice soft result in the render. But obviously not a nice smooth motion.
dl.dropboxusercontent.com/u/604 … tric.0.mp4

I might just be trying to do things with Stoke that it wasn’t designed to do. I still don’t have a good understanding of it.