Documentation Monoceros 3

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 Connector from Face. 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, so the offending point is obvious at a glance instead of only named in a warning bubble. Viewport preview draws the Connector sticker on every matched Face, identically to Connector From Face.

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

Validates the Connector name (must be non-empty, no reserved characters), the symmetry flags (at least one must be true), the Module Name, Face Direction, and Rotation. The name is lowercased automatically. 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 single items: Source Connector (item) + Target Connector (item) produces one Connector Pair (item). Compatibility is bidirectional - declaring A → B also allows B → A. Use Grasshopper’s cross-reference component to make multiple pairs from lists.

Behavior

Takes one Source Connector and one Target Connector, extracts their names, and produces a single Connector Pair object. To generate multiple pairs, use Grasshopper’s Cross Reference component on the inputs.

Inputs

Outputs

4.1.4 Deconstruct Connector

Connector • Nickname: DeconConn • Exposure: secondary

Deconstruct a Connector into its constituent parts: Connector name, rotation, Module Name, and Face id. The inverse of Connector from Face.

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. When it is, Construct Assembly caps the occupied Envelope frontier directly: every exposed Slot Face must be filled by a Module that carries a Terminator on the matching Face. Module Faces without a Terminator cannot sit at the outer edge of the Envelope; if no allowed Module can cap an exposed Face, the Assembly will contradict. No extra boundary cells are added — the grid stays exactly the cells you authored.

The optional All 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 the viewport.

String representation

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

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 (e.g. vox_0, vox_1, etc.) with the detected rotation offset. 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 random colour per Connector group. 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 every Face in every Module, checking whether the tagged point falls within the Face’s geometry. A Face matches if the point is within its boundary.

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 Face geometry for every Module Face, transforms to a normalized base plane, and compares against the exemplar Connector's Face. For each match, the component tests all four 90° rotations of the geometry pattern to detect the rotation offset. The output is a list of Connectors covering all matching Faces (including the exemplar itself), each with the correct rotation. The exemplar Connector's name and symmetry flags are inherited by all output Connectors. The component draws a viewport preview showing all detected Connectors as stickers on Module Faces (name label and symmetry arrows in the Connector’s type color, with degree labels).

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. The resulting 3D boolean fingerprint is compared at all four 90° rotations to find matching geometry with the correct rotation offset. The prototype Connector’s name and symmetry flags are inherited by all output Connectors. The prototype Face shows solid coloured voxels; candidate matches show wireframe voxel outlines with Axis colour coding. The prototype Module does not need to appear in the candidate Modules list.

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. When Connector Pairs are wired, the pairs are resolved to Rules internally and a bezier curve is drawn per Rule, using the same colour coding as 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 Grid Boxes, 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, so each cell starts exactly where the previous one ends. The resulting Grid Boxes can have different sizes in one, two, or all three dimensions.

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, Module invariants 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, both sharing the same Module Name. Rules are defined once per name and apply to every dimensional invariant of that name.

Variant design contract. Sharing a Module Name across different sizes asserts that all size variants are functionally equivalent: the Solver will allow any invariant in any position where the name fits, regardless of which size ends up there. If the connection geometry or logic differs between sizes, the two variants should have separate names and separate Rules. See example 1.8 - The invariant design contract for a detailed worked example.

The output is a flat list of Grid Boxes. Flatten the output when passing it 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 Grid Boxes, 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 output is a data tree of Grid Boxes, flattened by the component, in row-major order (X changes fastest, then Y, then Z). 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 Grid Boxes. 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 Grid Boxes 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 Grid Boxes 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.

You can restrict which Faces of the Envelope get a boundary layer using the six directional toggles. For example, disable Z+ to leave the top of the Envelope open. When working with non-rectangular (masked) Envelopes, the boundary grows the actual shape outward along its real Face - a masked sphere thickens into a shell - rather than filling out to the bounding box, so each new layer can extend past the Envelope's original extent in every enabled Direction.

Inputs

Outputs

4.2.4 Are Grid Boxes Boundary

Envelope • Nickname: AreBoxesBound • Exposure: secondary

Identify which Grid Boxes in an Envelope sit on its outer boundary. Returns a boolean per input box - true if the box is within the specified number of layers from the outer edge. Use this to separate boundary cells from interior cells to treat them differently - assign dedicated boundary Modules, restrict allowed candidates, or simply visualize the distinction.

Behavior

The component scans the Envelope from the outside inward. Any Grid Box that has fewer occupied neighbors than expected in the enabled Axes is considered a boundary box. With Layers set to 1, only the outermost ring is flagged. With 2, the two outermost rings are flagged, and so on.

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 Grid Boxes (or their resulting Slots) into boundary and interior groups, then apply different constraints to each.

Inputs

Outputs

4.2.5 Deconstruct Grid Box

Envelope • Nickname: DeconGridBox • Exposure: secondary

Extract the center plane, diagonal dimensions and Axis intervals from a Grid Box. 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 Grid Box in the input tree into its geometric components. The output tree structure mirrors the input tree. Invalid Grid Boxes produce null outputs in their branch positions (with a component warning), preserving index alignment with the input.

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 Grid Box, the component reports its integer position in the grid and which other boxes 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 Grid Box’s integer (column, row, layer) position within the grid, expressed as a Point. These are not world-space coordinates - they are grid indices. Index (0, 0, 0) is always the first box.

The Topology output is a tree where branch N contains the indices of all Grid Boxes adjacent to box N. This is analogous to the Grasshopper Proximity 3D component, but works in discrete grid-step distances rather than Euclidean distance, and respects the actual cell connectivity of the Envelope rather than raw point clouds.

Inputs

Outputs

4.2.7 Neighbor Grid Boxes

Envelope • Nickname: Neighbors • Exposure: tertiary

Find the Grid Boxes that are adjacent to a given set of focus cells. Given a list of focus indices, the component returns the indices of all Grid Boxes within the specified search distance (in grid steps) that are not themselves focus boxes. Useful for selecting “everything around” a particular sub-region of the Envelope.

Behavior

The search follows Grid Topology (not Euclidean distance), so a distance of 1 returns only directly adjacent cells, 2 includes those plus their neighbors, and so on. The focus cells themselves are excluded from the output.

A typical workflow is to use the Are Grid Boxes Boundary component to get boundary indices, then feed those into Neighbor Grid Boxes 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 Grid Boxes from Geometry

Envelope • Nickname: GeoGrid • Exposure: septenary

Generate a set of Grid Boxes 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 component samples the input geometry at grid intersection points and creates a Grid Box for each cell that the geometry passes through or contains. The Fill Method controls whether only the surface skin is covered, only the interior volume, or both.

The sampling works by testing candidate grid positions against the geometry. When a test point lies exactly on a geometric feature (such as on a surface edge or curve endpoint), the result can be ambiguous and that position may be skipped. The component reports these cases with a remark. If Grid Boxes are missing in expected positions, try slightly offsetting, scaling, or simplifying the geometry near those gaps.

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 6 individual Faces, one per output.

Behavior

Reads the Module’s internal Face array and outputs each Direction as a separate FaceId parameter. Returns error if Module is null or invalid. Also previews each Face directly on the input Module in the viewport, using the same rectangle/arrow/Direction-label glyph as Preview Faces, so the six 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. Builds output trees parallel to the input Face tree.

Inputs

Outputs

4.3.3 Compare Faces

Face • Nickname: CompFaces • Exposure: secondary

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

Behavior

Compares Module Name, Face Index and Direction. Same Axis = same or opposite; different Axis = skew.

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 point containment against each Face of each Module. Warns if point matches zero Faces; remarks if point matches more than one.

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 and Connector coverage. Partitions every Module’s six Faces into used (referenced by at least one Rule or Connector) 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) and Connectors (Module + Face Index) into a set, then tests each of the six Faces of every input Module against that set. Both inputs are optional — when neither is provided all Faces are reported as unused. Output trees mirror the input Module tree structure with one grafted branch per Module.

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

For each branch of the Modules input tree, builds a voxel fingerprint for every Face via bidirectional ray scanning. Fingerprints are grouped using structural equality on the voxel array. Faces with no occupied voxels are skipped. Output extends the input tree by one layer: each sub-branch contains Face IDs sharing the same geometry pattern.

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 rectangles at Face planes with Direction arrows colored by Axis (X = red, Y = green, Z = blue). Supports both viewport preview and baking to Rhino with grouped geometry.

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 Modules and Rules, runs a full Audit, and packages everything into an Assembly consumed by the Solver.

Behavior

Construct Assembly replaces the manual wiring pattern of Module Rotations → Rule merging → Audit with a single component. It performs rotation expansion on all Modules with rotation flags set, 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 everything, optionally generates Indifferent Rules for uncovered Faces, and runs the same Audit logic as the standalone Audit component.

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 AllowIndifferent flag is now handled here instead of on the Solver.

Allowed Connector Pair deduplication. Construct Assembly removes exact-duplicate Allowed Connector Pairs from the input list before generating any Rules. Cross-referencing Connector lists on the canvas easily produces exact duplicates, and the Rule generator is O(Modules² × Axes) per pair - deduplicating up front saves substantial computation on larger definitions. A single Remark reports how many duplicates were dropped. Note that A→B and B→A are kept as separate entries because the downstream Rule generator treats Direction as meaningful.

Allow-all Slot resolution. Construct Assembly also resolves any allow-all Slots (Slots created without explicit Module Names) it receives. After rotation expansion has produced the final Module set, every allow-all Slot is filled with the deduplicated list of Module Names, assigned uniform Weights of 1.0, and its Total Modules Count is set to match. Modules whose box dimensions do not match the Slot are filtered out, so mixed- dimension setups still produce dimension-consistent Slots. A single summary Remark reports how many Slots were resolved and to how many Modules - one Remark per Slot would flood the log for large allow-all Envelopes.

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 (directly actionable) and one for rotation variant Modules (informational - the Solver simply prunes a variant in the Directions it cannot cover). The coverage verdict is computed by the engine from the final Rule set, so enabling Indifference (which injects covering Rules) clears it. In addition, the output Discrete Assembly marks every such Face directly in the viewport with a red circle-and-cross badge on the Module preview, so the offending Faces can be found at a glance (most visible with Indifference disabled).

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 (the standalone Preview Rule component still colors arbitrary Rule lists by Face Axis). Authored Rules are drawn exactly as wired - including Disallowed Rules on a collapsed Envelope Axis - because you made them; the Clean up input below is what removes the ones that can never apply. Authored per-mesh display colors of the source geometry are carried into the exported document as per-mesh materials, so a Module assembled from differently colored meshes keeps each color.

Clean up. With the Clean up input enabled, Construct Assembly drops Rules that can never apply to the Slot layout and Modules left unplaceable by that pruning. A Rule is dead 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 neighbor 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, since the Solver can never place it. Clean up also runs constraint Propagation, narrowing each Slot to the Modules that can actually occupy it. Everything is gated on the input: left off, every Rule and Module you wired is preserved.

Partial and invalid Assemblies. Construct Assembly never suppresses its output. A recoverable build problem - required Terminators requested but none provided, or a literally empty Envelope (no Modules or no Slots) - no longer aborts the component. Instead it builds the most complete Assembly it can, reports each problem as its own Warning, and marks the Assembly invalid. An empty Envelope still emits an Assembly that carries whatever Modules and Slots were authored. The downstream WFC Solver refuses any Assembly whose IsValid flag is false, so an invalid Assembly is caught one component later with the problems already named on the canvas, rather than vanishing silently at construction time.

Inputs

Outputs

4.4.2 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 - the data exactly as supplied on Construct Assembly before rotation expansion and Rule generation. Rotation variants generated from Module symmetry flags are not included; use Dissolve Assembly to access the expanded Solver-ready state.

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 original Module Names list so order and Weights are preserved. All Audit outputs have moved to the Audit Assembly component.

Inputs

Outputs

4.4.3 Dissolve Assembly

Main • Nickname: DisAssembly • Exposure: secondary

Extract the fully expanded Solver-ready state from a Discrete Assembly: expanded Modules (with rotation variants), expanded Slots, and explicit + Indifferent Rules. For the authored inputs use Deconstruct Assembly instead.

Inputs

Outputs

4.4.4 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 all inputs and checks whether the Envelope is already Deterministic (fully solved) or already Contradictory (cannot be solved at all). If so, it stops immediately without running any solve steps.

The Solver then runs one single-threaded Attempt using the chosen Seed. This is a fast, cheap check: if the problem is easy it often finds a solution or reaches a Contradiction right away, with no extra overhead. The Solver spawns parallel workers on the remaining CPU cores - each with an incremented Seed, searching simultaneously - when that first Attempt does not produce a definitive result, or when Return First is off and every Attempt's solution is wanted (so an easy Envelope that solves on the first try still yields one Assembly per successful Seed).

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 continues until either every Slot has exactly one candidate (Deterministic - success) or some Slot has no candidates left (Contradictory - failure). A Contradictory result is retried with a different Seed.

The Solver log (Report output) shows a summary of preprocessing, the number of Rules used (including any auto-generated Indifferent Rules), and the outcome of each Attempt.

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

Every Module has six Faces - one per Face. 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. The Solver generates these implicit pairings internally at solve time. 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. The Slots Suitable for Solver output remains true even when Faces are uncovered - it only turns false for hard errors such as an invalid grid, unknown Module Names, or Contradictory Slots.

When Indifferent pairings are generated, the output log shows the total Rule count as N (M Indifferent), so you can see exactly how many Rules were auto-generated versus explicitly authored.

Limits

The free tier caps the WFC Solver at a limited number of runs per fixed time window (windows are aligned to UTC clock boundaries); paid tiers (Annual, Edu, Lifetime) are unlimited. Each Solver invocation that produces a result counts as one run regardless of the Max Attempts setting. The component footer shows a live counter indicating how many runs remain and when the window resets.

Regardless of tier, the Solver supports a maximum of 16,370 distinct Module Names across all Slots. Each rotation variant of a Module counts as a separate name - a single Module design can produce up to 24 Orientation invariants (from 90° turns around X, Y and Z Axes), so the limit accommodates roughly 682 fully-expanded unique designs, or more if not every Module uses all three rotation Axes. Exceeding this Module-name limit causes the Solver to report an error and stop without producing results.

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.

Inputs

Outputs

4.4.5 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 groups findings into Grid, Slots, Modules, Rules and warning sections. 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.

Inputs

Outputs

4.4.6 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 the same dimensions, all matching Variants are placed into the corresponding Slot. This is typically a configuration mistake and the Modules With Identical Names and Dimensions output of the Audit Assembly component will flag it.

Megamodules Materialize once per placed instance. Placed Megamodule sub-parts are grouped into instances and the Megamodule geometry is emitted exactly once per instance, sourced from the surviving part with the lowest part index (not hard-wired to _p0). Instances cut by an open Envelope boundary whose _p0 cell lies outside the Envelope therefore still Materialize from any surviving part, with the geometry overhanging the Envelope where the missing parts would sit. A Remark reports how many instances materialized from a non-primary part. The output tree path of a Megamodule instance is the representative part’s Slot index (unchanged for fully interior instances: that is _p0’s Slot).

Inputs

Outputs

4.4.7 Sample Geometry

Main • Nickname: SampleGeo • Exposure: septenary

Create Module candidates by sampling input geometry into GridBox 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 GridBox, chops geometry (curve–brep intersection, mesh splitting, brep trimming) in parallel. Voxelizes each Module and deduplicates by comparing voxel patterns and box dimensions (epsilon comparison). Creates a Slot for each box with the assigned Module Name and default Weight.

Inputs

Outputs

4.5.1 Construct Module

Module • Nickname: ConstModule • Exposure: primary

Construct a Module from a name, GridBox and optional geometry. Modules are the building blocks placed into Slots during WFC solving. Each Module has 6 Faces (one per Face).

Behavior

Validates name and GridBox. Removes invalid geometry items with warnings. Tracks geometry GUIDs. Reads the Rotational Freedom value (0 None, 1 X, 2 Y, 3 Z, 4 Full) and stores it on the Module. Construct Assembly expands this into actual rotational variants, remapping Rules and Face Indices accordingly. The expanded variants are available via Deconstruct Assembly. Warns if geometry extends significantly outside the Module's Grid Box.

Inputs

Outputs

4.5.2 Deconstruct Module

Module • Nickname: DeconModule • Exposure: primary

Extract the components of a Module: name, GridBox, geometry, validity flag and all Faces.

Behavior

Retrieves Module properties and outputs them as separate parameters. Generates a flat list of FaceId items for all 6 Directions. Warns if the Module is invalid.

Inputs

Outputs

4.5.3 Construct Megamodule

Module • Nickname: Megamodule • Exposure: secondary

Create a multi-cell Module from a name and a list of adjacent GridBoxes. Automatically creates one sub-Module per box (named {name}_p0/N, {name}_p1/N, etc. where N is the total part count), generates exclusive internal Rules, and identifies external (boundary) Faces.

Behavior

Every sub-Module receives the full Megamodule geometry so that Face suggestion components can analyze all external Faces. Materialize Assembly emits the geometry exactly once per placed instance, sourced from the surviving part with the lowest part index (for fully interior instances that is _p0), to avoid duplication. Display colors, render materials, layers, linetypes, lineweights, and print colors are captured from the referenced source objects, so the geometry previews and bakes with its original appearance.

Each sub-Module previews its sibling Grid Boxes as dashed ghost outlines, making the full Megamodule footprint visible even when viewing a single part in isolation. Sub-Modules other than the geometry-carrying part draw no geometry of their own in the viewport - every part carries the full, world-coincident Megamodule geometry, so drawing it per part would overdraw the realistic preview N times. The cage, name, and dashed peer boxes still locate these parts.

The Rotational Freedom value (0 None, 1 X, 2 Y, 3 Z, 4 Full) propagates to every sub-Module. When non-zero, the Solver automatically generates rotated variants of the entire Megamodule and remaps both internal and external Rules accordingly.

Detects adjacency when Faces Face opposite Directions and anchor plane origins coincide (within epsilon). Creates internal Rules and tracks which Faces are used. Warns if multiple boxes provided but no adjacencies found.

Inputs

Outputs

4.5.4 Deconstruct Megamodule

Module • Nickname: DeconMegamodule • Exposure: secondary

Extract GridBoxes, internal Rules, and external Faces from a set of Megamodule sub-Modules. Inspection companion to Construct Megamodule.

Behavior

Reconstructs internal Rules by comparing all Module pairs for opposite-Direction Faces with coinciding anchor planes. Remaining Faces (not in internal Rules) are output as external Faces.

Inputs

Outputs

4.5.5 Cull Duplicate Modules

Module • Nickname: CulDupModule • Exposure: tertiary

Remove duplicate Modules by comparing voxelized geometry and box dimensions. Use after generating rotated variants or importing from multiple sources.

Behavior

Voxelizes each Module in parallel and compares voxel patterns and box dimensions using epsilon comparison. Tracks index mapping and valence. If Rules provided, remaps source/target Module Names for culled Modules, creating a cartesian product of mapped names.

Inputs

Outputs

4.5.6 Module Rotations

Module • Nickname: ModuleRot • Exposure: tertiary

Generate rotated variants of a Module from a single Rotational Freedom choice. The integer input (selectable directly from its right-click menu) is 0 None (1 Orientation), 1 X / 2 Y / 3 Z (the four 90° rotations about that Axis), or 4 Full (all 24 cube orientations). It defaults to 4 (Full). Optionally deduplicates identical variants by voxel comparison.

Each option is a closed set of orientations. There is no two-Axis option: any two perpendicular Axes already generate the full 24, so anything beyond a single Axis is Full.

Behavior

Builds the rotation and translation transform for each Orientation in the chosen set. Creates rotated geometry in parallel. If deduplication is enabled, voxelizes the original Module once, then maps those voxels through each rotation's coordinate transform to produce a comparable voxel block per variant; compares patterns and box dimensions to keep only unique Modules. Variants are named with a Canonical rotation suffix (e.g. _x90, _z180, _x90y90).

Inputs

Outputs

4.6.1 Construct Rules from Faces

Rule • Nickname: RuleFromFaces • Exposure: primary

Construct Rules from two Face lists. By default (Cross Match = true), every Face in the Source list is paired with every Face in the Target list (cross product). Set Cross Match to false for element-wise pairing (first with first, second with second). This is the most common way to define Rules.

Behavior

Both opposing and non-opposing Face pairs are emitted. A non-opposing Rule (e.g. A:+X → B:+Y) is a Connector-symmetry hint that Construct Assembly expands into opposing-Face Rules referencing rotation variants of the target Module. Creates a Rule for each valid pair. Deduplicates automatically and reports duplicate count.

Only accepts explicit FaceId inputs. To pass all six Faces of a Module, extract them first using Get Module Faces.

Inputs

Outputs

4.6.2 Deconstruct Rule

Rule • Nickname: DeconRuleFaces • Exposure: primary

Deconstruct a Rule into its source and target FaceId entries.

Behavior

Extracts and outputs the SourceFaceId and TargetFaceId from the Rule.

Inputs

Outputs

4.6.3 Are Rules Equal

Rule • Nickname: AreRulesEq • Exposure: secondary

Compare two Rules for equality.

Behavior

Compares Rules using the Equals method (bidirectional: A→B equals B→A).

Inputs

Outputs

4.6.4 Detect Rules from Geometry

Rule • Nickname: DetRulesGeo • Exposure: secondary

Analyse Module Face geometry (naked edges, curves, points) and directly output Rules for all geometrically matching pairs. Combines Face suggestion and Rule construction in one step.

Behavior

Collects naked edge polylines from Breps/Meshes, open curve endpoints and point geometry. Projects onto Face planes. Compares all Face pairs, matching by equal Face dimensions and epsilon-equal point lists; there is no opposing-Direction filter, and non-opposing matches are Connector-symmetry hints expanded by Construct Assembly. Detected Rules are visualised in the viewport as bezier curves, using the same colour coding as Preview Rule.

Inputs

Outputs

4.6.5 Detect Rules from Voxels

Rule • Nickname: DetRulesVox • Exposure: secondary

Suggest Rules by comparing voxel fingerprints across all Module Faces. Uses Face-local bidirectional ray scanning to build voxel fingerprints, compares fingerprints across every Face pair and outputs a Rule for each match. Combines the fingerprint step and Rule construction into one component.

Behavior

Shoots rays from each Face plane in both Directions (inward and outward) on a uniform grid. For every Face pair with compatible dimensions, compares voxel fingerprints; there is no opposing-Direction filter, and non-opposing matches are Connector-symmetry hints expanded by Construct Assembly. Outputs Rules for all pairs whose patterns are identical. Matched Faces display wireframe voxel meshes in the viewport, coloured by Axis (X = red, Y = green, Z = blue). Fingerprint building is parallelised per Module. Bezier curves connecting each matched Face pair are also drawn, using the same colour coding as Preview Rule.

Inputs

Outputs

4.6.6 Rule from Curve

Rule • Nickname: RuleFromCurve • Exposure: secondary

Create Rules from curves drawn between Module Faces. Each curve’s endpoints are matched to Faces that contain the point. A single curve can produce multiple Rules when endpoints overlap Faces from different Modules.

Behavior

Extracts start/end points from each curve. Finds all Faces that contain the endpoint (same logic as Faces From Point). Cross-references all start/end matches and creates a Rule for every endpoint pair. Non-opposing pairs (e.g. a:+X → b:+Y) are emitted as Connector-symmetry hints that Construct Assembly expands into opposing-Face Rules through rotation expansion. Endpoints are matched with a forgiving plane-distance tolerance, so they are picked up reliably anywhere within the Face area. Previews matched curves colored by Axis. Reports skipped curves.

Inputs

Outputs

4.6.7 Rule from Points

Rule • Nickname: RuleFromPts • Exposure: secondary

Create Rules by cross-referencing Source Points with Target Points placed on Module Faces. Each source point is paired with each target point (cross reference). For longest-list matching, graft both inputs.

Behavior

Uses point-containment logic (same as Faces From Point) to identify which Face each point lands on. Iterates branches pairwise (branch N of sources with branch N of targets). For each branch pair, resolves point locations to Faces, then cross-references the resulting Face lists. Every Face pair produces a Rule; non-opposing pairs are Connector-symmetry hints that Construct Assembly expands into opposing-Face Rules through rotation expansion. Points are matched with a forgiving plane-distance tolerance, so they are picked up reliably anywhere within the Face area. Warns about points that do not land on any Face.

Inputs

Outputs

4.6.8 Preview Rule

Rule • Nickname: RulePreview • Exposure: septenary

Display Rules as lines connecting individual Faces for visual verification and baking. Display-only component (no geometry outputs).

Behavior

Finds matching source and target Module Faces for each Rule. Draws lines between Face anchor plane origins, colored by Direction Axis (X = red, Y = green, Z = blue). Supports viewport preview and baking to Rhino.

Inputs

4.7.1 Construct Slot

Slot • Nickname: SlotConstruct • Exposure: primary

Create a Slot with allowed Module Names and optional Weights. Assemble from a GridBox and a set of allowed ModuleNames. The Allowed Module Names input is optional: when omitted, the Slot is created in an “allow all” state and will be resolved to the full final Module set by Construct Assembly.

Behavior

Validates branch matching between GridBoxes, Module Names and Weights. Defaults Weights to 1.0 if not provided; extends the Weight list with the last value if fewer Weights than names. Creates Slot instances with validated inputs. A Weight of 0 or less removes the Module from the Slot entirely, turning the Weight into a hard constraint (a Remark reports how many Modules were removed). If the Grid Box input tree is empty, a Warning is shown and no Slots are produced.

Allow-all Slots. If Allowed Module Names is not connected, the component emits the Remark “No Module Names provided. Slot allows all Modules. The allowed set will be resolved by Construct Assembly.” and builds a Slot with an empty Module list. Any Weights connected alongside an empty Module Names input are ignored (a Remark is emitted). The Slot previews as white (“All allowed”) in the viewport until Construct Assembly resolves it to the deduplicated final Module Name list with uniform Weights.

AllModulesCount is no longer a user input. Every Slot leaves Construct Slot with AllModulesCount = 0 (the total Module count is not yet known). The viewport preview reflects that: the cage shows only the allowed-Module count — one number in the corner, no / total. Once the Slots pass through Construct Assembly, AllModulesCount is stamped with the size of the final Module set and the preview switches to the familiar allowed / total form. No cross-component wiring is required to keep Entropy percentages consistent.

Inputs

Outputs

4.7.2 Deconstruct Slot

Slot • Nickname: DeconSlot • Exposure: primary

Extract a Slot’s components: GridBox, allowed Module Names, Weights, determinism flag, Contradiction flag and Entropy.

Behavior

Iterates through all Slots in the input tree. Calculates Entropy as AllowedModulesCount / AllModulesCount. Skips invalid Slots with an error message. Pre-Assembly and allow-all Slots both have AllModulesCount = 0, so Entropy falls back to 1.0 explicitly — every Module is still a possibility until Construct Assembly stamps AllModulesCount with the size of the final Module set and (for allow-all Slots) resolves the allowed list.

Inputs

Outputs

4.7.3 Changed Slots

Slot • Nickname: ChngSlt • Exposure: secondary

Given an original list of Slots and one or more new Slot lists, identify which Slots changed between them. Returns a tree of indices - one branch per new list - where each index points to a Slot whose set of allowed Module Names differs from the original.