Generating Geometry with Code

All geometry starts with the point. In Rhino, a 3D point is three numbers - x, y, z - wrapped in a Point3d:

import Rhino.Geometry as rg

a = rg.Point3d(0, 0, 0)
b = rg.Point3d(10, 0, 0)
line = rg.Line(a, b)

A vector (Vector3d) looks the same - three numbers - but means a direction and distance rather than a location; lesson 5.2 drew that distinction, and it matters here because you move and copy geometry by adding vectors. A line is just two points. Once you have points and lines, curves follow: a smooth NURBS curve is built from a list of points it passes through or is shaped by.

pts = [rg.Point3d(0, 0, 0),
       rg.Point3d(5, 8, 0),
       rg.Point3d(12, 4, 0),
       rg.Point3d(18, 10, 0)]
curve = rg.Curve.CreateInterpolatedCurve(pts, 3)

CreateInterpolatedCurve threads a degree-3 (smooth) curve through those points. Notice the pattern already forming: make a list of points, hand it to a constructor, get geometry back. That single move - points into a builder - underlies almost everything in this lesson. Assign the result to an output like a and it appears on the Grasshopper canvas.

It is worth internalising the vector-as-a-move idea, because it is how geometry travels. To copy a point ten units up, you do not compute new coordinates by hand - you add a vector:

up = rg.Vector3d(0, 0, 10)
top = a + up            # a new Point3d, ten units higher

That single move - point plus vector gives a new point - is the basis of extruding, arraying and offsetting everything later in the lesson. Surfaces extend the same logic one dimension further: where a curve is shaped by a list of points, a NURBS surface is shaped by a grid of them, which is precisely why the nested-loop grid you are about to build is so central - it is the raw material a surface is made from. Points beget lines and curves; grids of points beget surfaces; and every one of them starts as a few numbers you chose.

This is also the moment to connect the geometry to Module 5, which built the mathematical intuition - coordinates, vectors, transformations - underneath everything here. You do not need to recompute any of that maths yourself; Rhino.Geometry provides ready objects and methods for it. But understanding what a Vector3d means, or why a curve needs a degree, makes the difference between copying code you do not trust and writing code you can reason about and fix. The library supplies the machinery; Module 5 supplied the mental model; this lesson puts them together to actually make things. That layering - concepts, then geometry, then generation - is deliberate, and it is why the earlier modules pay off precisely here.

Time for the classic. A column grid is a point at every intersection of a set of bays in two directions - exactly what two nested loops produce. The outer loop walks across, the inner loop walks up, and the same instruction places a point each time:

import Rhino.Geometry as rg

cols, rows = 5, 4      # inputs from sliders
step_x, step_y = 6.0, 5.0

points = []
for i in range(cols):
    for j in range(rows):
        x = i * step_x
        y = j * step_y
        points.append(rg.Point3d(x, y, 0))

a = points   # 20 column base points onto the canvas

Wire cols, rows, step_x and step_y to sliders and you have a live, adjustable grid: 5 by 4 becomes 8 by 6 by dragging, and the spacing follows the numbers. To turn each base point into an actual column, extrude a vertical line at every point:

height = 3.2
columns = []
for p in points:
    top = rg.Point3d(p.X, p.Y, height)
    columns.append(rg.Line(p, top))

b = columns

That is a complete, honest parametric model in a dozen lines: numbers in, a grid of columns out, everything responsive. The double loop you just wrote is the same engine behind facade panels, floor plates and seating layouts - learn it once, reuse it forever.

Notice a small but important detail in how the points were collected. The points list was created empty, before the loops, and each pass append-ed to it; if you create the list inside the inner loop it resets every time and you keep only the last point - a classic slip worth watching for. This gather-into-a-list pattern is everywhere in geometry code: start with [], build up inside the loop, use the full collection after. A neater, more Pythonic form of the same grid uses a nested list comprehension, which Module 2 introduced:

points = [rg.Point3d(i * step_x, j * step_y, 0)
          for i in range(cols)
          for j in range(rows)]

Both produce the identical 20 points; the comprehension is terser, the explicit loops are easier to extend when the logic grows. Choose whichever reads more clearly to you - both are correct, and clarity beats cleverness.

Now something that looks impressive but is really the same idea plus a rotation. A twisting tower is a stack of identical floor plates, each lifted higher and rotated a little more than the one below. One loop, an accumulating angle:

import Rhino.Geometry as rg
import math

floors = 20
floor_h = 3.5
twist = 4.0            # degrees added per floor
size = 12.0

plates = []
for k in range(floors):
    z = k * floor_h
    centre = rg.Point3d(0, 0, z)
    plane = rg.Plane(centre, rg.Vector3d.ZAxis)
    rect = rg.Rectangle3d(plane, rg.Interval(-size/2, size/2),
                          rg.Interval(-size/2, size/2)).ToNurbsCurve()
    angle = math.radians(k * twist)
    rect.Rotate(angle, rg.Vector3d.ZAxis, centre)
    plates.append(rect)

a = plates

Each floor is a square, raised by k * floor_h and rotated by k * twist degrees around its own centre - so the twist accumulates up the building. The move that makes it parametric is that the character of the tower now lives in four numbers: more floors, taller floor_h, sharper twist, wider size. Set twist to zero and you have a plain extrusion; push it to eight and you have a dramatic corkscrew. You could Loft these plates into a skin inside Rhino (remember: lofting needs the kernel, lesson 6.2), but as a stack of profiles the design intent is already fully there, controlled entirely by numbers you can turn.

Two things in that snippet are worth pausing on. First, the math.radians(...) call: Rhino, like most geometry libraries, measures rotation angles in radians, not degrees, so you almost always convert - it is one of the most common small bugs in geometry scripting, a tower that barely twists because someone passed 4 (radians, a huge angle wrapped around) or one that spins wildly because they forgot to convert. Second, notice that the same handful of moves from the column grid returns: a loop, a running index k, and geometry placed from numbers. The tower is not a new skill - it is the grid skill plus a rotation. That is the quiet lesson of parametric scripting: impressive-looking form is usually a simple pattern with one extra idea layered on, and once you have the patterns, ambitious geometry stops being intimidating. The same recipe - a loop, an index, an accumulating transform - scales from a twisting tower to a spiral ramp, a fanned louvre array, or a helical stair, each just a different transform applied per step.

Step back and notice what changed. In both examples, the design lives in a few named numbers at the top. That is the heart of parametric design: separate the parameters (the dials) from the construction (the loops that build from them), and exploring options becomes turning dials rather than redrawing. A good habit is to gather every meaningful number at the very top of your script, clearly named, so the controls are obvious - to you next month and to anyone reading it.

# --- controls ---
floors = 20
floor_h = 3.5
twist = 4.0
size = 12.0
# --- construction below; do not hand-edit ---

But keep two honest limits in view. First, code does not supply judgement. A script will happily generate a 90-degree twist that is unbuildable or a column grid that ignores the site; deciding which numbers are good is still design, and still yours. Second, not everything should be scripted. A one-off shape you will never vary is faster to draw by hand than to parameterise. Scripting geometry pays off when a form has real variations worth exploring, or a pattern too repetitive to draw - which is most of the interesting cases, and exactly what Module 9 pushes further into generative territory.

One more habit pays off enormously as scripts grow: keep the construction free of magic numbers. Every meaningful quantity should trace back to a named control at the top, so there is one place to change the design and no stray 3.5 buried deep in a loop that silently fights the slider above it. When you find yourself typing a raw number inside the construction, that is usually a signal it wants to become a parameter. This discipline is what lets a script survive contact with a real project - a colleague, or you in six months, can open it, read the controls block, and understand the whole design without deciphering the loops. Parametric thinking is as much about naming your intentions as about the geometry itself.