Hi,
We have a case where neither the Vellum Constraints or Constrain Property DOPs suit requirements.
The problem can be easily solved with a Geometry Wrangle DOP, but I'm not sure if using that alone (see grab) is going to hurt, performance-wise, if we arent running through a SOP solver invoking a compiled block (as in the Vellum Constraints DOP)… the Geometry VOP DOP of Vellum Constaint Property DOP isn't using that, however it doesnt pull SOP data as we are, see attached grab.
(i know, why dont we just try, and do a cf… i guess i'm also looking for insight so we can rationalise then when and wheres)
Thanks!
Found 4 posts.
Search results Show results as topic list.
Technical Discussion » geo wrangle in DOPs, without use of invoked compile block, bad?
- c.strong
- 4 posts
- Offline
Technical Discussion » Distributed Vellum sims?
- c.strong
- 4 posts
- Offline
Is it possible to distribute Vellum simulation across machines? (as you can with the Grains PBD implementation). There is no distribute shelf tool alongside the other Vellum gear, nor documentation I can see, so I'm assuming it is not possible?
Maybe due to the way constraint GPU batching (/graphcolor SOP) is currently implemented?
If it makes a difference, current context is a vellum-grains-only setup (ie, no wires, cloth, etc, at all. Just points geo, and constraints).
Was super hoping we could use Vellum on current project, but may need to fall back to Grains for distributed sim?
Thanks!
Maybe due to the way constraint GPU batching (/graphcolor SOP) is currently implemented?
If it makes a difference, current context is a vellum-grains-only setup (ie, no wires, cloth, etc, at all. Just points geo, and constraints).
Was super hoping we could use Vellum on current project, but may need to fall back to Grains for distributed sim?
Thanks!
Technical Discussion » Vellum, grain-grain collision exclusion when explicitly constrained? (and non-disablable collisons!?)
- c.strong
- 4 posts
- Offline
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!
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:
... // Do not potentiall collide with explicit constraints // to allow us to over-pack particles. if (!explicitcollide && find(@ec, ptj) >= 0) continue; append(neighbors, ptj); ...
… 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!
Technical Discussion » Vellum, grain-grain collision exclusion when explicitly constrained? (and non-disablable collisons!?)
- c.strong
- 4 posts
- Offline
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
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
-
- Quick Links