Transformations & Arrays

Every transformation takes geometry and returns a moved copy - the original data stays put upstream, which is why Grasshopper is non-destructive. The five you'll use daily: Move (translate by a motion vector - recall from Lesson 4.1 that this wants a vector, not a point). Rotate (turn by an angle about an axis, around a plane or point - angles are in radians unless you feed degrees through a Radians component or a Degrees toggle, a classic gotcha). Scale (resize about a center; Scale NU does non-uniform scaling with different X/Y/Z factors). Mirror (reflect across a plane - the mirror plane's orientation is everything, which is why this belongs in a module that hammers planes). And the quiet champion, Orient.

Orient is 'move-and-rotate in one honest step'. It takes geometry, a source plane ('where it is now / its reference frame') and a target plane ('where and how it should end up'), and applies the exact transformation that carries the source frame onto the target frame. Everything riding on that frame comes along, correctly rotated and positioned, with no angle arithmetic. Once Orient clicks, you'll reach for it constantly - it's how you place a module onto any tilted, twisted frame a surface or curve hands you.

An array is a transformation applied repeatedly to make a pattern of copies. Linear Array repeats geometry along a single direction by a motion vector and a count - a colonnade, a run of balusters. Rectangular Array (ArrayRect) tiles copies across a grid using two step vectors and two counts (X and Y) - a coffered ceiling, a window grid, a paving field. Polar Array (ArrayPolar) rotates copies around a center by a count over an angle (usually a full 360) - a spiral stair's treads, a rose window, seating around a drum, a fan of blades.

The important habit is to think of the array's controls as design parameters. A rectangular array isn't 'a grid' - it's (spacing X, spacing Y, count X, count Y), four sliders that let you explore an entire family of grids. A polar array is (center plane, count, total angle). Because these are parametric, you can drive them from anything: an attractor could set the count, a curve's length could set the linear spacing, a slider sweep could animate the whole field. And when you need a pattern the built-in arrays can't express - copies whose size or angle varies across the field - you drop the array component and instead generate a list of transforms or target planes yourself and apply them, which is the more general technique the next section builds toward.

Arraying along a straight line is easy; the interesting work is distributing elements along a curve - stair treads climbing a helix, fins marching along a facade edge, planters following a path. The naive approach - Divide the curve into points and Move a copy to each point - places the copies at the right positions but leaves them all facing the same way, like soldiers ignoring the road's bends. It looks wrong immediately.

The correct approach uses the primitive from Lesson 4.1: build a plane at each point that's aligned to the curve, then Orient the element onto each plane. Divide Curve already gives you tangents; better, Perp Frame (or Horizontal Frame) hands you a ready-made plane at every parameter, perpendicular to the curve and correctly aimed. So the pipeline is: Divide or Perp Frame the curve -> get a list of target planes -> Orient the module from its base plane onto each. Now every copy leans, turns and follows the path naturally. This is one of the most-used patterns in the whole toolset, and it's the concrete reason we spent a lesson on planes: the frames are the design. Feed a twist into those frames (rotate each plane a little more than the last) and your fins spiral; scale the element by each frame's position and they taper. The frame list is where all the expression lives.

This is the idea to leave the lesson with. There are two philosophies for placing things. Transform the geometry directly: take the object and Move/Rotate/Scale it with explicit vectors and angles. This is fine for simple, one-off moves. But it gets brittle fast - chaining rotations, keeping track of which axis, fixing things that end up mirrored or tilted wrong. Transform the plane instead: figure out the frame where you want the object (build it, or harvest it from a curve or surface), then Orient the object onto that frame in a single operation. The geometry is 'along for the ride'; the plane does the thinking.

Why the second scales better: planes compose cleanly. You can build a frame, then rotate that frame, then offset that frame along its own normal - each step is a clean, readable transform of a coordinate system, and the geometry follows perfectly at the end. A whole tower of rotating floors is 'a list of planes, each turned a bit more than the one below, with a floor Oriented onto each'. Compare that to trying to rotate each floor's geometry by an accumulating angle about the right axis - error-prone and hard to read. The professional instinct, drilled across this module, is: when orientation matters, don't wrestle the geometry - build the right plane and let Orient carry it there. Master that and complex placement stops being fiddly and starts being architecture.

One more idea rounds out the toolkit and quietly powers the advanced work later: in Grasshopper a transformation is itself a piece of data you can store, pass around and reuse. Components like Move and Rotate not only output the transformed geometry, they also output the Transform object - a compact description of the operation. You can capture a list of transforms and apply them all at once with the Transform component, or chain them, or compute them from other data. This is the deep reason 'transform the plane, not the geometry' scales: an Orient is really 'the transform that maps plane A to plane B', and a whole array is just a list of such transforms applied to one base object.

That reframing unlocks patterns the fixed array components can't reach. Want copies that grow toward a point, twist more the further along a facade they sit, or thin out where a curve is tight? You generate a list of planes or transforms - one per instance, each computed from position, distance, or an attractor value - and apply them in a single move. The built-in Linear, Rectangular and Polar arrays are just the convenient, uniform special cases of this general idea; when a design needs variation, you drop down a level and build the transform list yourself. It also keeps definitions light: applying a list of transforms to one referenced object is far leaner than baking hundreds of unique pieces of geometry. And it composes with everything you've learned - the transforms can be built from curve frames (Lesson 4.2's Perp Frame), from surface normals (Divide Surface), or from the vectors and planes of Lesson 4.1. Seeing transformation as data, not just an action, is the mental step that turns arrays from a fixed menu into an open-ended design language - and it's the bridge into the attractor and field logic of the next module, where the transforms are driven by a whole landscape of influence.