Documentation

4.1.1 Connector from Point

Connector • Nickname: ConnFromPt • Exposure: primary

Create Connectors by pointing at a Module Face in the viewport. Combines Face-from-Point lookup with Connector construction: looks up every Module Face whose geometry contains the provided point and produces one Connector per match. Useful when authoring Connectors by clicking on Module Faces directly in the Rhino viewport. 8 inputs total.

Behavior

Resolves the Point Tag into one or more Module Faces using the same point-in-Face matching logic as Faces from Point, then constructs a Connector for each matching Face using the same name, rotation and symmetry inputs as Construct Connector. Connector Name is optional; when it is not wired, a Deterministic name with the prefix c- and four letters is generated and reported in a Remark. Only external Faces are matched; on a Multi-cell Module each matching Face is addressed to its own Cell. Zero matches raise a Warning (“Point does not match any Module Face.”); multiple matches emit an informational Remark listing how many Connectors were created. An unmatched Point Tag is also marked directly in the viewport with a red circle-and-cross badge laid flat in the world XY plane at the point, sized from the average provided Module size. Viewport preview draws the Connector sticker on every matched Face, identically to Construct Connector.

Inputs

Outputs

4.1.2 Construct Connector

Connector • Nickname: ConstructConn • Exposure: primary

Create Monoceros 3 Connectors from Faces - named, rotation-aware interfaces placed on specific Module Faces. Combines type identity (name + symmetry) and placement (FaceId + rotation) in a single object. All Connectors sharing the same name are implicitly the same type. A Module wired directly into the Face input is cast to a short-lived wildcard FaceId that the component expands into the Module's six explicit Faces, producing one Connector per Face. Output is flattened. 8 inputs total. For point-based placement, use Connector from Point.

Behavior

Connector Name is optional. When it is not wired, a Deterministic name with the prefix c- and four letters is generated per component instance and reported in a Remark; Construct Connector, Connector From Point and Detect Connectors From Voxels share this name namespace. A wired name must not be empty or contain a line break, :, ->, @ or #; names are lowercased. Validates the symmetry flags (at least one must be true), Module Name, Face Direction and Face Rotation. Face Rotation accepts 0-3 or 90, 180 and 270 degrees; other values produce an Error. Symmetry 0 degrees defaults to true, while Symmetry 90, 180 and 270 degrees default to false. Creation failures are collected into one Error. A Connector with all four symmetry flags set to true behaves identically at every rotation - Rules generated for it do not distinguish Orientation. A Connector with selective flags (e.g. only 0° and 180°) produces different Rules for different in-plane orientations, enabling Direction-sensitive connections. When the optional Modules input is connected, the component draws a viewport preview showing the Connector as a label sticker on the target Face - displaying the Connector Name and symmetry arrows in the Connector’s type color, with degree labels (0°, 90°, 180°, 270°) indicating the in-plane rotation.

Inputs

Outputs

4.1.3 Construct Connector Pair

Connector • Nickname: ConnPair • Exposure: secondary

Declare which Connector types can connect across opposing Faces. Takes lists of Source Connector Names and Target Connector Names and produces a list of Connector Pairs. Compatibility is bidirectional - declaring A → B also allows B → A.

Behavior

Pairs every unique Source Connector Name with every unique Target Connector Name and outputs a flat list of Connector Pairs without duplicates. A Connector or text wired into either input is cast to its Connector Name.

Inputs

Outputs

4.1.4 Deconstruct Connector

Connector • Nickname: DeconConn • Exposure: secondary

Deconstruct a Connector into its constituent parts: Connector Name, Rotation in degrees (0, 90, 180 or 270), Module Name, and Face including any Cell ordinal. The inverse of Construct Connector.

Inputs

Outputs

4.1.5 Construct Terminator

Connector • Nickname: ConstructTerm • Exposure: tertiary

Create Terminators - boundary-facing markers placed on Module Faces. A Terminator declares that a specific Module Face is allowed to sit against the Envelope boundary when Require Terminators is enabled on Construct Assembly. For point-based placement, use Terminator from Point.

Behavior

The Face or Module input accepts either a Face (from the Get Module Faces component) or a whole Module. When a Module is wired, the component expands it into all six of its Faces and produces one Terminator per Face; a Remark reports how many were produced. This is the fastest way to mark an entire Module as fully boundary-compatible.

Terminators do nothing unless Require Terminators is enabled on Construct Assembly; supplying them when it is off produces a Warning. When enabled, Construct Assembly caps exposed Slot Faces on non-flat Axes: each needs a Module with a Terminator on the matching Face. The front and back Faces of a one-Cell-thick Envelope need no Terminators. If no allowed Module can cap a required Face, Construct Assembly reports a build problem and marks the Assembly invalid, so the WFC Solver refuses it. No extra boundary Cells are added - the grid stays exactly the Cells you authored.

The optional Modules input provides Modules for viewport preview. When connected, a Terminator badge - a smooth circle with an inner × - is drawn on each target Face in its Axis colour.

String representation

Format: Terminator@moduleName:faceIndex. Example: Terminator@pipe:+X.

A Terminator that targets one Cell of a Multi-cell Module spells that Cell's ordinal after the Face, as Terminator@pipe:+X1. The unnumbered form means the whole side: every Cell of the Module that exposes that Direction.

Inputs

Outputs

4.1.6 Detect Connectors from Voxels

Connector • Nickname: DetConVox • Exposure: tertiary

Voxelize all Module Faces using Face-local ray scanning, group same-Direction Faces by matching voxel fingerprint (testing 4 rotations), assign a named Connector to each group with detected rotation offsets, and output Connector Pairs for groups whose fingerprints match across opposite-Direction Faces.

Behavior

Shoots rays from each Face plane in both Directions (inward and outward) on a uniform grid. The resulting 3D boolean fingerprint is compared across same-Direction Faces at four 90-degree rotations. Faces whose fingerprints match at any rotation form a Connector group and receive the same Connector Name with the detected rotation offset. Names come from the shared Connector auto-name table (c- followed by four letters), deterministically per component instance and uniquely across Connector components in the document; vox_N is used only when more groups are detected than names were reserved for this component. Symmetry flags are determined per group by testing the prototype fingerprint against itself at each rotation. Groups on opposite Directions are tested with a UV-mirrored comparison to account for the different coordinate frames of opposing Faces; each match produces a Connector Pair. The viewport shows Connector sticker previews (arrows and name labels) alongside voxel wireframes with a colour derived deterministically from each Connector Name, stable between recomputes. Bezier curves connecting compatible Module Faces are drawn for each detected Connector Pair, using the same visual language as Preview Rule.

Recompute limit. When the number of detected Connector groups changes between consecutive recomputes, the component schedules one additional solution pass to stabilize. This reschedule is capped at five consecutive Attempts; if the count keeps changing after five passes a Warning is shown and the current result is returned as-is.

Inputs

Outputs

4.1.7 Terminator from Point

Connector • Nickname: TermFromPt • Exposure: tertiary

Create Terminators from a point tag. Looks up every Module Face whose geometry contains the provided point and creates a Terminator for each matching Face in one step. Useful for authoring Terminators by clicking on Module Faces in the Rhino viewport. For Face-based placement, use Construct Terminator.

Behavior

Uses the same point-in-Face matching as Faces from Point: the component tests each external Face of every Module with a 0.01-model-unit tolerance. Each match addresses the Cell on which the Face lies, so a hit on a Multi-cell Module produces a numbered Face reference covering only that Cell. The input Modules also provide the viewport badge preview.

Zero matches raise a Warning and produce no Terminators. Multiple matches (e.g. two Modules whose geometries overlap at the point location) emit an informational Remark and produce one Terminator per match. Output is flattened.

Inputs

Outputs

4.1.8 Match Connectors by Geometry

Connector • Nickname: MatchConGeo • Exposure: quarternary

Given an exemplar Connector, find all geometrically matching Faces across all Modules and output Connectors with detected rotation offsets. Uses the same naked-edge / curve-endpoint / point extraction as Detect Rules From Geometry but additionally detects the in-plane rotation offset between each match and the exemplar.

Behavior

Extracts geometry from each input Module's external Faces, transforms it to a normalized base plane, and compares it against the exemplar Connector's Face. The exemplar Module and Face must be present among those external Faces; otherwise the component reports an error. For each match, it tests all four 90° rotations of the geometry pattern. Each output Rotation is the exemplar's Rotation plus the detected offset. The output covers matching Faces, including the exemplar itself, and inherits its name and symmetry flags. No matches produce a warning. Multiple exemplars may be wired in separate iterations; the viewport previews all their Connectors together as stickers on Module Faces.

Inputs

Outputs

4.1.9 Match Connectors by Voxels

Connector • Nickname: MatchConVox • Exposure: quarternary

Given a prototype Connector on a known Module, find all Faces across candidate Modules whose geometry matches the prototype’s Face. Uses Face-local bidirectional ray scanning to build voxel fingerprints and compares them at four rotations (0°, 90°, 180°, 270°).

Behavior

Shoots rays from each Face plane in both Directions (inward and outward) on a uniform grid. Intersection parity determines inside/outside state; intersection positions mark surface voxels. Candidate external Faces are first filtered by Face dimensions and voxel-grid dimensions, then their fingerprints are compared at all four 90° rotations. The output starts with a copy of the prototype Connector, followed by matches with its name and symmetry flags. The Modules input is optional: without it, only the prototype Connector is output. The prototype Module does not need to appear in the candidate Modules list. The prototype Face shows solid coloured voxels and white scan-bounds edges; candidate matches show wireframe voxel outlines with Axis colour coding.

Inputs

Outputs

4.1.10 Preview Connector

Connector • Nickname: ConnPreview • Exposure: septenary

Display Connectors on Modules as arrows and name labels. When Connector Pairs are also provided, bezier curves are drawn between compatible Module Faces. Display-only component (no geometry outputs). Supports baking of the bezier curves.

Behavior

Draws a Connector sticker (arrow and name label) on the assigned Face of each Module. Several Connectors on one Face are drawn; only exact repeats and per-Cell Connectors covered by a whole-side Connector in the same Direction are dropped. If any Connector references a Module absent from the Modules input, a Warning names it and nothing is drawn. When Connector Pairs are wired, the pairs are resolved to Rules internally and a bezier curve is drawn per Rule in the neutral grey used by Preview Rule. The bezier curves can be baked; Connector arrow/label geometry is not bakeable.

Inputs

4.2.1 Heterogeneous Grid

Envelope • Nickname: HeteroGrid • Exposure: primary

Generate a grid where Cells along each Axis can have different sizes. Each Axis receives an independent list of dimension values; the component creates all combinations. For example, three X sizes, four Y sizes, and two Z sizes produce 3×4×2 = 24 Cells, each with dimensions determined by its position along each Axis. The homogeneity of the Homogeneous Grid means all Cells are identical; here, each column, row, or layer has a distinct dimension while all Cells within the same column, row, or layer share that Axis value.

Behavior

Cells are placed with cumulative offsets along each Axis, starting with a Cell centered on the Base Plane origin. The resulting Cells can have different sizes in one, two, or all three dimensions. Each size list must be nonempty and contain only positive values; the grid cannot exceed 5,000,000 Cells.

What makes a grid Heterogeneous. The grid is only Heterogeneous when the size lists contain more than one distinct value along at least one Axis, so that neighbouring Slots end up with different dimensions. If all three lists contain a single repeated value, the result is identical to Homogeneous Grid. A grid is not Heterogeneous merely because its Cells are non-cubic - a Homogeneous Grid with Diagonal (2, 1, 3) already has rectangular Cells; every Cell is still the same size.

A practical way to create varied-size input lists is the Grasshopper Gene Pool component for interactively dragging individual values and seeing the resulting grid update in real time.

For the Heterogeneous Grid to work with WFC, Modules are required whose dimensions match the different Cell sizes. For example, if X sizes are [1, 2], you need at least one Module with X = 1 and one with X = 2. Give separately authored Modules distinct names and define Rules for each.

Naming Modules of different sizes. Construct Assembly rejects separately authored Modules with the same name, even when their sizes differ. Only rotation variants of one source Module may share a name. Use distinct names and Rules for different sizes. See example 2.11 - Naming Modules of different sizes for a detailed worked example.

The component flattens its Cells output in Z-fastest order, then Y, then X. Connect it directly to the Construct Slot component.

Inputs

Outputs

4.2.2 Homogeneous Grid

Envelope • Nickname: HomoGrid • Exposure: primary

Generate a regular Envelope made of uniform Cells. All Cells share the same X, Y and Z dimensions, arranged in a cuboid block. This is the most common starting point for a WFC setup.

Behavior

Creates a 3D array of identically-sized Cells, aligned to the given base plane. Each individual Cell can have different X, Y, and Z dimensions; the homogeneity means all Cells in the grid share exactly those same dimensions. A single-Cell grid (X Count = Y Count = Z Count = 1) is valid and can be used for any purpose that requires an isolated Cell.

Non-cubic is not Heterogeneous. Setting the Diagonal to (2, 1, 3) produces rectangular Cells, but every Cell in the grid is still identical - the grid is still Homogeneous. You still need only one Module size. Use Heterogeneous Grid only when you need neighbouring Slots to have different sizes from each other. Although Cells do not need to be cubic, cubic Cells (X = Y = Z) are strongly recommended: non-cubic Cells constrain which Modules fit which Slots and can make the setup harder to manage.

The first Cell is centered on the Base Plane origin. The output is a data tree of Cells, flattened by the component with Z changing fastest, then Y, then X. The grid cannot exceed 5,000,000 Cells. Connect directly to the Construct Slot component.

Inputs

Outputs

4.2.3 Add Boundary Layer

Envelope • Nickname: AddBound • Exposure: secondary

Surround an existing Grid or Envelope with one or more additional layers of Cells. Use this to control what appears at the outer edges of the Envelope - for example, to ensure open or closed boundary conditions, or to add a ring of dedicated “cap” Modules that frame the interior.

Behavior

Generates new Cells that are adjacent to - but not part of - the input Envelope. The component outputs only the new boundary Cells, not the original ones. The boundary Cells are typically converted to a separate set of Slots (using Construct Slot with different Module allowances than the interior), and only then merged with the interior Slots before passing all Slots to the WFC Solver.

The six directional toggles, Include +X, Include +Y, Include +Z, Include -X, Include -Y and Include -Z, default to true. For example, disable Include +Z (Z) to leave the top of the Envelope open. Diagonal Neighbors (D) defaults to false; when enabled, the layer also grows into diagonal Cells in the toggled 26-neighbourhood. Every empty neighbouring Cell is included, including holes enclosed inside the Envelope. When working with non-rectangular (masked) Envelopes, the boundary follows the actual shape rather than filling out to the bounding box, so each new layer can extend past the Envelope's original extent in every enabled Direction. Layers below 1 raise an Error. When all six Directions are disabled, a Warning is shown and no output is produced.

Inputs

Outputs

4.2.4 Are Cells Boundary

Envelope • Nickname: AreBoxesBound • Exposure: secondary

Identify which Cells in an Envelope border empty space, including interior holes. Returns a boolean per input Cell - true if the Cell is within the specified number of layers from an empty neighbour along an enabled Axis. Use this to separate boundary Cells from interior Cells to treat them differently - assign dedicated boundary Modules, restrict allowed candidates, or visualize the distinction.

Behavior

A Cell is a boundary Cell when at least one neighbour along an enabled Axis is empty. Include X, Include Y and Include Z each cover both Directions of that Axis. With Layers set to 1, Cells adjoining empty space are flagged; deeper layers flood inward through occupied Cells. With Layers at 0 or below, no Cell is flagged. When all three Axes are disabled, a Warning is shown and no output is produced.

The output boolean list matches the input list order one-to-one. A convenient workflow is to feed the boolean pattern into a Dispatch component to split the Cells (or their resulting Slots) into boundary and interior groups, then apply different constraints to each.

Inputs

Outputs

4.2.5 Deconstruct Cell

Envelope • Nickname: DeconCell • Exposure: secondary

Extract the center plane, diagonal dimensions and Axis intervals from a Cell. Useful for working with the geometry of individual Cells directly, for example to generate Module geometry at a Cell’s exact position and size.

Behavior

Decomposes each Cell in the input tree into its geometric components. Each output item is placed at the input path with the Cell's item index appended. If any Cell is null or invalid, one Error names every offending tree position and the component produces no output.

Inputs

Outputs

4.2.6 Grid Topology

Envelope • Nickname: Topology • Exposure: tertiary

Extract the discrete grid coordinates and adjacency map of an Envelope. For each Cell, the component reports its integer position in the grid and which other Cells are its neighbors. Useful when reasoning about spatial relationships within the Envelope in Grasshopper - for example, to drive custom Module allowances based on grid position.

Behavior

The Relative Coordinates output gives each Cell’s integer (column, row, layer) position within the grid, expressed as a Point. These are not world-space coordinates - they are grid indices counted from the minimum corner of the grid's extent. Position (0, 0, 0) need not contain a Cell.

The Topology output is a tree where the input branch path with Cell index N appended contains the indices of Cell N's neighbors. By default, Diagonal Neighbors is false (Face neighbors only) and Bi-Directional Topology is true (neighbors in both Directions). Enabling Diagonal Neighbors includes edge and corner neighbors; disabling Bi-Directional Topology keeps only neighbors in the positive X, Y, and Z Directions.

Inputs

Outputs

4.2.7 Neighbor Cells

Envelope • Nickname: Neighbors • Exposure: tertiary

Find the Cells that are adjacent to a given set of focus Cells. Given Cell Indices, the component returns Neighbor Indices for Cells within the specified number of Layers along the enabled Axes. Useful for selecting “everything around” a particular sub-region of the Envelope.

Behavior

The search covers a box measured in grid steps along each enabled Axis, including diagonal neighbors. With Layers set to 1 and all Axes enabled, it can return up to 26 neighbors per focus Cell. Include X, Include Y, and Include Z restrict the search to the selected Axes. Focus Cells are excluded, and the output indices are unique and sorted in ascending order.

A typical workflow is to use the Are Cells Boundary component to get boundary indices, then feed those into Neighbor Cells to find the row of Cells just inside the boundary. You can then use a Dispatch component to separate Neighbor Cells from the rest and apply different Module allowances to each group.

Inputs

Outputs

4.2.8 Cells from Geometry

Envelope • Nickname: GeoGrid • Exposure: septenary

Generate a set of Cells whose Cells cover the shape of input geometry. Use this to define a non-rectangular Envelope that follows an arbitrary form - for example a curved building mass, a terrain surface, or a point cloud.

Behavior

The Populate Method input selects Surface Wrap, Fill Volume, or Surface Wrap + Fill Volume (the default). For Meshes, Surfaces, and Breps, Surface Wrap marks a Cell when the surface overlaps its box; Fill Volume marks a Cell when its centre lies inside a closed volume. Curves and Points are sampled. Interior Only keeps only Cells marked by Fill Volume but not Surface Wrap and skips Curve samples on a Cell Face.

A Mesh, Surface or Brep that does not enclose a volume (an open shell such as a box without a lid, a tube or a flat sheet) is never filled: it is voxelized by its surface only. Fill Volume and Surface Wrap + Fill Volume then give the same Cells as Surface Wrap, and Interior Only gives none. The component names such a shape in a remark. Closed solids are filled as usual.

Cells are aligned to the Base Plane and centred at integer multiples of the Cell Diagonal from its origin. Snapping to Cell boundaries uses the document tolerance, capped at 2% of a Cell; the component reports when it applies this cap.

Supported geometry types: Points, Curves, untrimmed Surfaces, Breps, and Meshes. Trimmed surfaces should be converted to Breps before use (use the Convert to Brep component in Grasshopper).

Inputs

Outputs

4.3.1 Get Module Faces

Face • Nickname: ModFaces • Exposure: primary

Deconstruct a Module into its externally visible Faces, one list per Direction output.

Behavior

Reads the Module's externally visible Face set and outputs each Direction as a separate FaceId list. A single-Cell Module produces one FaceId per Direction (6 total), spelled +X..-Z. A Multi-cell Module may produce several per Direction - one per footprint Cell whose Face in that Direction is not covered by another Cell - numbered +X0, +X1, ... in spatial Cell order. Returns error if the Module is null or invalid. Also previews each Face directly on the Module in the viewport, using the same rectangle/arrow/Direction-label glyph as Preview Faces, so the outputs can be told apart by eye without wiring a separate preview component.

Inputs

Outputs

4.3.2 Analyze Face

Face • Nickname: AnalyzeFace • Exposure: secondary

Analyze Face properties including geometry, Direction and Rule/Connector usage. Provides Direction flags, Face planes, rectangles, and used/unused classification.

Behavior

Looks up each Face’s Module, extracts Face plane and rectangle geometry, determines Direction flags, and checks Rule and Connector references. A Module wired into Face or Module is expanded into its six Faces with a Remark. Faces naming an unknown Module or no external Face of their Module produce an Error and no output. Without Modules, a Warning says Face Planes and Rectangles could not be determined. Builds output trees parallel to the input Face tree.

Coverage is read per Cell, the same way Used Faces reads it. A reference that names a Cell ordinal, such as big:+X1, covers that one Cell’s Face; a reference without an ordinal, big:+X, covers the whole side - every Cell of the Module exposing that Direction.

Inputs

Outputs

4.3.3 Compare Faces

Face • Nickname: CompFaces • Exposure: secondary

Compare two Faces for identity, Module membership and Direction relationship.

Behavior

Identical is true only when Module Name, Direction and Cell ordinal all match; a whole-side Face and a per-Cell Face on the same side are different. Same Direction and Opposite Direction compare only Direction; Skew Direction is true when the Axes differ. A null or invalid Face, including a Module wired as a six-Face wildcard, raises an Error and produces no output.

Inputs

Outputs

4.3.4 Faces from Point

Face • Nickname: FacesPoint • Exposure: tertiary

Detect Module Faces at a point location. Returns all Faces whose geometry contains the given point.

Behavior

Tests the point against external Faces of each Module with a tolerance of 0.01 model units. Each Face returned for a Multi-cell Module carries its Cell ordinal. If no Face matches, a Warning states that the point does not mark any FaceId; multiple matches produce a Remark that the point marks more than one FaceId.

Inputs

Outputs

4.3.5 Touching Faces from Slots

Face • Nickname: FacesFromSlots • Exposure: tertiary

Scan Slots and extract touching Module Faces where adjacent Slots meet. Useful for discovering which Module Faces need Rules.

Behavior

Builds a spatial index of Slot positions, finds adjacent Slot pairs along each Axis, and extracts Face pairs where Faces touch. Groups results by source (positive-Direction Faces) and target (negative-Direction Faces). Each branch of the input is processed independently. Non-deterministic Slots produce all possible combinations with a warning.

Inputs

Outputs

4.3.6 Used Faces

Face • Nickname: UsedFaces • Exposure: tertiary

Filter Module Faces by Rule, Connector, and Terminator coverage. Partitions every Module’s external Faces into used (referenced by at least one Rule, Connector, or Terminator) and unused (no reference). Wire the Unused output into Construct Terminator to mark uncovered Faces as boundary-safe, or use it to assign indifference Connectors.

Behavior

Collects all Face references from Rules (source and target), Connectors (Module + Face Index), and Terminators into a set, then tests every external Face of every input Module against that set. All three reference inputs are optional; when none is provided all Faces are reported as unused. Output trees mirror the input Module tree structure with one grafted branch per Module.

A Multi-cell Module exposes one Face per Cell in each Direction, so coverage is read per Cell. A reference that names a Cell ordinal, such as big:+X1, covers that one Cell’s Face. A reference without an ordinal, big:+X, covers the whole side: every Cell of the Module exposing that Direction. Construct Assembly reads the same two forms the same way, so what this component reports as covered is what the Assembly treats as constrained.

Inputs

Outputs

4.3.7 Group Faces by Voxels

Face • Nickname: GrpFacesVox • Exposure: quarternary

Groups Module Faces by identical voxel fingerprint. Uses Face-local bidirectional ray scanning to build voxel fingerprints and groups Faces whose fingerprints are structurally identical.

Behavior

The Modules input is flattened into one list. The component builds a voxel fingerprint for each external Face via bidirectional ray scanning and groups Faces by exact fingerprint equality without testing rotations. Faces with no occupied voxels are skipped. Face Groups has one branch per group at path {g}. The viewport previews each group's voxel fingerprints as wireframes in a distinct colour.

Inputs

Outputs

4.3.8 Preview Faces

Face • Nickname: FacesPreview • Exposure: septenary

Visualize Faces with their geometry, anchor planes and Direction indicators. Display-only component (no geometry outputs).

Behavior

Draws each Face from Faces or Modules as a rectangle with a name label and Direction arrow colored by Axis (X = red, Y = green, Z = blue). A Module wired into Faces or Modules is expanded into its six Faces with a Remark. Null Faces or Faces naming a Module absent from the Modules input produce an Error and nothing is drawn. Baking to Rhino writes a rectangle, a text dot with the Face name and a Direction line per Face, grouped and colored by Axis.

Inputs

4.4.1 Construct Assembly

Main • Nickname: Assembly • Exposure: primary

Build a complete Discrete Assembly in a single step. Expands rotation variants, transforms Connectors to match rotated Modules, generates Rules from Connectors and Connector Pairs, removes Disallowed Rules, enforces Exclusive Rules, applies Indifference for unconnected Faces, merges all Rule sources, deduplicates Rules, runs a full Audit, and packages everything into an Assembly consumed by the Solver. Modules may share a name only when they are rotation variants from Module Rotations, which merge into one Module; any other repeated Module Name is an Error.

Behavior

Construct Assembly performs rotation expansion on Modules with Rotational Freedom, remaps existing Rules for the new variants, transforms Connectors to match the expanded variants, generates explicit Rules from Connectors and Allowed Connector Pairs (respecting symmetry flags and rotations), merges these with manually provided Allowed Rules, removes Disallowed Rules (explicit and from Disallowed Connector Pairs) - including automatic expansion of Disallowed Rules through all rotation variants - enforces Exclusive Rules (explicit and from Exclusive Connector Pairs) by removing all other Rules referencing the same Faces, deduplicates Rules, optionally generates Indifferent Rules for uncovered Faces, and runs the same Audit logic as Audit Assembly. Several Connectors may occupy one Module Face: the Face accepts every neighbour any of them mates with. Only exact repeats and per-Cell Connectors covered by a whole-side Connector in the same Direction are dropped. A Multi-cell Module whose Cells do not form one Face-connected block raises an Error.

During Rule remapping, each rotation variant receives a Face permutation that maps original Face Indices to their new positions after rotation. When both sides of a Rule are rotation-expanded, only variants with the identical rotation (same Face permutation) are paired - the spatial neighborhood rotates as a rigid unit. Mismatched rotations would produce geometrically wrong Rules even when Face Directions remain opposite. When only one side is expanded, only the rotated side’s Face Index is permuted.

The output Assembly is an opaque container. Connect it to the WFC Solver, to a Deconstruct Assembly component for inspection, or to Materialize Assembly after solving. The Indifference input defaults to true and generates Rules for otherwise uncovered Faces.

Slot Priorities (SP) supplies per-Slot solve priorities parallel to Slots, defaulting to 1.0. When the list is shorter than Slots, its last value repeats; more priorities than Slots raise an Error. Fractional parts are dropped before priorities reach the engine. Remove Unused Connectors (RU) defaults to false. A Connector Name absent from all Allowed Connector Pairs produces a Warning because it generates no Rules; enabling RU drops those Connector assignments and reports the count in a Remark, making their Faces eligible for Indifference. Require Terminators (RT) defaults to false. Terminators (T) have an effect only when RT is enabled; supplying them with RT off produces a Warning. With RT on, each exposed Slot Face on a non-flat Axis must be filled by a Module with a Terminator on the matching Face. Flat-Axis Faces of a 2D Envelope need none.

Construct Assembly stores the source project on its output Assembly. Use Export Project… on the WFC Solver's right-click menu to save it before or after solving. The file includes inline OBJ geometry but no solved Slot states or WFC Solver Random Seed.

Allowed Connector Pair deduplication. Construct Assembly removes exact-duplicate Allowed Connector Pairs from the input list before generating any Rules. A single Remark reports how many duplicates were dropped. A→B and B→A remain separate entries; both produce the same Rules, and the resulting duplicate Rules are removed.

Allow-all Slot resolution. Construct Assembly resolves allow-all Slots (Slots created without explicit Module Names) against authored Modules before rotation expansion. A Module fits if any one of its Cells matches the Slot's Cell size on all three Axes; a Multi-cell Module is listed under its authored Module Name. Each fitting name receives a Weight of 1.0. Later, every Slot's Total Modules Count is set to the number of distinct Module Names referenced by any Slot. One Remark reports the number of allow-all Slots resolved and an upper bound on Modules per Slot. An allow-all Slot with no fitting Module raises an Error and stops the component.

Extending Rules and Connectors. A Rule, a Connector, or a Connector Pair may reference something the Assembly does not contain - a Rule or Connector naming a missing Module, or a Connector Pair naming a Connector that no Connector defines. These are treated as extending references rather than errors: the Solver ignores any Rule it cannot tie to a real Module, so Construct Assembly keeps building and reports them as a Warning naming what was unmatched. This applies to the Allowed, Disallowed, and Exclusive Rule and Connector Pair inputs alike (Terminators on a missing Module are likewise dropped with a Warning). A Module itself must still be complete - a Module Face with no Rule and no Connector is reported as uncovered, below.

Uncovered-Face diagnostics. Two separate Warnings report Faces not described by any Rule or Connector: one for authored Modules and one for rotation variant Modules. With Indifference off, an uncovered authored Face marks the Assembly invalid, and the WFC Solver refuses it. Uncovered rotation variant Faces do not invalidate the Assembly; the Solver may eliminate those variants. The coverage verdict is computed by the engine from the final Rule set, so enabling Indifference (which injects covering Rules) clears it. The output Discrete Assembly marks such Faces in the viewport with a red circle-and-cross badge on the Module preview.

Slot-fault diagnostics. Slot-level faults are marked the same way: every Slot that refers to an unknown Module Name, or whose allowed Modules have no variant with matching dimensions (the Audit's Slots With Unknown Modules and Slots Without Fitting Modules), gets a red circle-and-cross badge laid flat at the Slot box centre. The marks are recomputed on every solve, so they clear as soon as the fault is resolved. Use the Audit Assembly report to see which fault class each marked Slot falls into.

Rule preview and appearance. The output Assembly draws its Rules as preview wires colored by kind - Allowed green, Disallowed red, engine-generated Indifferent blue - matching the web Rules graph. Preview Rule draws arbitrary Rule lists in one neutral grey. Authored Rules are drawn as wired, including Disallowed Rules on a collapsed Envelope Axis; Clean up removes Rules that can never apply. Authored per-mesh display colors of the source geometry are carried into the project file written by Export Project… on the WFC Solver as per-mesh materials, so a Module assembled from differently colored meshes keeps each color.

Clean up. Clean up defaults to false. When enabled, Construct Assembly drops Rules that can never apply to the Slot layout and Modules left unplaceable by that pruning. A Rule cannot apply when its two Faces are not opposite under any allowed rotation (a cross-Axis pair like -X to +Z is never a real adjacency), when its Axis is collapsed (a flat Envelope has no neighbour along it), or when its two Modules are never allowed in two adjacent Slots; such Rules leave both the effective Rule set and the Disallowed-Rule preview. Any authored Module with no surviving rotation variant after this pruning is removed from the Assembly's Module set and every Slot's allow-list. Clean up also runs constraint Propagation, narrowing each Slot to the Modules that can occupy it. If this leaves a Slot with no valid Module, a Warning reports the Contradiction. Clean up does not remove Connectors. With Clean up off, Construct Assembly does not perform this trimming; the Solver still runs constraint Propagation and prunes dangling references when a session starts. Clean up only shows a trimmed Assembly at Construct Assembly and does not change the solve result.

Partial and invalid Assemblies. Recoverable build problems, including required Terminators with none provided, an empty Envelope (no Modules or no Slots), and uncovered authored Faces with Indifference off, produce an invalid Assembly. Other engine build problems are reported as Warnings and also invalidate the Assembly. Construct Assembly builds the most complete Assembly it can and reports the problems. An empty Envelope still emits an Assembly carrying whatever Modules and Slots were authored. The WFC Solver refuses an Assembly whose IsValid flag is false.

Inputs

Outputs

4.4.2 Growth Solver

Main • Nickname: Grow • Exposure: primary

The Growth Solver takes a Discrete Assembly and places Modules one Slot at a time. The WFC Solver Attempts to fill the Envelope in one solve; Growth Solver steps can leave a partial Assembly and apply supply caps. It uses the same native engine and constraint Propagation. It returns the grown Assembly, a Report, and Settled, Placed, and Empty outputs.

Behavior

Set Run to true to start. When Run is false, the component shows Idle, warns Set Run to True to grow., and reports GROWTH SOLVER IDLE. An invalid Assembly produces Assembly is invalid: <reason>. Supply lists of different lengths produce Supply Names and Supply Caps must have the same length.; Steps below 0 produces Steps must be 0 or more. An Assembly without serialized engine data produces Assembly has no serialized engine data. Engine or growth session failures are reported as errors. These cases leave the Assembly output empty. If the native library is blocked, the component reports its error and shows Library blocked.

Every Slot starts with its allowed Modules and an internal empty candidate. No Slot counts as placed at the start, including one that allows only one Module. On each step, the Growth Solver considers unresolved Slots that still have a Module candidate and share a Face with a Slot holding a placed Module. This set is the frontier. If it is empty, all unresolved Slots with a Module candidate are eligible. The Growth Solver keeps only those with the highest Slot Priority and picks one uniformly at random. It then chooses a remaining Module candidate that has not reached its supply cap, using the Slot's per-Module Weights. Without authored Weights, candidates have Weight 1.0; with authored Weights, a Module's Weight is divided among its eligible rotation variants. Constraint Propagation then removes Modules disallowed by Rules in neighbouring Slots.

A Slot whose Module candidates are all removed settles empty without a Contradiction. The internal empty candidate accepts any neighbouring Module on any Face; Rules restrict pairs of placed Modules. The Growth Solver respects Terminators, Require Terminators and Slot Priorities from Construct Assembly, and sparse Envelopes.

With Stop When Settled false (the default), an empty frontier causes growth to start in another eligible region. With it true, growth stops after the first frontier-connected region resolves and at least one Module has been placed, leaving other regions unresolved. Steps defaults to 100 and limits the number of steps; each step places at most one Module. Growth can stop earlier when no placement remains, Stop When Settled ends it, or the engine reports a settled or Contradictory Envelope. 0 steps places nothing. Pressing Escape stops growth between batches of 256 steps and returns the result reached so far.

The output Assembly lists the surviving real Modules at each Slot. An empty Slot lists none. Placed counts authored Slots that Growth has placed; Empty counts authored Slots with no compatible real Module. A Slot with one visible Module candidate can still be unplaced while the internal empty candidate remains, so it does not count as Placed. Settled is true when no Slot can still receive a Module, and false while unresolved Slots remain. Materialize Assembly skips empty Slots with a N contradictory slot(s) skipped. Warning and Slots with multiple remaining Modules with a N non-deterministic slot(s) skipped. Warning.

The Report states whether all Slots resolved, the step budget ended with undetermined Slots, or growth stopped early. It lists Total Slots, Placed, Empty, Undetermined, Steps performed, and Duration, plus SUPPLY CAPS when Supply Names is wired. After a run, the component message is Settled or the Placed count followed by placed.

Supply caps

Supply Names and Supply Caps are parallel lists of authored Module Names and maximum instance counts. A Module absent from the lists has unlimited supply. A cap covers every rotation variant and decomposed part of that Module. The first part of a Multi-cell Module reserves one instance; its remaining parts can still be placed after the cap is reached. The Growth Solver then removes candidates that would start another instance and propagates the change; other Slots can settle empty. A cap of 0 prevents placement, and a negative cap is applied as 0. Enter Supply Names in lowercase to match Module Names. Names that match no Module are ignored without a message.

Seeds

Random Seed defaults to 42. The same Seed, Assembly, Steps, Stop When Settled, and supply settings produce the same result. Changing the Seed changes the random choices and may produce a different growth pattern. Each run performs one growth, without parallel Attempts.

Limits

On the free tier, Growth Solver and WFC Solver runs share one run budget per fixed time window. A run is charged when Run is true, the Assembly is valid, and the engine Assembly and growth session have been built, before the first step and regardless of Steps. When the budget is exhausted, the component reports an Error with the reset time, shows Limit reached, and reports GROWTH SOLVER BLOCKED. The component footer shows the remaining-run counter, and after a completed run a Remark reports how many runs remain.

Run input gate

Run is a boolean input that defaults to false. Set it to true to grow the Assembly. Connect a Boolean Toggle or a Button component.

See also FAQ 1.77 What is the Growth Solver?.

Inputs

Outputs

4.4.3 Deconstruct Assembly

Main • Nickname: DeconAssembly • Exposure: secondary

Extract all authored inputs from a Discrete Assembly: Modules, Slots, Connectors, Connector Pairs, Rules, Terminators, and the Indifference and Require Terminators flags.

Behavior

Extracts the authored side of the Assembly container before rotation expansion and Rule generation. Allow-all Slots contain their resolved Module Names. When Clean up is on, authored Modules with no surviving rotation variant are removed from the Modules output and from every Slot's allow-list. Rotation variants generated from each Module's Rotational Freedom are not included; use Dissolve Assembly to access the expanded Solver-ready state. An invalid Assembly is accepted and its reason is reported in a Remark.

After solving, the Slots output returns authored Slots with narrowed Module Names: rotation variants in each solved Slot are projected back to their source Module Name, and the result is intersected with the authored Slot's Module Names list so order and Weights are preserved. Diagnostics are available from Audit Assembly.

Inputs

Outputs

4.4.4 Dissolve Assembly

Main • Nickname: DisAssembly • Exposure: secondary

Extract the fully expanded Solver-ready state from a Discrete Assembly: one Solver Module per rotation variant and, for Multi-cell Modules, per Cell; the authored Slots with narrowed domains when Require Terminators is enabled; Explicit Rules; and Indifferent Rules. Solver Module Names are engine-internal keys, while each entry carries its authored source Module Name. Explicit Rules include manual and Connector-generated Rules; Indifferent Rules cover otherwise uncovered Faces. Invalid Assemblies are accepted with a Remark naming the reason. For the authored inputs use Deconstruct Assembly instead.

Inputs

Outputs

4.4.5 WFC Solver

Main • Nickname: WFC Solver • Exposure: tertiary

The WFC Solver runs the Wave Function Collapse algorithm on the supplied Envelope. It takes a Discrete Assembly as its sole data input, progressively eliminating Module candidates from each Slot - guided by adjacency constraints and weighted Entropy - until every Slot holds exactly one Module, or the Attempt ends in a Contradiction. Returns an output Assembly with solved Slot states, status flags, Seed values, and a Solver log.

Behavior

Before starting, the Solver validates its inputs and builds the engine Assembly. It then runs the first Attempt with the selected Seed; an already Deterministic or Contradictory Envelope ends that Attempt immediately.

The first Attempt runs on one thread. If it is not Deterministic, or Return first is false, the Solver runs additional Attempts when Max Attempts is greater than 1. It uses at most the smaller of the logical processor count and Max Attempts minus one worker threads, with Seeds increasing from the first Seed. Pressing Escape while these Attempts run stops further Attempts after the running ones finish. With Return first enabled, the lowest-Seed Deterministic result is returned, or the lowest-Seed partial result if none is Deterministic. Otherwise all non-Contradictory results are returned in Seed order; if every Attempt contradicts, the lowest-Seed Contradictory Assembly is returned.

Each Attempt works by repeating two steps. First it picks the Slot with the fewest remaining candidates and assigns it a single Module, making it Deterministic (an Observation). Then it cascades the consequences of that choice through the whole Envelope, eliminating Module candidates that would violate Rules with neighboring Slots (this is called Propagation). The cycle ends when every Slot is Deterministic, a Slot is Contradictory, or Max Observations is reached. Reaching the Observation limit gives a partial result. The default limit is effectively unlimited.

The Report output summarizes the result, input Slots, Modules, Placements, total unique Rules, number of Attempts, successful Seeds, observations, and stage durations. It also reports whether parallel solving ran and how many processor cores it used. When the Assembly is invalid, it gives a reason and suggested fixes; when Run is false, it reports that the Solver is idle.

If an Attempt stops with a partial solution at the Observation limit, pass an Assembly from the Assemblies output to another WFC Solver to continue solving it. To inspect its Slots, connect that Assembly to Deconstruct Assembly.

Seeds

The Random Seed input controls the starting point for the Solver's random choices. For the same Slots, Modules, and Rules, the same Seed always produces the same result. Seeds themselves have no inherent meaning - they are arbitrary integers that initialize the random number generator. There is no relationship between the Seed value and the visual outcome; consecutive Seeds (e.g. 42, 43, 44) give independent, unrelated results. To explore the solution space, increment the Seed by 1 for each variation, or use Return First = false with Max Attempts set to the desired number - the Solver automatically increments the Seed for each Attempt. When a result is satisfactory, record the Seed from the Seeds output to reproduce it exactly later.

Indifferent Faces

A single-Cell Module has six Faces, one per Direction. A Multi-cell Module has an external Face for each footprint Cell that exposes a Direction. To be valid for solving, every Face that appears on a Module allowed in at least one Slot must be referenced by at least one Rule. A Face with no Rule provides no instruction: the Solver cannot determine what that Module may be placed next to.

Indifferent Faces are Faces with no explicit Rule that are automatically allowed to connect to any other uncovered Face facing the opposite Direction on the same Axis. Construct Assembly generates these pairings and stores their Rules in the Assembly. The effect is equivalent to having manually written a Rule that permits all uncovered Faces to freely connect to each other - which is the same behavior as the Indifferent Rule in Monoceros 1.

This behavior is controlled by the Indifference input on Construct Assembly. When enabled, Construct Assembly generates Indifferent Rules for uncovered Faces before packaging the Assembly. When disabled, any uncovered Face is treated as a hard error.

To inspect which Faces are uncovered before solving, use the Faces Not In Rules output on the Audit Assembly component. Connect those Faces to a Preview Faces component to visualize them in the viewport, or use them as input to a Rule-construction component to add explicit Rules for those pairs.

The Audit Assembly report marks uncovered Faces as warnings - not errors - because Construct Assembly can handle them via indifference. Slots Suitable for Solver checks only whether the Slot Cells form a complete Axis-aligned 3D lattice, with uniform spacing per Axis and no gaps, overlaps, or duplicates. Uncovered Faces, unknown Module Names, and Contradictory Slots do not change this output.

The Solver's Report includes explicit and Indifferent Rules in its total unique Rule count; it does not show the Indifferent count separately.

Limits

The free tier gives the WFC Solver and Growth Solver one shared limited number of runs per fixed time window (windows are aligned to UTC clock boundaries); paid tiers (Annual, Edu, Lifetime) are unlimited. One WFC Solver run is charged when Run is true, the Assembly is valid, and the engine Assembly has been built, immediately before the first Attempt, regardless of Max Attempts. The component footer shows a live counter indicating how many runs remain and when the window resets.

Regardless of tier, the engine supports at most 16,370 Solver Modules. Every rotation variant and every Cell part of a Multi-cell Module counts separately when a Slot allows its name and that name appears in an opposing Rule. Construct Assembly warns and emits an invalid Assembly if this limit is exceeded; the Solver refuses to run that Assembly. Reaching the free-tier run limit instead blocks the Solver before the first Attempt.

Run input gate

The WFC Solver has a mandatory boolean Run input (default false). The Solver only executes when Run is explicitly set to True, which prevents upstream slider changes from accidentally burning through the free tier's run budget. Connect a Boolean Toggle or a Button component.

Export Project…

Right-click the WFC Solver and select Export Project… to write a portable Monoceros project file as JSON with inline OBJ geometry. The file contains the source setup authored in Construct Assembly: Modules and their geometry, Slots, Rules, Connectors, Connector Pairs, Terminators, and Construct Assembly settings. It contains no solved Slot states or WFC Solver inputs such as Random Seed. The file is identical before and after solving.

The menu item first reads project data from the first Assembly on the Assemblies output that carries it. If none carries project data, it reads the Assembly on the input, so you can export before solving. If neither has project data, a No exportable project found. dialog asks you to wire an Assembly from Construct Assembly into the Solver. Assemblies from older Grasshopper files, or ones for which Construct Assembly reported Project export and analytics could not be read from the engine: …, do not carry exportable project data.

The save dialog is titled Export Monoceros Project and suggests monoceros-project.json. The component appends .json if the chosen name lacks it. A write failure shows Failed to write project file: followed by the reason.

Inputs

Outputs

4.4.6 Audit Assembly

Main • Nickname: Audit • Exposure: quarternary

Analyze a Discrete Assembly for consistency and errors. Reports missing Modules, unfitting Modules, Unused Faces and other issues that may block solving or materialization. Run this component before the Solver to catch setup problems early.

Behavior

Performs comprehensive validation: verifies Slots form a valid grid, cross-references Modules against Slots and Rules, detects orphaned or unused components, identifies dimension mismatches, checks for redundant Rules, self-connecting Modules, and potential over-constraint. The text Report has OVERVIEW, GRID, SLOTS, MODULES, RULES and DISALLOWED FRACTION (LOVÁSZ LOCAL LEMMA) sections; conditional sections such as SELF-LOOP MODULES, POTENTIAL OVER-CONSTRAINT and ALL FACES INDIFFERENT; and a closing TERMINATORS section showing whether Require Terminators is active and which Face Directions are covered or missing. Invalid Assemblies are accepted: a Remark gives the reason and the component still fills its outputs. All diagnostic outputs are available.

Faces not covered by any Rule are reported as warnings rather than errors because indifference on Construct Assembly (when enabled) automatically generates matching Rules for such Faces. The Faces Not In Rules output provides the actual Face objects for visualization or further use.

Allow-all Slot check. Audit flags any Slots that are still in the allow-all state as an Error - Construct Assembly is expected to resolve them before the Audit runs, so an unresolved Slot indicates that the pipeline was bypassed. Slots that were originally allow-all but have since been resolved are reported as an informational Remark so the user is reminded that the Module set was wired implicitly for those positions.

Face Disallowed Fraction. A continuous per-Face over-constraint measure, the graded generalization of Singly Constrained Faces and Potential Over-Constraint. For each oriented Face it reports the share of dimension-compatible opposing Module Faces that no Rule permits as a neighbour, from 0 (every fitting neighbour allowed) to 1 (none allowed); a value of -1 marks a Face with no candidates because its Axis is a single-Slot grid Axis, so it can only meet the boundary. The Report adds one honest summary line from this: the worst Face, its fraction, and a conservative Lovász Local Lemma solvable annotation with its margin - an annotation only, never a solvability guarantee, since it reads false for nearly every authored config.

Diagnose Resolution. Off by default so the Audit stays fast. When enabled, Audit runs a Deterministic diagnostic solve (Seed 0) with resolution tracking and reports on the Resolution output how the Solver settles the Envelope: how many Slots it directly observed (chose and collapsed, with the observe order), how many Propagation resolved as a side effect, and how many were left unresolved, then one line per resolved Slot as [order] KIND slot@(x,y,z) module. This is the same per-Slot provenance the engine emits after any solve, so you (or an LLM) can see the actual order the Envelope collapsed and locate where a solve stalls. It is most informative on an unsolved Assembly straight from Construct Assembly; an already-solved input reports every Slot as Propagation, because its initial Canonicalization determines every Slot before any Observation.

Rules Never Firing. Lists every authored Allowed, Disallowed and Exclusive Rule the Solver can never apply, each tagged with its kind: no allowed rotation of its two Modules brings the two Faces into opposition (for example a +X Face against a +Z Face on Modules without Rotational Freedom), or the two Modules are never allowed in adjacent Slots. The engine decides this per Rule on the rotation-expanded pairs and the Slot layout, the same check Construct Assembly uses when Clean Up is on. The Report adds one row to its Rules section with the count per kind. Such Rules are normal when Modules cannot rotate into each other: the Solver ignores them, and no component shows a warning or error for them.

Inputs

Outputs

4.4.7 Materialize Assembly

Main • Nickname: Materialize • Exposure: quarternary

Extract placed geometry from a solved Discrete Assembly. Takes an Assembly as input and produces geometry. For every Deterministic Slot, it looks up the assigned Module (including rotation variants), finds the variant whose dimensions match the Slot’s Cell box, and moves and orients the Module geometry into place. The output is ready to bake, render, or process further in Grasshopper.

Behavior

Each Deterministic Slot is matched to the Module Variant whose name and Cell dimensions agree. The Module geometry is transformed from its original position into the Slot’s position and Orientation via a plane-to-plane mapping. Non-deterministic Slots (still carrying multiple candidates) are skipped. Contradictory Slots (zero allowed Modules) produce no geometry.

When multiple Module Variants share the same name and dimensions, only the first matching Variant in Assembly order is placed. The others are unused. The Modules With Identical Names and Dimensions output of Audit Assembly flags these duplicates.

Multi-cell Modules Materialize once per placed instance. A Multi-cell Module occupies one Slot per footprint Cell; the engine reports which placed Cells belong to which instance (grouping them by Module, rotation and anchor Cell) and the Module's geometry is emitted exactly once per instance. Every Cell carries the whole Module, so an instance cut by an open Envelope boundary materializes from whichever Cells are inside, with the geometry overhanging the Envelope where the missing Cells would sit. Each output tree path is {assembly iteration; slot index}; for a multi-Cell instance, this is the Slot index of its anchor Cell, the lowest-numbered footprint Cell present inside the Envelope. A Contradictory Slot costs only its own instance: instances elsewhere in the Envelope still Materialize. The component warns about skipped Contradictory or Non-deterministic Slots and reports unknown Module Names or missing dimension matches as errors. Baking creates one shared Rhino block definition per placed Module Variant and one block instance per placement.

Inputs

Outputs

4.4.8 Sample Geometry

Main • Nickname: SampleGeo • Exposure: septenary

Create Module candidates by sampling input geometry into Cells. Chops geometry to Slot Envelopes, voxelizes for comparison, and deduplicates identical Modules. Returns Modules ready for Face analysis and Rule construction.

Behavior

For each Cell, chops geometry (curve–brep intersection, mesh splitting, brep trimming) in parallel. Voxelizes each nonempty result and deduplicates by comparing voxel patterns and box dimensions (epsilon comparison). Each new Module is named with Module Name Base followed by its Cell index (for example, module-0); a matching result reuses the earlier Module Name and increments Module Count. Only Cells containing geometry produce a Deterministic Slot with Weight 1. Empty Cells produce neither a Module nor a Slot and have -1 in Box to Module Index and Box to Slot Index.

Inputs

Outputs

4.5.1 Construct Module

Module • Nickname: ConstModule • Exposure: primary

Construct a Module from optional Module Name, one or more adjacent Cells, and optional Geometry. Modules are the building blocks placed into Slots during WFC solving. A single-Cell Module has six Faces; a Multi-cell Module has externally visible Faces numbered per Direction and Cell, such as +X0 and +X1.

Behavior

Several adjacent Cells form a Multi-cell Module that the Solver places as one rigid body; a Remark reports its dimensions, Cell count and external Face count. When Module Name is not wired, a Deterministic name with the prefix m- and five letters is generated per component instance and reported in a Remark. Names are lowercased. Coinciding Cells, Cells that do not form a grid or one Face-connected block, and Rotational Freedom outside 0-4 are Errors. Invalid Geometry items are removed with an Error; an empty Geometry list produces a Remark. Tracks geometry GUIDs. Reads Rotational Freedom (0 None, 1 X, 2 Y, 3 Z, 4 Full) and stores it on the Module. The engine generates rotation variants during the Construct Assembly build, remapping Rules and Face Indices accordingly. The expanded variants are available via Dissolve Assembly. Warns if Geometry leaves the combined bounding box of the Cells.

Inputs

Outputs

4.5.2 Deconstruct Module

Module • Nickname: DeconModule • Exposure: primary

Extract the components of a Module: name, Cells (one per footprint Cell), external Faces, geometry, Footprint, Cell Count, and validity flag.

Behavior

Outputs one Cell per footprint Cell and the Module's externally visible Faces - the Faces its own footprint does not cover, numbered per Direction. Footprint gives each Cell's integer grid offset relative to the anchor Cell, parallel to Cells; Cell Count gives the number of Cells. The lock Rules binding the Cells are engine-internal and are not reported. An invalid Module raises an Error and produces no outputs, so Is Valid is true whenever it is output.

Inputs

Outputs