Forums

Everything posted by 3dome

well it seemed to be a weired bug or something. just tried it again without the promote and the dopnet complained about missing required point attrib 'name' so I didn't see any geo in the dopnet. The same thing happended when I opened your scene back then.
Anyway, I disabled the promote and to force the dopnet to evaluate the geo I turned on Solve on Creation Frame and voila it works. Even then turned off that checkbox again and still working. Also transform pieces sop works.

No. The point number is 0 because the loop runs over each point of the grid, so for each iteration there is only 1 point => ptnum = 0
That point has your effector attribute, which is read by the point()-expression in the transform SOP to modify the box size. Then it gets copied onto the current point's position.
Iteration done.
Next iteration: same process but new point => different effector value, different position to copy the box to.
After the loop has run through all points of the grid, it outputs the merged boxes as the result.
You can still use the transform for that. If you have a vector attrib called effector just change the attrib_index in the point expression to 1=y and 2=z
In 16.5.536 when I tick on Pack and Instance it keeps the color. Previous version had some "issues" with displaying packed color, apparently SideFX now made some changes.
Anyway, if you unpack your stuff later the color attrib should be back.

I tried it with your scene yesterday and all i changed was to promote the name attrib to primitives (keep it on points too) right before sending the pieces into the dopnet. Then transform pieces worked fine for me.
If you cant get it to work I can send you the modified file on monday

@ParticleSkull tricky question, but I think I found a way.
According to the docs the gas collision detect just stores the collision information into attribs instead of manipulating the points. I make use of that by setting those attribs back to 0 for points that are supposed to ignore the collision with a certain collider.
I didn't test it with millions of grains, but this hack might be not as efficient as a clean solution (which I didn't figure out yet) since it still computes the collisions for all points.
grains_avoid.collision_1.04.hiplc

To the eye the results may seem the same, but the data tells you that they are not. there is a difference.
From a quick investigation the reason it looks the same is because the explicit constraints take over detecting the collisions but even with them turned on you can see a different behaviour in the attached scene (the disabled one has a springy motion to it)
[if you disable the constraints AND the final collision test, you dont get any collisions (apart from Internal Collisions) anymore, because now all possible detections are bypassed(gas coll detect) or turned off (constraints & final coll test)]
It gets way more noticable if we turn off the explicit contraints (leave final coll test on):
(1)- disabling the gas collision detect: you can see that both objects blow up. the cube because it is meant to when hitting the box but also the sphere because it is getting in contact with the cube and the Internal Collisions affect the sphere's particles
(2)- modifying the group membership: you can observe that while the cube blows up when hitting the box, the sphere passes through everything untouched (and it of course affects the cube's particles).
This is because all those pbd collisions make use of the __pbd_group and in (1) all the particles are in that group while - as said - (2) excludes the sphere's ones
@ParticleSkull: so i guess the problem is when 2 grain objects hit each other and you have disabled the gas coll detect you get an unexpected behaviour
grains_avoid.collision_1.03.hiplc

it's called function overloading. for details see http://www.sidefx.com/docs/houdini/vex/lang.html#functions
this is a quick basic example where VEX determines which function to use based on the argument types you feed to the function
int func(int a; float b){
return int(a*b);
}
float func(float a; float b){
return a*b;
}
printf("value is %d", func(2.0, 2.75)); //change the 2.0 to 2 to see the difference

@Andrea yes exactly. I noticed the same thing when disabling the whole thing but as @ParticleSkull said it feels wrong which is why I came up with that group method.
the reason the box still collides even with the gascollisiondetect disabled is because by default the Final Collision Test is enabled (where I guess the gasintegrator DOP apparently DOES take collisionignore attrib into consideration)

i can't look at the file right now but please stay away from using Concave mode as far as possible. it's slow, unreliable and just not good.
there are far better options like vdbtospheres, heightfields, etc

there's no need to create groups with a partition SOP as the connectivity gives you an attribute (called class by default) identifying which prim belongs to which piece.
so just run the loop as I mentioned in the first post (you can even do For-Each Connected Piece loop which sets up the loop to work with connectivity)
EDIT:
just make sure to set connectivity to Primitive so the attrib gets created on them instead of the default point level (the Connected Piece loop does all that for you if you're unfamiliar with that stuff)

they usually are. you can see that by middle mouse click it and then it says packed alembics and you only have like 25 points/prims or so
EDIT:
but there's nothing wrong with converting them to polys and then run connectivity before the loop

if every piece is a packed alembic you can loop through them. use a meta import to get random seed for a simple expression (like fit01(rand(detail("../metaThing", "iteration", 0)), -125, 235) ) in a transform SOP (on there maybe set pivot to $CEX,$CEY,$CEZ)
if they are not packed, just use connectivity as in your picture and then loop

in case you wanna be more fancy and have the prims appear in a growing fashion, drop down a fuse SOP in unique mode before that code
//primwrangle
vector center = @P;
int primpts[] = primpoints(0, @primnum);
foreach(int i; primpts)
{
vector dir = center - point(0, “P”, i);
float fit = fit(@primnum+1+@Frame, @primnum+1+(@Frame*(@primnum > @Frame)), (@primnum+1)*2.05, 1, 0);
float ramp = chramp(“scale_ramp”, fit);
vector set = dir*ramp;
setpointattrib(0, “P”, i, set, “add”);
}
play with the ramp (i found moving right point closer to left side looks nice) and with the 2.05 in the code (make it parameter or so, jsut make sure its always > 2) to adjust "trail length" and falloff
also pretty cool if you reverse the fit to (x,y, 0, 1) and have the ramp zero all the way then close to right side make it go to 1. gives a nice trail when disintegrating

i guess such a point always has 4 neighbours, so
EDIT:
it's a bit diffuse how much control you have about the other points (are they grouped, etc)?
so my code above might not be what you want.
instead you could UV each quad and select the corner points based on their UVs ({0,0}, {0,1},{1,0},{1,1})