Collections
A collection is a spreadsheet of things: each row is one item, each column an attribute those items carry.
Almost everything that flows between nodes travels as a collection. Points, mesh vertices, shapes and plain rows of numbers all share one shape: a table with rows for the items and columns for the data each item holds. Read that way, every node adds rows, removes rows, or edits a column.
Rows and columns
| @P (position) | @Cd (colour) | @pscale (size) |
|---|---|---|
| 0, 0, 0 | red | 1.0 |
| 1, 0, 0 | green | 0.5 |
| 2, 0, 0 | blue | 2.0 |
Three rows, three items. Each column is an attribute, a named piece of data every row carries. Attribute names take an @ prefix when referenced, so @P is the position column and @Cd is colour. The same names appear in the spreadsheet view, in The Expression language, and in node parameters.
Some attributes are standard:
@P, position@Cd, colour@pscale, size or scale@N, normal, the direction a surface faces@id, a unique number for each row@uv, texture coordinates
Any node that writes a column can name it whatever you like, and downstream nodes read it back.
Open the spreadsheet view on any node to see its collection as a literal table, rows down and attribute columns across. It is the fastest way to establish what is flowing through a connection.
The kinds of collection
Every collection has a kind, which says what the rows represent and how they draw. The row and column structure is the same across all of them.
Points: a cloud of positions. Each row is one point with a
@P. Used for scattering, particles, instancing and sprites.Geometry: meshes. Points joined into faces and edges, giving solid surfaces. Carries connectivity alongside the columns, plus per-corner data like
@uvand@Nfor texturing.Gaussian splats: captured scenes. Rows are soft coloured blobs reconstructed from photos or scans, rendering as a cloud rather than a surface.
Analytic shapes: resolution-free shapes carried as maths rather than baked geometry. See Analytic shapes and the
@analyticattribute.Tables: pure data, no geometry. Rows and columns of numbers, text and colours, used as a control sheet driving other nodes.
Lists: a single column of values in order. The simplest kind.
Those six are the whole set. A curve is not one of them. It travels as its own value type, and converts to and from a collection wherever a node needs the other form.
Points, Geometry, splats and Analytic shapes are visual and draw straight into the viewport. Tables and Lists are data-only, holding information for other nodes without rendering.
How collections move between nodes
A node reads the incoming collection, does its work, and passes a new one out.
A scatter node takes Geometry in and sends Points out.
A colour node reads the rows, writes the
@Cdcolumn, and passes the same rows along. Same kind, one column changed.A merge node stacks the rows of two collections into one.
Because every kind is the same underlying table, steps mix freely: scatter points on a mesh, colour them from a table, then turn them into curves. Nodes that need a specific kind convert what you give them where a conversion makes sense.
When a node misbehaves, check the kind of its input. A node expecting Geometry has no faces to work with if it is handed loose Points. Hover a socket to read the kind on the wire, or open the spreadsheet.
Guaranteed columns
Some columns come with the kind, so you can read them without a node having created them first.
Points and Geometry:
@Pand@id.Analytic shapes:
@P,@idand@analytic, which names the shape.Gaussian splats:
@Pand@id, plus the columns that make a splat a splat, its per-axis scale, its rotation, its opacity and its base colour.
Everything else is opt-in. A node that writes @N, @uv, @density or a name of your own declares it, and the declaration is what downstream nodes check against.