Procedurally cull misbehaving vellum grains post-sim?

[bentway23]

I'm using a vellum grains setup to serve as a softbody sim for a fractured object (glued islands with separate, breakable glue for the seams, will point-deform source geo in a for-loop). Because the source geo is fractured, tet softbodies won't work, so I'm going the grains route. By and large it's working nicely, except that there are a few rogue grains that will fly off during the sim and I'm afraid that will screw up my point deform. It's not huge spacewise, so manually picking and blasting them after the sim but before the point deform wouldn't be difficult (and at this point probably more efficient, actually) but I'd rather do this procedurally since this setup is made to be reusable. Is there a way I can identify and blast out the misbehaving grains procedurally (presumably with the sim time-shifted to the last frame)? I presume doing a nearpoints-type-thing would eat into the edges or smaller islands, but I could be wrong. (And since they're more often in little clusters of two or three, just finding completely isolated points won't work.)

 

Thanks for any help!

[Atom]

You can run over the points and create group out of all the candidates who have less than three or four neighbors. Another approach is to group points with high velocity, if some of them are ballistic. Once you have a group, you can delete or colorize them to see how their removal impacts the overall simulation.

[bentway23]

I started toying with isolating points, shifting the cached sim to the last frame, creating an attribute for those with fewer than 3 other points within 2 times the pscale radius and then using an attribute copy to transfer it to the non-frozen sim--what I've found is that it doesn't seem to transfer to the non-time-shifted sim cleanly (the results change throughout the sim, although since it's based on the shifted final cached frame I would think they'd be constant--my method screenshot attached). I thought about measuring the velocities, too, but haven't started tackling that.

It would be great to just tell the point deform to reject misbehaving points as it goes along. Perhaps the trick would be to do the point deform in a solver, updating the rest lattice each frame so that points that have flown out of the radius wouldn't be considered, but I have a feeling that would be dreadfully inefficient.

It would also be great to not have those rogue points, but even going up to 7 substeps and 200 constraint iterations a few of them just fly away. I think that there are some problems where the most practical solution is a lasso select and a viewport-invoked blast node.

[Atom]

Try extending your detection for the ones that fly away.

float speed = length(v@v);
if(speed > chf("threshold"){i@group_rogue = 1;}