The effect: Pieces break apart according to a bunch of paths, on an object that is moving/deforming. In parts, we have to: (1) Fracture the sphere according to some paths. (2) Have the pieces start out as part of the keyframed animation e.g. as part of the spinning globe, and then switch over to being simulated by the RBD Solver when some “trigger” happens. @active and @deforming We learned previously, the RBD Solver looks for the attribute i@active on the pieces to determine whether they are “reactive” in a sim.

Point Deform lets us transfer animation to any mesh (within reason) with just a buncha points. Lets create this contrived example, using this static mesh: And this animated “point cloud”: Wiring them up: For the second input, we use a TimeShift to hold the first frame of the point cloud animation, which gives us the “rest lattice” that matches the static mesh’s topology (ideally). All this essentially animates the mesh:

We start with two vectors @N (yellow) – which is the primitive’s normal from a Normals SOP, and {0,1,0} – the global up (gray). When the primitive is not rotated, these two vectors are parallel. By using a buncha cross, we can derive our main axes: vector pink = cross(@N, {0, 1, 0}); // First cross product vector green = cross(pink, @N); // Second cross product, the "double cross" Note 1: The green vector is essentially an “up-ish” vector that is always parallel to the plane and never points downwards.

A point doesn’t “point” anywhere. Points have no implicit direction or orientation. The idea of “rotating a point” is essentially meaningless. 1. When we “rotate a point”, we are implicitly saying “translate this point around the origin”. Take this example of “rotating” points in a Point Wrangle: matrix3 m = ident(); rotate(m, @Time, {0, 1, 0}); // Rotate on Y over @Time @P *= m; What we’re really doing is translating points around the origin:

1. The “workhorse” functions Most of the time, we use these to query distance: distance, xyzdist. 2. Query from a single point/prim When you ask: “Who’s next to me? Who’s nearby? Who’s connected to me?”. We ask this when we need to do stuff like growth propagation: nearpoint(s), neighbour(s), polyneighbours. 3. Specialized Other functions/operators that work with distance: surfacedist, pcfind, minpos, Find Shortest Path, Distance From Geometry 1a. distance An infrared ramp is used to color points based on their respective distances to the orbiting ball.

An arbitrary point in space (x,y,z) is a vector <x,y,z> from the origin. Adding a vector <a,b,c> to a point gives us another point. The vector <a,b,c> can be derived by subtracting P1 from P2. So far: vector abc = {1, 2, 3}; vector P2 = P1 + abc; vector def = P2 - P1; // def == abc The vector <a,b,c> defines a line in space between P1 and P2.

Transform Pieces moves stuff around with points. [Above] We use one point to move one box. Transform Pieces takes three inputs: [ A ] Points to transform. [ B ] Points that will move the A-points. [ C ] Rest positions of B before the move. Houdini binds the A-points to the B-points by matching a user-specified attribute that exists on both. In our tree, Assemble packs the box – reducing it to a single A-point – which is then driven by the single B-point.

We can modify constraints and geos while a simulation runs by plugging in SOP Solvers inside a DOP. The wirings go like this: [Above] The blue SOP Solver messes with the incoming RBD Packed Object (after the Bullet Solver is done with it), and the red SOP Solver messes with the constraint network. The various solvers plugged into the Multi Solver (green) are evaluated left-to-right. In this case, the Bullet Solver does its thing to the packed object, moves shit around, then passes it to the blue SOP Solver.

Since a Constraint Network is nothing more than geometry, we can animate it. Here, we have a line connecting two points, constraining a ball. We move the line up, the ball follows along. Easy. But not really. First, let’s do what is “intuitive” and setup a network like so: The Transform SOP (red) moves the entire line up. And this is what we get: When the sim runs, the constraint network moves up, but the ball doesn’t come along.

Animating the “First U” and “Second U” parameter of a Carve sorta makes the line appear or disappear. This is also how you extract a segment of a line. So far, the entire line is one primitive. What if we want to “break it up”? E.g. we want polylines between 1--2, 2--3, 3--4, etc. We would first need “unique points” e.g. 1--2, [x]--3, [x]--4. If we enable Breakpoints > Cut all Internal U Breakpoints: