Hi,

Looking for the same behaviour as with POP grains' “collide mutually constrained particles”, with Vellum.

I'm doing this in the context of a grain setup with Vellum.

The init- and update-overlap parameters look like they could be appropriate, …but I cant quite get a read on how they behave with the black-boxed Detangle node. The overlap attributes seem to be a bit all or nothing? (either the init value, or 0)

Also, it seem you cant turn self-collision off, even if you completely disable collisions altogether? (bump pscale up coming out of the grain_constraints setup node, and flip collisions off on solver.. it explodes until you dial pscales back to non-overlapping)

I am fresh to Houdini, so dont discount me missing something lame! - but i've tried to be a good little acolyte, clearing caches, inspecting attributes, bumping viewports/display flags, etc.


Thanks!
Campbell

H 17.0.352

It might help to clarify that the detangle and the grains are two separate collision detectors in Vellum. The detangle uses overlap and disableself, but the grain colliders do not. The grain collider uses the isgrain attribute to include a point for grain collision.

The collide mutually constrained isn't in Vellum. Often it was used in grains to handle sheets or wires where one has to have a very dense layer to avoid penetration. In Vellum, it is expected instead to just use triangles and lines for this. The main reason for its absence, though, is that the constraints live on a separate geometry in Vellum.

So, how do you do grains solver setups (where overlap on birth is solved) with vellum and grains constraints? Like the OP, all I get is exploding vellum grains.

Is vellum grains not suited for this type of work (sphere packing)?

Thanks for the insight, definitely cleared things up.


Our use case is with many grain clusters (ball proxies, preferably overlapping) doing various things in all-ball-worlds, instanced with geo at render. Ie, no wires or meshes associated with the grains in the dynamic context. All collisions are grain-grain. Simple tests have shown Vellum's speed to be faster than POPGrains in many of our cases (may well have been unfair comparisons though ), …would you expect that, for grains-only usage?

With POP Grains you're doing the collision exclusion during neighbour-lookup-and-stash:

POPGrains/get_neighbours:

… if we were to read the ConstraintGeometry during Vellum's get_neighbours, and did similar exclusion from the neighbors array, then when Vellum's use of the same POP Grains's calc_dP_ocl (pbd_sand.cl pointDistanceUpdate()) comes about it'll behave the same way, …given Detangle is strictly about geo/tri collisions, there should be no ‘cross-interference’ with the grains we need to consider? (again, we have no dynamic geo assoc with the vellum objects here, its grains all the way up and down).

A super coarse test looks like its behaving as expected: groups of clustered, overlapping points that are self-excluded from the pcfind() neighbour lookups, resulting in clusters not exploding and allowing for cluster-cluster collision). Can we expect surprises down the road by doing this though? If we start banging grains against external/non-vellum geo?

Thanks!

Your analysis seems quite right. Stripping those points from the neighbourlist is what the don't-collide-with-explicit does. I'm glad you were able to find the right code to add it.

As for speed, I'd expect a proper apples-to-apples to match speed in both cases. One big difference is we've locked down the Vellum path to be only support OpenCL and only have constraint averaging disabled. But we call the same kernel in the inner loop, so I'm not sure where the speed up occurs.

Another issue with Vellum is the auto-sleep likely won't be as effective in speeding up the sim. So I can see pure grains still being used. Which is also why we kept all those shelf tools.