c.strong
c.strong
About Me
Connect
LOCATION
Not Specified
WEBSITE
Houdini Skills
Availability
Not Specified
Recent Forum Posts
geo wrangle in DOPs, without use of invoked compile block, bad? Oct. 1, 2019, 1:42 a.m.
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!
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!
Distributed Vellum sims? Sept. 16, 2019, 11:57 p.m.
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!
Vellum, grain-grain collision exclusion when explicitly constrained? (and non-disablable collisons!?) Oct. 17, 2018, 7:33 p.m.
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!