Hey Folks,

I ran into a case where I needed to disable self-collisions on sim object, in the example scene I have it's the red cyldiner. While looking at the docs, I saw the disableself attribute and thought that might do it. I set it to 1 on the cylinder poitnspoints and 0 on the plane points. However, all collisions across objects get disabled with it.

I tried this both using a single vellum stream, and separate ones merged used vellum pack/unpack. It seems as though I'm missing something that allows the solver to recognize different objects, and is treating them as one.

I was able to cheat it by using putting the red points in a collision group and setting them to ignore that group, but this seems incorrect and I would like to understand why disableself isn't working.

I attached a scene as well, the switch nodes in there toggle between the collision group workaround and the disableself attempt. In case someone can take a look and help out I would appreciate it.

s@collisiongroup + s@collisionignore is the correct workflow, which is also part of CollisionIgnore recipe for Vellum Solver SOP

i@disableself + i@disableexternal work on per DOP object basis and since the whole geometry from the 1st input of Vellum Solver SOP is a single DOP object, there is no distinction between named pieces as far as "self" is concerned
So you can either do pure DOP setup where your pieces are separate DOP objects (Vellum Object DOP) or specify collisiongroup/ignore patterns to define relationships you want within a single object

Disableself and disableexternal do work per point of the object, you can see it if you assign the value of 1 to let's say just a part of the patch. However points with the value of 1 will both ignore and be ignored by the points with value of 0 when resolving self collisions which in Vellum's case collisions between all points of the same Vellum Object (unless those points are grains or fluid, those are handled differently). If collisiongroup and collisionignore work, use them.
Also, if you end up using SDF volume colliders for external collisions, those only consider the collisiongroup and collisionignore attributes, disableexternal doesn't do anything for those.

tamte
s@collisiongroup + s@collisionignore is the correct workflow, which is also part of CollisionIgnore recipe for Vellum Solver SOP

i@disableself + i@disableexternal work on per DOP object basis and since the whole geometry from the 1st input of Vellum Solver SOP is a single DOP object, there is no distinction between named pieces as far as "self" is concerned
So you can either do pure DOP setup where your pieces are separate DOP objects (Vellum Object DOP) or specify collisiongroup/ignore patterns to define relationships you want within a single object

Ah ok, that's a reasonable explanation, I see a Vellum Object inside the dop network, I assume that's where you would change it up. For cloth/hair simulation is not normal to unlock the solver and modify/add nodes inside it? Thank you for your help!

houdiniLearner02
For cloth/hair simulation is not normal to unlock the solver and modify/add nodes inside it?

ideally, you wouldn't need to do that, since that makes it difficult in the future to know what exactly it was unlocked for, it bloats up the file and also makes it more difficult to update the node version in the future, and dive targets stop working when HDA is unlocked, so it makes it pretty annoying to tweak the microsolvers in the actual internal dive target

the only time I unlock the Vellum Solver is when I need to do SDF colliders, which is mostly when dealing with changing topology colliders

but for selective collisions among individual pieces I'd personally do collision groups and keep things locked and just use the provided dive target for further customization

tamte
but for selective collisions among individual pieces I'd personally do collision groups and keep things locked and just use the provided dive target for further customization

That's good to know, thanks again for the help, I really appreciate it. I wish the documentation mentioned that, but good that we have this forum, and folks like yourself sharing the knowledge.