Polygon to Particle behavior

[Nicholas Yiallouris]

Hi, in trying to create something similar to what I've achieved in Max (TP) and Maya (nCloth) and that is to have the polygons of my object be apart of a particle/dynamics system, ie: each face is actually a particle in essence. It would be even more helpful if those polygons collided with each other like rigid body, so I'm thinking it would be a DOP setup? Any help would be appreciated . Thanks Nic

[ikarus]

like this?

points2particles.hip

[Nicholas Yiallouris]

Oh wow, thats pretty cool ! but not exactly what I was after.

Perhaps this is a better explanation, If I had a polygon mesh sphere (50 x 50) that I could control each individual face with a rigid body solver (as you have) but the faces weren't attached to each other so they didn't stretch like a soft body but rather retained their original poly size that would be the winner.

I'm basically trying to have an object break apart / explode into little squares (faces) then have those particles/faces/rigid bodies be affected with forces before reassembling.

The end result will be this system interacting with another particle system but thats for another day...

[Zach]

Something like this, maybe?

It's a little haphazard, but it might do the trick...

sploding_poly2.hipnc

[Nicholas Yiallouris]

Now you are just showing off...

Thanks!

Trying to decode it now, is there anyway to omit the AttribWrangle (just because I've no idea what it does yet) haha.

Cheers

Nic

[Zach]

Aww, I wasn't trying to show off... I hope its helpful...!

Yeah, you can totally omit the attribute wrangle and use a Point SOP instead. The Wrangle SOPs are just quick-n-dirty ways of using VEX without having to set up a VOP network... for really tiny things, I find them easier to read. But I can totally understand how confusing this one might seem, because I've added options to normalize, scale, and / or reverse the calculated normals (it was a preset I had saved earlier... I do that a lot with wrangles, because both the code and the parameter interface are saved into the preset, which is not the case for vop networks!)

The code in question is as follows:

@N = (point(@OpInput2,"P",@ptnum) - @P);
if (`ch("normalize")` == 1)
    @N = normalize(@N);
if (`ch("reverse")` == 1)
    @N  *= -1;
@N *= `ch("scale")`;
[/CODE]

All the wrangle is doing is orienting normals to serve as initial velocities for the pop network. The wrangle itself is just setting each point's normal to the difference between that point and the point with the corresponding point number on the second input; which should work predictably, since the only difference between the two points is a relative transform (eg, the point count isn't changing).

With a Point SOP, you could plug in the initial geo and the transformed geo into the two inputs, and then you can select Add Normal, and set the three fields to $TX2-$TX, $TY2-$TY, and $TZ2-$TZ. That's equivalent to the following line of wrangle (vex) code:

[CODE]@N = point(@OpInput2, "P", @ptnum) - @P;[/CODE]

Broken down:

• @ptnum, @P, and @N are the current point number being evaluated (int) , that point's position (vector), and that point's normal (vector), respectively.
  
• @OpInput2 = the path to the node plugged into the second input of the wrangle
  
• Because @P and so forth refer only to the first input stream (exactly like the globals you get in a VOP environment), you have to use a vex point() expression if you want to retrieve an attribute from the second input stream (or anywhere other than the first input stream). In this case, we want to get the position "P" vector from the second input stream of the point that corresponds, ptnum-wise, to the one we're currently evaluating in the first input stream. Thus, we use point(@OpInput2, "P", @ptnum), which tells the point() expression to look at the path pointed to by @OpInput2, and return the "P" attribute for point number @ptnum. The vex point() expression is clever enough to recognize that it should return a vector of all three components, so we can subtract vector @P from it directly to return a difference vector.
  
• So, @N = "the position of point number @ptnum in the second input" minus "the position of point number @ptnum in the first input")
  

Everything that follows in that wrangle is additional convenience.

• `ch("normalize")`, for instance, refers to a spare toggle parameter called "normalize" - it's placed between backticks ( ` ) to indicate that we want the compiler to evaluate what's within the backticks - in this case, the value of the "normalize" spare parameter, being one or zero - before evaluating the rest of the code. It's kind of like playing MadLibs, if you've ever done that - you fill in all the blanks with values before reading the entire thing aloud. Except VEX does it much faster, and it's not as funny.
  
• So, when you toggle on the "Normalize" checkbox, `ch("normalize")` evaluates as true (or one). So, the statement "if (`ch("normalize")` == 1) @N = normalize(@N);" means, "if the "Normalize" checkbox is ticked, then take @N, normalize it, and output it as the new @N)
  
• Similarly, "@N *= -1;" multiplies all components of the vector @N by the float "-1", thereby having it point in the opposite direction as before, while keeping the same magnitude.
  
• And again, same thing with "@N *= `ch("scale")`, except it's referring to a float with a slider instead of a checkbox.
  
• The "value *= ..." thing is shorthand from C - it's like a multiply constant VOP. So "@N *= -1" is the same thing as writing "@N = @N * -1"
  

The more you use wrangles, the more you'll use wrangles. They're great (and much faster, computationally and, I'd argue, workflow-wise, than chaining SOPs). But the Point SOP method will do the effectively do the exact same thing.

Hope that clears things up.

One thing you might want to do is orient the particle normals to their (normalized) velocities coming out of the popnet. A wrangle is the perfect tool for the job:

[CODE]
@N = normalize(@v);
[/CODE]

And then you should probably ignore the "reverse normals" attribute wrangle I have at the end, and post-compute normals with a Facet instead. That was sloppy. The reason why you have to recompute normals at all after the Primitive SOP is because I scaled the transformation by -1 in the Y axis in order to get the primitives to orient properly to the templated points. In fact, a cleaner, smarter way would be to set the Y-pivot to -$CEY, instead of scaling the entire thing by -1, which would leave the normals intact. Couldn't quite tell you why this negative Y orientation business has to happen at all, but you can see what happens without it.

Other notes...

I'm using an entire popnet at the top to get primitive centroids. I'd rather avoid going into pops just to get primitive centroids, but:

a) It's a lot less of a pain in the ass than setting up a foreach node, creating an add sop within, and then using centroid() expressions for x, y, and z to place the each point at the center of each primitive.

The centroid() expression actually calculates the centroid of the bounding box of a primitive. The Source POP seems to calculate the primitive's center more accurately, and it makes all the difference, particularly with those triangular primitives near the poles of the sphere. I haven't tried it, but I imagine the local $CEX, $CEY, and $CEZ primitive variables might return something different than the centroid() expression; in which case, you could store those values as a point attribute, and reference those with an Add SOP inside of a foreach loop. Or whatever you want.

You can also have a look at the actual Particle SOP - you can use it to modify geometry. Try uniquing the points with a Facet SOP on your input geometry, and messing around with the forces in the Particle SOP. Probably not what you're looking for, but an interesting effect if you'd like to deform the squares. Maybe you can get away with using a Blend SOP to snap them back in place or something.

Using a templated Primitive SOP is orders of magnitude faster than using a copy node within a foreach node, if that ever crossed your mind. It should also be faster than using stamped attributes and a copy node.

As for all the particle stuff... I hope it's not too oblique. Adam Swaab has a great new video at CMIVFX that goes over techniques similar to the ones I used here. Peter Claes has something similar in his 3D Buzz Technical Effects video. I think Peter Quint has something worth looking at for morphing fluids.

Let me know if there's anything else I can explain about my setup.

[Nicholas Yiallouris]

Thanks for the thorough explanation.

This is truly one of the best communities out there !