We have two grids, we scatter an equal number of points on both. Boys on the left, girls on the right. Blend Shapes is a lerp function. You give it a “start” and “goal” state – boys at the start, girls at the goal – and Houdini interpolates between them. In the operator, blend1 is the bias – a float 0 <> 1 that sets the current “state” along that interpolation.

When Houdini builds a Constraint Network, as long as points have @name, it automagically connects points to the centroid of the object specified by @name. [Left] We have a constraint network (in yellow). The points only have @name declared on them. [Right] Inside DOPs, Houdini finds the object, and smartly connects the bottom points to the centroid of the object. Which results in: What we need is a way to tell Houdini which points on the target do we want each constraint point to be anchored to.

See Part 1 here. 99% of the time, when you setup constraint points that are close to/on the surface of a geometry, you don’t actually need i@anchor_id. [left] We have a constraint network with points that only have @name declared. The points on her body have @name = "thing", the ones on top @name = "". [right] The constraint network that gets built inside DOPs is as expected, everything just works.

Most instances must be run inside a VPC. Each VPC has subnets, each subnet is bound to an availablitiy zone. Make sure the subnet’s IPv4CIDR is set to 10.0.0.0/24. Back in the main config, make sure there is a security group assigned (VPC instances all must have one). And make sure to Auto-assign an IP or you can’t login to the instance! For the security group, edit the Inbound and Outbound rules:

A constraint is a single primitive polyline connecting two points. Anything not this will be ignored. The points tell Houdini what they constrain through a @name attribute. The bottom point, in this case, constrains something called “thing”. If @name is an empty string [the top point], then it is a “world contraint” e.g. it’s pinned to wherever its position happen to be. IMPORTANT The @name attribute must exist or the constraint will not be created.

A bias value tells us where, along an interpolation, to grab a value from. If we’re interpolating between the numbers 1 and 2, when bias == 0, the return value is 1. When bias == 1, the return value is 2. Thusly, bias == 0.5 would return 1.5. There are two main functions to get this “return value”: lerp (for all numbers and vectors) and slerp (for quarternions). Formally, to get the “middle” of interpolating between 1 and 2 (above example), we would write:

The basis of all “fireworks” like effects (or rocket boosters!). Essentially, a single point with @v = {0, 1, 0} fed into a POP Replicate with Impulse set to $F%24==0 e.g. points are replicated every 24-frames.

A POP Force is a pushing force – it accelerates particles – each step adds to the particle’s @v. A POP Wind is a pulling force. If we have this setting: An attribute is created on the particle called @targetv – in this case {0,2,0}. Over time, the particle will match its own @v to @targetv. This also means that the particle’s @v will never exceed @targetv – as apposed to a POP Force, which keeps adding to @v.

A ramp takes in a sample position 0 <> 1 (x-axis) and outputs the value sampled at that position from the y-axis. Here, we take a Line SOP and create a line with direction {0, 1, 0}. We feed it into a Revolve SOP. Before the Revolve, we use a Wrangle to push the @P.x of the points around with the ramp. float pos = @ptnum/float(@numpt); // For each point 0.

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.