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:

The network, at the most basic level needs only 2 things: a path, and a point. The magic sauce and engine that drives the whole thing is Attribute Interpolate. It expects points from its first input, and paths/primitives from its second input. The points from the first input must have: i@sourceprim – match this to a @primnum from the second input. v@sourceprimuv – where to place the point on the sourceprim.