FAQ & Tips Monoceros 3

Frequently asked questions and practical tips for working with Monoceros 3. If you are new to Monoceros, start with the Quick Start guide first. For step-by-step examples and workflow strategies, see Workflows & Strategies. For data type and component reference, see the main documentation.

Bare minimum ↓ GH

The simplest possible Monoceros setup - one module, one rule, one solver call. Grasshopper file for download.

Puzzle ↓ GH

Interlocking puzzle-piece modules that can only connect one way. Grasshopper file for download.

Table of contents

• 1. FAQ
  • 1.1 What is a good exercise to start?
  • 1.2 Does the solver always fill every cell in the Envelope?
  • 1.3 What does “World state is contradictory” mean?
  • 1.4 Why can't the Solver find a solution?
  • 1.5 What makes a good Module?
  • 1.6 What makes a good Envelope?
  • 1.7 How do I handle boundaries?
  • 1.8 How do I create an “empty” Module?
  • 1.9 Why does my Module show red in the viewport?
  • 1.10 How do I control how often a Module appears?
  • 1.11 Why does a zero-weight Module still appear in the result?
  • 1.12 How do I get different results each time?
  • 1.13 How do I get reproducible results?
  • 1.14 Why does the same seed give different results after I change something?
  • 1.15 Why do some Modules never appear in the result?
  • 1.16 Can Monoceros work in 2D?
  • 1.17 What geometry types are supported?
  • 1.18 Can I use curved geometry as Modules?
  • 1.19 How do I create L-shaped or T-shaped Modules?
  • 1.20 What is the “interior geometry” design principle?
  • 1.21 Are block instances supported?
  • 1.22 Can I use Monoceros with other plug-ins?
  • 1.23 How do I ensure watertight results?
  • 1.24 What is the free-tier run limit?
  • 1.25 How do I count the Slots in my Envelope?
  • 1.26 Why does the solver fail only with larger Envelopes?
  • 1.27 Why does the solver fail with small Envelopes?
  • 1.28 How do I guarantee exactly one of a specific Module?
  • 1.29 What is All Modules Count and why does it matter?
  • 1.30 Can I use Module Rotations instead of defining every directional variant?
  • 1.31 How do I make a Module type go mostly straight instead of winding?
  • 1.32 How do I design tile Modules for a 2D layout?
  • 1.33 How do I make tiles of the same type cluster together?
  • 1.34 How do I create a mandatory buffer zone between two Module types?
  • 1.35 Can I use a hexagonal grid?
  • 1.36 What is entropy and how does it affect solving?
  • 1.37 How does randomness affect solving? Is the result entirely random?
  • 1.38 Why does a contradiction appear in a Slot far from where I made changes?
  • 1.39 Are weights a property of a Module or of a Slot?
  • 1.40 What is the “coast principle” for Module design?
  • 1.41 Why do Slot Grid Boxes in the viewport look smaller than the actual cell size?
  • 1.42 Why does the result always look the same regardless of the seed?
  • 1.43 Why do the Solver and Materialize Assembly warn about Module dimension mismatches?
  • 1.44 Is there a good or bad random seed?
  • 1.45 Can Module geometry protrude outside the Grid Box?
  • 1.46 Can I use an AI assistant (ChatGPT, Claude, etc.) to help me with Monoceros?
  • 1.47 How many Modules can the solver handle?
  • 1.48 Common Module design mistakes
  • 1.49 What are the Monoceros license tiers?
  • 1.50 What happens when my subscription ends?
  • 1.51 Why does Monoceros ask me to register?
  • 1.52 What are Connectors and how do they differ from Rules?
  • 1.53 How does the Assembly workflow work?
  • 1.54 How does Connector rotation compatibility work?
  • 1.55 Can I mix Connectors with explicit Rules?
  • 1.56 Why does Construct Assembly generate so many indifference rules?
  • 1.57 Can I create a Slot that allows all Modules?
  • 1.58 How do I create a Connector by clicking on a Module face?
  • 1.59 What is a Terminator and when should I use it?
  • 1.60 What happens when Require Terminators is on but some face directions have no Terminator?
  • 1.61 How does Require Terminators differ from manually adding boundary Slots?
  • 1.62 How do I create Terminators for all faces of a Module at once?
  • 1.63 What does “Some modules lack adjacency rules on non-flat axes” mean?
• 2. Tips & Tricks
  • 2.1 Start small, scale up
  • 2.2 Always run Audit before Solve
  • 2.3 Name Modules descriptively
  • 2.4 Use multiple void Module types
  • 2.5 Use attractor-based weight gradients
  • 2.6 Use Cross Reference for bulk Rule creation
  • 2.7 Test Rules visually before solving
  • 2.8 Bake as block instances for smaller files
  • 2.9 Use Data Recorder to save multiple results
  • 2.10 Use Add Boundary Layer for irregular Envelopes
  • 2.11 Understand the Materialize output tree
  • 2.12 Disable the Solver while editing
  • 2.13 Proto-results save computation time
  • 2.14 Use Sample Geometry to verify Module content
  • 2.15 Compare results with Changed Slots
  • 2.16 Use Module Rotations for isotropic geometry
  • 2.17 To exclude a Module from a zone, remove it from allowed names
  • 2.18 Plan Face roles before modelling geometry
  • 2.19 Let Construct Assembly stamp AllModulesCount
  • 2.20 How to allow all indifferent Faces on the boundary

1. FAQ

1.1 What is a good exercise to start?

Start with the Bare minimum example. Define two simple Modules (e.g. cubes with different colors), create Rules that allow them to be neighbours, build a small 3×3×3 Envelope, and solve. Once you see results, experiment with adding a third Module, adjusting Weights, and changing Rules.

See also workflows and FAQs: 2.1 Bare minimum, 1.1 Top-down: envelope first.

1.2 Does the solver always fill every cell in the Envelope?

Yes. WFC assigns exactly one Module to every Slot before it finishes. There is no concept of a partially solved Envelope or a cell left unassigned: the Solver either produces a complete assignment covering all Slots, or it reports a Contradiction and returns no result. Every cell will be occupied by some Module.

This surprises users who expect the Solver to skip empty areas or leave gaps where no Module fits naturally. It does not. If you want certain cells to appear visually empty - voids, gaps, courtyards, open air - you must design an explicit Module for that purpose. A Module constructed without geometry occupies the cell in the constraint system and contributes nothing visible after Materialize. Any Module whose role is “nothing visible here” - a grass lawn, a structural void, a neutral filler - serves the same function. See 1.8 How do I create an “empty” Module? and 2.3 Empty Module in the Workflows manual.

This property also explains contradictions in overconstrained setups. When the Solver reaches a Slot for which no Module satisfies all neighbour constraints, it cannot skip that Slot - it must place something, and when nothing qualifies the result is a Contradiction. Including a filler Module - one designed with permissive Face Rules that accept a broad range of neighbours - gives the Solver a legal option for those Slots, which prevents the Contradiction at the cost of introducing those filler Slots into the result.

See also workflows and FAQs: 2.3 Empty Module, 1.1 Top-down: envelope first.

1.3 What does “World state is contradictory” mean?

The Solver propagated constraints and found a Slot with zero allowed Modules. This usually means your Rules are too restrictive for the given Envelope and Module set. Try:

• Adding more Rules to increase flexibility.
• Adding an “empty” Module (a Module with no geometry) that can fill leftover spaces.
• Increasing Max Attempts - the Solver uses random choices, so a different Seed may find a valid solution.
• Using the Audit component to check for orphaned Faces or missing Rules.

See also workflows and FAQs: 2.18 Audit-driven debugging, 1.5 Debugging strategy, 2.1 Bare minimum.

1.4 Why can't the Solver find a solution?

The Rule set may be inherently Contradictory for the given Envelope size. Common causes:

• A Module that must appear but has no valid neighbour on one Face.
• A boundary Module without Rules connecting it to interior Modules.
• An Envelope too small for the Module set (some Modules require specific neighbours that don't fit).
• Conflicting constraints from weighted Slots forcing incompatible placements.

Use the Audit Assembly component to diagnose. Simplify the problem: try with fewer Module types or a smaller Envelope first.

See also workflows and FAQs: 2.18 Audit-driven debugging, 1.5 Debugging strategy.

1.5 What makes a good Module?

Module design is the single most important skill in working with Monoceros. A well-designed Module set makes Rules easy, the Solver fast, and results surprising in the right way. A poorly designed set leads to contradictions, visual artifacts, and an unmanageable Rule count. The principles below are listed roughly in order of importance.

Exciting middle, boring edges

This is the most important principle. Design each Module so that the interesting content - walls, surfaces, objects, geometry with visual character - sits in the center of the Module, not at its edges. The six Faces (the Faces of the Grid Box) should show only cross-sections of things, never complete surfaces.

Think of slicing through a wall with a knife: the cut surface (the “flesh”) appears at the Face, but the wall’s visible surface (the “skin”) stays in the interior of the Module. A Face is a mechanical interface, not a design surface.

Why this matters: the Suggest Rules From Geometry and Suggest Rules from Voxels components work by analyzing what appears at each Face. If cross-sections are predictable and boring, the components produce correct Face tags reliably. The WFC Solver then handles only the mechanical task of continuing interrupted elements across cell boundaries, while you retain full control over what happens semantically inside each Module.

Don’t touch the walls of the Grid Box

Module geometry should not touch the Faces of the Grid Box. If geometry touches a boundary, Suggest Rules From Geometry and Suggest Rules from Voxels will incorrectly infer that adjacent Modules should also have geometry at that Face, producing wrong Face tags.

Workaround for cases where geometry must extend into the neighboring cell (e.g. a bolt or bracket that protrudes): use simplified proxy geometry for Face suggestion and Rule creation, then use the detailed geometry only for materialization. Two approaches:

1. Use the transform output of the Materialize Assembly component to place complex geometry at solved positions.
2. Create two sets of Modules with identical names - one simple set for Rule suggestion, one detailed set for Materialize Assembly.

Scale heuristic: half the smallest semantic object

Module size should be approximately half the smallest semantic object in the design. For example, if the smallest meaningful element is a 3-meter room, use 1.5-meter Modules. A room corner then falls in the center of one Module (with 0.75 m of wall on each side of the corner), followed by a full 1.5 m straight-wall Module, then the opposite corner Module. Three Modules = one 3 m wall.

This “half-size” Rule ensures that semantic boundaries (corners, junctions, transitions) land in the middle of Modules - exactly where the “exciting middle” principle says they should be - rather than at Faces where they would complicate Rule matching.

Modules contain parts, not wholes

Never design a Module that represents an entire semantic object - a whole room, a whole door, a whole furniture piece. Always put a part of the object inside the Module, so that parts of neighboring objects are also present. The Solver works by connecting parts across boundaries; if a Module already contains a complete object, the connections become trivial and the result loses combinatorial variety.

Exception: objects that are significantly smaller than everything else in the system can be placed as whole Modules.

Design systems separately, connect through interfaces

When the design involves multiple independent spatial systems (e.g. a road network and surrounding landscaping), design each system’s Modules and Rules independently. Then create a small number of interface Modules that bridge the two systems. For example: road Modules connect only to other road Modules; greenery Modules connect only to other greenery Modules; a single “road edge” Module connects road sides to greenery boundaries.

This keeps complexity manageable - each system can be developed and tested independently. See 1.8 System-based Module design for a full walkthrough.

Multiple variants of the same purpose

The same functional role often needs multiple Module variants with different names and Rules. The most common case: empty-interior, empty-exterior, and empty-boundary. Each participates in different Rules even though the geometry may be identical or absent. Without distinct identities, you cannot control which “kind of empty” appears where.

Same geometry, different identity

Multiple Modules can share identical geometry but carry different names and participate in different Rules. The identity of a Module is in its name and Rule participation, not its geometry. This is a feature, not a workaround - use it freely whenever the same shape should behave differently in different contexts.

Don’t embed extra data in Modules

Keep associated data (materials, structural properties, cost, metadata) separate from Modules. Distribute it alongside geometry during the Materialize phase. Trying to pack additional data into Module geometry leads to Face matching problems and unmanageable Rule sets.

Two workflows for wall/boundary design

When Modules must represent boundaries between different zones, there are two valid approaches demonstrated in architectural examples:

• Wall-centered: The wall sits in the center of the Module (per the “exciting middle” principle). Both sides of the wall carry context from their respective zones. This is self-contained and works well with Suggest Rules, but requires designing a Module for every combination of zone types on either side of the wall.
• Boundary-split: The wall is split at the Module boundary - half the wall thickness in one Module, half in the next. Zone identity is controlled through Rules rather than Module design. This requires more Rules but fewer Modules, and works better when there are many zone types.

See also workflows and FAQs: 2.1 Bare minimum, 2.6 Working with multiple Modules, 2.27 Restricting Modules to specific regions, 1.2 Bottom-up: Modules first, 1.8 System-based Module design, 1.45 Can Module geometry protrude outside the Grid Box?, 1.40 What is the “coast principle” for Module design?.

1.6 What makes a good Envelope?

• Start with a Homogeneous Grid for simplicity. Use Heterogeneous grids only when the design requires variable cell sizes.
• Add a boundary layer of Slots filled with boundary Modules. The Solver needs to know what happens at the edges.
• For complex shapes, use Slice Geometry to convert Rhino geometry into Grid Boxes.
• Don't make the Envelope too large initially. Start with 5×5×5 and scale up once the Rules work.

See also workflows and FAQs: 2.10 Boundary handling, 2.4 Rotating the envelope base plane, 1.1 Top-down: envelope first.

1.7 How do I handle boundaries?

Monoceros 3 has no implicit boundary layer. You must define boundaries explicitly:

1. Use Add Boundary Layer to generate Grid Boxes around your Envelope.
2. Create Slots from those Grid Boxes, pre-loaded with your boundary Module(s).
3. Define Rules connecting boundary Module Faces to interior Module Faces.

This gives you full control: you can use different boundary Modules on different Faces, multiple boundary layers, or no boundary at all.

See also workflows and FAQs: 2.10 Boundary handling, 4.2.3 Add Boundary Layer.

1.8 How do I create an “empty” Module?

Monoceros 3 has no built-in Empty Module. Simply create a Module with no geometry:

1. Use Construct Module with a name like empty and a Grid Box matching your grid cell size.
2. Do not connect any geometry to the Geometry input.
3. Define Rules connecting the empty Module's Faces to other Modules as needed.

You can have multiple empty Modules with different names for different purposes (e.g. empty-interior, empty-boundary).

See also workflows and FAQs: 2.3 Empty Module.

1.9 Why does my Module show red in the viewport?

A red display box and red name label indicate the Module is invalid. Common causes:

• The Module Name contains reserved characters (:, ->, newlines).
• The Module Box is degenerate (zero volume, negative dimensions).

Use Deconstruct Module to inspect the Module's properties and identify the issue. Note: a rotated base plane is not an error - the Module display box rotates with the plane.

See also workflows and FAQs: 2.18 Audit-driven debugging, 1.5 Debugging strategy.

1.10 How do I control how often a Module appears?

Use the Weights input on Construct Slot. Higher Weight means higher probability of being selected during Observation. A Module with Weight 5.0 will appear roughly five times as often as one with Weight 1.0 in an unconstrained scenario. Weights are soft preferences, not guarantees - the Solver still respects Rules, so actual counts depend on the constraint structure. See example 2.8 Weighted Module placement.

1.11 Why does a zero-weight Module still appear in the result?

Zero Weight does not remove a Module from the allowed set during constraint Propagation - Propagation uses Rules, not Weights. A zero-Weight Module remains a valid candidate in any Slot that lists it in ModuleNames. The WFC Solver will never voluntarily choose a zero-Weight Module during Observation, but if constraint Propagation eliminates every other option in a Slot, the Solver must use the zero-Weight Module to avoid a Contradiction.

To reliably prevent a Module from appearing in a zone, remove it from that Slot's ModuleNames list rather than setting its Weight to zero.

See also workflows and FAQs: 2.27 Restricting Modules to specific regions, FAQ tip 2.17 Exclude a Module from a zone.

1.12 How do I get different results each time?

Change the Random Seed input on the WFC Solver. Each Seed produces a Deterministic but different result. Use a Number Slider to browse variations quickly. See example 2.9 Design exploration (seed surfing).

1.13 How do I get reproducible results?

Keep the Random Seed fixed. The same Seed with the same Modules, Rules, Slots, and Solver settings will always produce the identical result, on any computer, on any operating system. If the result changes unexpectedly, something in the setup has changed - check Module Names, Rule lists, Slot Weights, and data tree structures.

See also workflows and FAQs: 2.17 Solver settings, 2.17 Solver settings.

1.14 Why does the same seed give different results after I change something?

The Seed controls the pseudo-random sequence, but any change to the input - adding a Module, modifying a Rule, changing a Weight, resizing the Envelope - changes the sequence of decisions the Solver makes. Even a small change can cascade into a completely different result. This is expected behaviour. If you need to preserve a result while modifying the setup, note both the Seed and the exact input configuration.

See also workflows and FAQs: 1.3 Iterative refinement.

1.15 Why do some Modules never appear in the result?

A Module may be valid but effectively excluded by the constraint structure. Common causes:

• The Module has no Rules on one or more Faces - the Solver cannot place it because neighbouring Slots would have no valid connection.
• The Module's Rules are too restrictive - its required neighbours conflict with the rest of the Rule set.
• Weights are too low relative to other Modules - it is statistically unlikely to be chosen.
• The Module is not listed in the Slot's allowed Module Names - check that all Slots include this Module Name.

Use Audit to identify orphaned Faces, and Occurrence Count to verify the Module appears at all.

See also workflows and FAQs: 2.18 Audit-driven debugging, 2.28 Occurrence Count analysis.

1.16 Can Monoceros work in 2D?

Yes. Set the grid count to 1 in the unused dimension (e.g. Z count = 1 for a floor plan in XY). Design Modules as flat tiles and define Rules for the four in-plane Directions. Connect the two out-of-plane Faces to a boundary Module or to themselves. When Require Terminators is on, the flat Axis is automatically skipped — no Terminators needed for that dimension. See 2.23 2D grids.

1.17 What geometry types are supported?

Modules accept the following Rhino geometry types:

• Point
• Curve (Line, Arc, Circle, Polyline, NurbsCurve, etc.)
• Surface (including Sphere, Cylinder, etc.)
• Brep / Polysurface (including Box, Extrusion, etc.)
• Mesh

Not supported: Block instances, groups, text dots, hatches, annotations. If you need block instances, use the Materialize transforms to create them after solving (see example 2.15).

See also workflows and FAQs: 2.11 Constructing Slots from geometry.

1.18 Can I use curved geometry as Modules?

Yes. Module geometry can be any shape - it is purely decorative and does not affect the solving process. The Solver only considers the Module's Grid Box and Face Rules. Curved geometry can extend beyond the Grid Box, be smaller than the Grid Box, or sit anywhere within it. The only requirement is that Faces on matching Faces produce compatible geometric results when placed side by side.

See also workflows and FAQs: 2.11 Constructing Slots from geometry.

1.19 How do I create L-shaped or T-shaped Modules?

Modules occupy exactly one grid cell. For shapes spanning multiple cells, use a Megamodule - a group of adjacent cells that acts as a single design element. The Construct Megamodule component creates coordinated sub-Modules (named {name}_p0/N, {name}_p1/N, etc.), internal Rules, and external Faces. It also supports auto-rotation (Rotate X/Y/Z) so the Solver can generate rotated variants of the entire Megamodule. See example 2.15 Megamodule construction. Alternatively, design your Module geometry to visually suggest an L or T shape within a single cell (e.g. a partition wall that runs along two Faces of the cell).

1.20 What is the "interior geometry" design principle?

Design Module geometry so that all content stays inside the Grid Box boundary. When two Modules sit side by side, their shared Face must match geometrically - edges meeting at the Face should align. The Solver has no geometry awareness: it cannot detect visual overlaps or gaps between adjacent Modules.

Geometry that protrudes beyond the Grid Box will visually intersect neighbouring Modules without triggering any Solver error. Geometry that stops short of the Face will leave visible gaps. For transitions (e.g. a wall ending at a Face), design the geometry to stop exactly at the Grid Box Face, and ensure the neighbouring Module starts at the same Face with a matching profile.

See also workflows and FAQs: 2.1 Bare minimum.

See also workflows and FAQs: FAQ 1.45 Can Module geometry protrude outside the Grid Box?.

1.21 Are block instances supported?

The Materialize component outputs both geometry and transform data. You can use the transforms to place block instances in Rhino instead of duplicating geometry, which is more memory-efficient for large assemblies. See example 2.15 Custom materialization with transforms.

1.22 Can I use Monoceros with other plug-ins?

Yes. Monoceros is a standard Grasshopper plug-in and its inputs and outputs are standard Grasshopper data types (Points, Breps, Meshes, numbers, strings). You can combine Monoceros with any other plug-in:

• Kangaroo - Apply physics simulation to the materialized result (e.g. relaxation, collision detection).
• Human UI - Build custom control panels to expose WFC parameters (Seed, Weights, Module toggles) as interactive sliders and buttons.
• Karamba3D - Structural analysis of WFC assemblies.
• Pufferfish - Advanced mesh and surface operations on materialized geometry.
• Lunchbox - Additional paneling and pattern tools.
• Elefront - Bake with attributes, layers, and user data.

See also workflows and FAQs: 2.29 Exporting results for fabrication, 1.6 Fabrication-oriented workflow.

1.23 How do I ensure watertight results?

WFC does not guarantee geometric continuity - it guarantees Rule satisfaction. To get watertight results:

• Design Module geometry so that Face boundaries are geometrically continuous when placed side by side. Edges at Faces should align perfectly.
• Use the proto-results workflow to join geometry after solving.
• Use Suggest Rules From Geometry to ensure only Modules with matching edge geometry are paired.

1.24 What is the free-tier run limit?

Monoceros 3 Free includes full functionality on Envelopes of any size. The WFC Solver component is rate-limited to a limited number of runs per fixed time window (windows are aligned to UTC clock boundaries); additional runs require a paid license (Annual, Edu, or Lifetime). Each Solver invocation counts as one run regardless of the Max Attempts setting - the algorithm may retry or backtrack internally, but it is still one run from the license point of view.

The WFC Solver component also has a 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 your run budget. Connect a Boolean Toggle or a Button component.

The component footer on the WFC Solver shows a live counter indicating how many runs remain in the current window and when the window resets. When the cap is hit, the footer turns red and the next available run is announced in the component message.

Separately, the Solver has a hard limit of 16,370 distinct Module Names on every tier. Each rotation variant counts as a separate name. With up to 24 Orientation invariants per Module (from 90° turns around X, Y and Z Axes), the practical limit is roughly 682 unique Module designs if every Module uses all three rotation Axes. The Solver reports an error if this limit is exceeded.

See also workflows and FAQs: 1.4 Multi-scale approach, FAQ tip 2.1 Start small, scale up.

1.25 How do I count the Slots in my Envelope?

Connect the Slot list to a Grasshopper List Length component. The output is the total Slot count, including any boundary Slots you have added. There is no free-tier cap on Envelope size - only the Solver run rate is capped (see 1.24 What is the free-tier run limit?).

See also workflows and FAQs: 2.28 Occurrence Count analysis.

1.26 Why does the solver fail only with larger Envelopes?

A small Envelope is more forgiving because there are fewer Slots to fill and fewer constraint Propagation paths. As the Envelope grows:

• Constraint chains become longer and more likely to create contradictions.
• Random choices early in solving have a larger cascading effect.
• Rule sets that are “almost Contradictory” on a small Envelope become fully Contradictory on a larger one.

Solutions: add more flexibility (more Rules, empty Modules, more Module types), reduce constraint density, increase Max Attempts, or consider a multi-scale approach.

1.27 Why does the solver fail with small Envelopes?

Small Envelopes can fail for different reasons than large ones. The most common: the Module set or boundary conditions force a pattern that requires more space than available. A Module that needs a specific sequence of neighbours may need five or more cells in a row; a 3×3 Envelope cannot accommodate it. Boundary Modules also create additional constraints on every edge Slot, which consumes a disproportionate fraction of a small Envelope.

Solutions: verify that every Module can sit directly adjacent to your boundary Module; check that no Module type implicitly requires a run longer than the shortest dimension of your Envelope; temporarily disable Modules one at a time to isolate which one causes the failure.

See also workflows and FAQs: 1.2 Bottom-up: Modules first, 1.5 Debugging strategy, 2.3 Empty Module.

1.28 How do I guarantee exactly one of a specific Module in the result?

WFC cannot enforce global uniqueness through Rules or Weights alone. Three approaches are available:

1. Pre-fixing - Select the specific Grid Box where the unique element (e.g. control_station) should appear. Use Construct Slot with ModuleNames = [only that module]. Exclude the Module from all other Slots. Deterministic, but the location must be known upfront.
2. Anemone loop - Solve freely, count occurrences with Occurrence Count. If count > 1, remove the Module from all non-preferred Slots and re-solve. Loop via the Anemone GH plugin until count = 1.
3. Two-pass carving - Run the WFC Solver (pass 1) with the Module allowed everywhere. Identify redundant placements. Reset those Slots and several surrounding layers to the full possibility set minus that Module, keeping the rest of the pass 1 result as Deterministic boundary conditions. Run a second Solver on just the carved region. No extra plugins required.

See also workflows and FAQs: 2.12 Fixing Modules in the Envelope, 2.28 Occurrence Count analysis.

1.29 What is All Modules Count and why does it matter?

AllModulesCount is a property of every Slot that records the size of the final Module set. It controls how Entropy is displayed as a normalised percentage in the Grasshopper parameter preview — it does not affect solving.

You never set it by hand. Every Slot leaves Construct Slot with AllModulesCount = 0 — the total is not yet known, so the Slot preview shows only the allowed-Module count (one number in the corner, no / total). Construct Assembly then stamps every Slot it processes with the final total, and the preview switches to the familiar allowed / total form. Every Slot in the Assembly agrees on the same denominator automatically.

Allow-all Slots. If you leave the Allowed Module Names input unconnected, the Slot becomes an allow-all Slot. Construct Assembly fills both the Module list and the count with the final Module set automatically.

See also workflows and FAQs: 2.1 Bare minimum.

1.30 Can I use Module Rotations instead of defining every directional variant?

Yes - and this is the recommended approach. Define one base Module (e.g. path-straight with a path on ±X and void on ±Y) and apply Module Rotations [RotateZ = true, CullDuplicates = true]. The component generates all valid orientations. All variants share the same Module Name, so Rules defined for the base Module apply automatically to all rotations. This avoids manually defining path-straight-x and path-straight-y as separate Modules, and similarly for corners (1 base → 4 rotated corners), T-junctions (1 base → 4 variants), and directional entry Modules (1 base → 4 entry-facing variants).

Note: Module Rotations generates only rotational variants. If you need a mirrored Module, model it separately from scratch. See FAQ 1.49 for why.

See also workflows and FAQs: 2.7 Automatic Module rotations, 4.5.6 Module Rotations, FAQ tip 2.16 Use Module Rotations for isotropic geometry.

1.31 How do I make a Module type go mostly straight instead of winding?

Use a combination of Weight biasing and Rule filtering:

• Give straight Modules a high Weight (e.g. 4.0–5.0) and corner / junction Modules a low Weight (e.g. 0.3–0.5).
• Optionally connect Rules to the Disallowed Rules input of Construct Assembly to remove corner-to-corner adjacency, preventing back-to-back turns.
• Enforce a transition zone: remove any direct straight-Module ↔ void or straight-Module ↔ other-type Rules so a transition Module is mandatory between them.

This creates structured, mostly straight runs rather than winding paths.

See also workflows and FAQs: 2.16 Disallowing Rules, 2.17 Rule Exclusivity, 1.6 Fabrication-oriented workflow.

1.32 How do I design tile Modules for a 2D layout?

Set Z Count = 1. Design one base Module per tile role. Apply Module Rotations [RotateZ = true, CullDuplicates = true] to derive all directional variants - each variant receives a unique counter-based name (tile-0, tile-1, …), so Rules must be defined across the full variant list using the methods in section 1.5. Assign Face roles to each Face and set all ±Z Faces to the boundary role. Use Face grouping ( Construct Rules From Faces with same-role lists as both source and target) to create all valid pairings efficiently. Add a boundary layer and pre-fix any unique elements.

See also workflows and FAQs: 2.23 2D grids (floor layouts and panel systems), 2.7 Automatic Module rotations.

1.33 How do I make tiles of the same type cluster together?

Use two mechanisms together:

• Topological isolation: Design cluster Modules so their horizontal Faces use a dedicated role (e.g. fluid) that connects only to other cluster tiles or edge / transition tiles. This means cluster tiles cannot be directly adjacent to non-cluster tiles.
• Attractor-based Weight gradient: Compute each Slot's distance to a target location, remap to Weights (high near attractor, exactly 0.0 far away), and assign these per-Slot Weights for the cluster Module. Setting Weight to 0.0 - not just low - prevents the Solver from voluntarily choosing the Module in those Slots.

See also workflows and FAQs: 2.9 Weighted Module placement, 2.21 Rules from Face Groups, 2.27 Restricting Modules to specific regions.

1.34 How do I create a mandatory buffer zone between two Module types?

Do not create Rules between type-A Faces and type-B Faces directly. Only create: type-A ↔ type-A, type-A ↔ buffer, and buffer ↔ type-B.

This makes the buffer zone the mandatory intermediate layer: type-A → buffer → type-B. The WFC Solver cannot place a type-A Module directly next to a type-B Module because no Rule exists for that adjacency. Every type-A tile will always be separated from type-B tiles by at least one buffer tile.

See also workflows and FAQs: 2.17 Rule Exclusivity, 2.16 Disallowing Rules.

1.35 Can I use a hexagonal grid?

No. Monoceros only supports rectilinear (Axis-aligned rectangular box) grids. Hexagonal, triangular, diagonal, and polar grids are not supported. Adjacency is always Face-to-Face between rectangular cells - 6 neighbours only.

There is no workable hex workaround for layouts that require Face-to-Face geometric continuity between tiles. The common suggestion - “stagger every other row after baking” - fails for two reasons:

1. Rectangular tiles produce a brick-wall bond, not hexagonal geometry. Shifting rows moves geometry but the tile shapes remain rectangular; seams are still straight horizontal and vertical lines.
2. Staggering breaks physical connections. Modules are designed to connect Face-to-Face at rectilinear grid positions. Shifting a row moves the geometry away from those positions. Any Module set requiring Face-to-Face continuity becomes non-functional after staggering.

Recommendation: abandon the hex grid idea. Design directly for the rectilinear grid. Results can read as organic, directional, and non-uniform through Weight gradients, attractor clustering, and varied Module geometry - without any hexagonal topology.

See also workflows and FAQs: 2.23 2D grids (floor layouts and panel systems).

1.36 What is entropy and how does it affect solving?

Entropy is the number of allowed Modules in a Slot, expressed as a ratio between 0.0 (no Modules, Contradictory) and 1.0 (all Modules allowed). During solving, the WFC algorithm always observes (collapses) the Slot with the lowest Entropy first - the Slot with the fewest options. This heuristic reduces the chance of Contradiction by making the most constrained decisions first.

In practice, Entropy affects the visual character of results: Slots near already- solved regions tend to have lower Entropy and get solved next, producing a “growing” pattern outward from the first Observation.

See also workflows and FAQs: 2.17 Solver settings, 2.17 Solver settings.

1.37 How does randomness affect solving? Is the result entirely random?

Monoceros is Deterministic for a given Seed and input configuration. The “random” part is only the tie-breaking during Observation: when multiple Slots have the same (lowest) Entropy, the Solver uses the Seed to choose which one to collapse first. All constraint Propagation after that choice is fully Deterministic.

Results are more structured than truly random arrangements - the Solver always makes the most constrained decision first and only uses randomness to break ties. Changing any input (Module list, Rule set, Slot Weights, Envelope size) changes the tie-breaking sequence and can produce a completely different result even with the same Seed.

See also workflows and FAQs: 2.17 Solver settings, 2.17 Solver settings.

1.38 Why does a contradiction appear in a Slot far from where I made changes?

WFC uses constraint Propagation: each time a Module is placed in a Slot, the Solver removes incompatible Modules from all neighbouring Slots, then propagates outward through the Rule graph. A change near Slot A can cascade through a chain of Propagation steps and create a Contradiction in a distant Slot Z.

This is expected WFC behaviour. To debug: use the Audit Assembly component to identify which Slot contradicts, then trace backward - examine which Rule connections reach that Slot and which recent placement could have triggered the chain. Adding a void Module with general Rules usually breaks the Propagation chain.

See also workflows and FAQs: 2.18 Audit-driven debugging, 1.5 Debugging strategy.

1.39 Are weights a property of a Module or of a Slot?

Weights are a property of a Slot, not of a Module. The same Module can have Weight 5.0 in one Slot and Weight 0.0 in another. A Module has no Weight property of its own - the Weight is always specified on the Construct Slot component, as a value paired with the Module Name for that specific Slot.

This is what makes attractor-based gradients work: you compute a spatial value (distance to a point, Z height, noise) for each Slot's centre, remap it to a Weight range, and supply those per-Slot values as the Weights input. The result is a Module that appears frequently near the attractor and rarely or never away from it - all from a single Module definition.

See also workflows and FAQs: 2.9 Weighted Module placement, 2.27 Restricting Modules to specific regions, FAQ tip 2.5 Attractor-based weight gradients.

1.40 What is the “coast principle” for Module design?

The most generative Modules are those that contain transitions rather than uniform content. The analogy: a coastline tile containing part land and part sea generates richer adjacency possibilities than a purely-land or purely-sea tile. Applied to design: a Module that is half one content type and half another generates richer adjacency possibilities than a Module that is entirely one type. Design your Modules to live at the boundary between adjacent content types rather than fully representing only one.

See also workflows and FAQs: 1.2 Bottom-up: Modules first, 2.5 Defining Rules from Faces.

1.41 Why do Slot Grid Boxes in the viewport look smaller than the actual cell size?

This is intentional. Adjacent Slots share Faces: if every Slot Grid Box were drawn at full cell size, the shared edges of neighbouring Slots would overlap exactly in the viewport, making it impossible to visually distinguish individual cells. Monoceros shrinks each display box inward by a small fraction so there is always a visible gap between neighbours, regardless of how large or densely packed the Envelope is.

The display box is a display-only artifact. The solving geometry, Rule matching, and Face placement all use the true, full-size cell box. Baked geometry fills the full box.

See also workflows and FAQs: 2.1 Bare minimum.

1.42 Why does the result always look the same regardless of the seed?

Changing the Seed changes which Slot the Solver observes first and how it breaks ties, but it cannot create variety that the Rule set does not allow. If every Face that is covered by explicit Rules appears in exactly one Rule, then each Face of each Module has only one valid neighbour. Once the first Module is placed, the entire grid is forced to follow a single valid chain - the Solver has no choices to make, and the result is structurally identical every time. Changing the Seed shifts the starting point but the same pattern tiles out in all Directions.

For variety to occur, at least some Faces must participate in more than one Rule. When a Face has two or more valid neighbours, the Solver has a genuine choice at that Face; different Seeds resolve those choices differently and produce different results. The more Faces have multiple valid partners, the richer and more varied the output space.

The Audit Assembly component reports which Faces are referenced in only a single Rule (the Singly Constrained Faces output) and which are effectively Indifferent even though explicit Rules exist for them. If all Rule-covered Faces are singly constrained, Seed variation will produce no structural variety.

See also workflows and FAQs: 1.5 Debugging strategy, 2.17 Solver settings, 2.17 Rule Exclusivity, FAQ tip 2.15 Compare results with Changed Slots.

1.43 Why do the Solver and Materialize Assembly warn about Module dimension mismatches?

The WFC Solver assigns Modules to Slots by name only - it has no knowledge of box dimensions. A Module is removed from a Slot's candidate list by constraint Propagation (Rules), not by geometry checks. This means the Solver can successfully complete a solve where a Slot is assigned a Module whose box dimensions do not match the Slot's dimensions.

When Materialize Assembly later tries to place the geometry, it compares the Module's box dimensions to the Slot's dimensions. If they differ, placement is skipped and the Slot remains empty in the geometry output - with no indication of which Slots were affected other than the Module count in the warning.

To surface this earlier, the Solver now emits a Warning before the solve runs if any Slot allows a Module Name that exists in the Module list but has no variant with dimensions matching the Slot. The warning lists the mismatched Module Names. Materialize Assembly also now emits a Warning (previously only a Remark) when it skips geometry placement due to a dimension mismatch. Use the Audit Assembly component's Slots Without Fitting Modules output to identify every affected Slot precisely before the solve.

See also workflows and FAQs: 2.8 Heterogeneous grid, 2.25 Rectangular (non-square) Modules.

1.44 Is there a good or bad random seed?

No. All Seeds are equivalent from the Solver's perspective. Whether a given Seed finds a solution depends entirely on the Rule set, Envelope, and Weights - not on the Seed value itself. A Seed that fails with one setup may solve with another; a Seed that solves is not lucky, it simply encountered constraints in an order that avoided a dead end. Changing the Seed is just another way of exploring the same solution space from a different starting point.

The only thing that makes a Seed “special” is that once a successful Seed is known, pinning it to the input guarantees the same result every time - because the Solver is fully Deterministic for a given Seed and setup. See also 1.13 Why does the same seed give different results after I change something?

1.45 Can Module geometry protrude outside the Grid Box?

Yes, and Monoceros fully supports this. Module geometry is never clipped or constrained to the Grid Box boundary - it can extend freely in any Direction. The Solver only uses the Grid Box and Faces to determine adjacency; the geometry itself plays no role in solving.

Two intentional uses of protruding geometry:

• Physical Faces - bolts, screws, tabs, or latching hooks that physically join adjacent Modules can be modelled as geometry protruding into the neighbouring cell. Design the matching receiving feature (hole, socket, recess) into the neighbouring Module’s geometry. The Solver will not detect or flag the protrusion - only the Rules determine what may be placed next to what.
• Artistic overreach - fins, overhangs, tendrils, or any decorative element that intentionally crosses a cell boundary. Results can appear seamlessly continuous across multiple cells even though each Module is geometrically independent.

Monoceros has no geometry awareness: it cannot detect or warn about clashes between protruding geometry and the content of neighbouring Modules. Verifying that protrusions fit correctly together is a design responsibility.

See also workflows and FAQs: FAQ 1.20 What is the “interior geometry” design principle?, 1.6 Fabrication-oriented workflow.

1.46 Can I use an AI assistant (ChatGPT, Claude, etc.) to help me with Monoceros?

Yes. Monoceros provides official machine-readable documentation files specifically designed for AI assistants. You can feed these files to any LLM - ChatGPT, Claude, Gemini, Copilot, or any other - to get accurate, context-aware help with your Monoceros projects.

Two files are available:

• llms.txt - a concise summary of key concepts, workflow steps, all component names, and the 10 most common issues. Good for quick questions.
• llms-full.txt - the complete documentation in a single text file: all data types, every component with inputs/outputs, 7 strategies, 30 example walkthroughs, all 47 FAQ answers, and tips. Use this for in-depth help or debugging.

To use them: paste the contents into your AI chat, upload the file as an attachment, or give the AI the URL directly. Then ask your question as you normally would. For detailed step-by-step instructions, see the AI-assisted help page.

1.47 How many Modules can the solver handle?

The Solver supports a maximum of 16,370 distinct Module Names. Every rotation variant counts as a separate Module Name toward this limit. The Module Rotations component can generate up to 24 orientations per Module (90° turns around the X, Y, and Z Axes). This means the practical limit is roughly 682 unique Module designs if every Module uses all three rotation Axes, or significantly more if your Modules only rotate around one or two Axes.

The Solver automatically selects a compact internal representation based on the actual Module count. Problems with fewer Modules use less memory and run faster - there is no penalty for the higher limit.

1.48 Common Module design mistakes

These are the mistakes that come up most often when people start working with Monoceros. Each one stems from a reasonable intuition. WFC and Monoceros, however, often happen to be counterintuitive.

Making one room = one Module

Architects and designers think in terms of assembling whole semantic objects: one Module for a bedroom, one for a bathroom, one for a corridor. This is the most counterintuitive aspect of working with Monoceros. A room is not a Module - a Module contains a part of a room, together with parts of whatever is next to it. A 3-meter room built from 1.5-meter Modules consists of a corner Module, a straight-wall Module, and another corner Module. The room only exists as an emergent result of the Solver connecting these parts.

If you make an entire room a single Module, the Solver has nothing to combine - it just places pre-made rooms side by side, losing the combinatorial variety that WFC is designed to produce.

Expecting empty space to appear automatically

The WFC Solver fills every Slot in the Envelope. It does not leave cells empty or skip areas where no Module fits well. If you want empty space in the result, you must include an explicit empty Module - a Module with no geometry, just a name and a Grid Box - and define Rules for it. Without an empty Module, the Solver is forced to place visible geometry everywhere, which usually leads to either contradictions or visually cluttered results.

Confusing Monoceros with growth algorithms

There are several amazing tools in the Grasshopper ecosystem that add pieces one by one to a growing aggregate, expanding outward from a Seed. Monoceros works differently: it fills a pre-defined Envelope all at once using WFC. The Envelope is fixed before solving starts, and every Slot gets a Module assignment. Different tools, different paradigms, different outputs.

Growth-like behavior can be simulated with Monoceros (e.g. progressive solving on expanding partial Envelopes, or using masks to reveal regions incrementally), but the underlying mechanism is always constraint Propagation over a fixed grid, not incremental aggregation.

See also workflows and FAQs: 1.5 What makes a good Module?, 1.8 How do I create an "empty" Module?, 1.2 Does the solver always fill every cell in the Envelope?.

1.49 What are the Monoceros license tiers?

Monoceros 3 has four tiers. Free includes full functionality on Envelopes of any size, with the WFC Solver rate-limited per fixed time window and no purchase required. Annual is a yearly subscription that unlocks unlimited Solver runs. Edu is a discounted annual license for students and educators. Lifetime is a one-time purchase that unlocks unlimited Solver runs permanently.

All tiers use the same plugin. The tier is determined by your Gumroad purchase - enter the email you used on Gumroad in the License dialog and the plugin validates it automatically. Annual and Edu licenses are cached for 7 days - a period during which it works also offline. Lifetime licenses are cached for 1 year. After that they need to go online to renew automatically. The plugin may optionally ask you to register with your email - this is for product updates only and can be skipped.

See also workflows and FAQs: 1.24 What is the free-tier run limit?.

1.50 What happens when my subscription ends?

If your Annual or Edu subscription ends (cancelled, expired, or not renewed), the plugin automatically falls back to Free mode (WFC Solver runs rate-limited per fixed time window). Your definitions and settings are preserved - only the run-rate cap is re-applied.

Lifetime licenses never expire. They are a one-time purchase that unlocks unlimited Solver runs permanently.

See also workflows and FAQs: 1.49 What are the Monoceros license tiers?.

1.51 Why does Monoceros ask me to register?

Monoceros 3 may show an optional registration dialog inviting you to enter your email for product updates and news. Registration is not required to use the Free tier - you can dismiss the dialog and continue working. If you choose to register, claim the free Monoceros product on Gumroad and enter the same email in the plugin. We do not share your email with third parties.

See also workflows and FAQs: 1.49 What are the Monoceros license tiers?, 1.24 What is the free-tier run limit?.

1.49 Why is there no automatic mirror option on the Module?

Rotations and mirrors are fundamentally different. If a Module represents a real-world object, every rotation of that object is still the same object - a chair rotated 90° is still the same chair. All 24 rotational variants are guaranteed to be valid representations of the original design.

Mirroring does not have this property. A mirrored version of an object is not always the same object. A left shoe is not a right shoe. A staircase that spirals clockwise becomes one that spirals counter-clockwise. Text becomes unreadable. A door with hinges on the left becomes a door with hinges on the right. Automatically generating mirrored variants would silently introduce Modules that may not represent valid real-world objects, leading to results that look plausible at first glance but are physically wrong.

For this reason, Monoceros does not offer automatic mirroring. If your design genuinely needs a mirrored variant (e.g. a left-hand and right-hand corner), model it separately from scratch as its own Module and define its Rules independently. This forces an explicit design decision for each mirrored variant, ensuring every Module in the system is intentional.

See also workflows and FAQs: 1.30 Can I use Module Rotations instead of defining every directional variant?, 2.16 Use Module Rotations for isotropic geometry, 4.5.6 Module Rotations.

1.52 What are Connectors and how do they differ from Rules?

A Rule is an explicit permission for two specific Module Faces to be adjacent. A Connector is a higher-level abstraction that combines interface identity (name + symmetry) with placement (Module + Face + rotation) in a single object. Think of a Connector like a USB socket on a device - it has a specific type and Orientation, and only mates with a compatible counterpart. All Connectors sharing the same name are the same type.

Each Connector carries four symmetry flags (0°, 90°, 180°, 270°) that declare which rotations are considered identical. You declare which Connector names can connect via Connector Pairs. Monoceros then generates the corresponding Rules automatically. This is especially powerful when Modules have many rotation variants - the Connector system handles all rotational bookkeeping for you. There is no separate type-definition step: every Connector already carries its type identity and its placement.

See also workflows and FAQs: 2.4 Using Connectors for rotation-aware rule generation, 1.54 How does Connector rotation compatibility work?.

1.53 How does the Assembly workflow work?

Construct Assembly takes Modules, Slots, explicit Rules, Connectors, and Connector Pairs. It expands rotation variants, generates Connector-based Rules, applies indifference, merges all Rule sources, deduplicates, audits, and packages everything into a single Discrete Assembly.

The WFC Solver takes this Assembly as its sole data input. After solving, use Materialize Assembly to extract placed geometry, or Deconstruct Assembly to access the Modules, Slots, and Rules. Use Audit Assembly on the input Assembly to diagnose setup errors before solving, and on the output Assembly to inspect the solution.

See also workflows and FAQs: The Assembly workflow, 1.52 What are Connectors and how do they differ from Rules?.

1.54 How does Connector rotation compatibility work?

Each Connector has four symmetry flags corresponding to 0°, 90°, 180°, and 270° rotations around the Face normal. When a flag is true, the Connector at that rotation is considered identical to the Connector at 0°.

A round pipe end that looks the same from every angle has all four flags set to true. A door frame that can be placed upright or upside-down but not sideways has only the 0° and 180° flags set. An interface with no rotational symmetry at all has only the 0° flag set.

When two adjacent Module Faces carry compatible Connector names, the Solver checks whether the relative rotation between them is covered by the symmetry flags. If the rotation is not marked as symmetric, the pairing is not allowed.

See also workflows and FAQs: 2.4 Using Connectors for rotation-aware rule generation, 1.52 What are Connectors and how do they differ from Rules?.

1.55 Can I mix Connectors with explicit Rules?

Yes. Construct Assembly accepts both explicit Rules and Connector-based inputs (Connectors + Connector Pairs). It merges Connector-generated Rules with explicit Rules into a single set. Duplicates are harmless - the Solver ignores them.

Use Connectors for the bulk of adjacency logic and add explicit Rules for special cases that Connectors cannot express - for example, a one-off connection between two specific Module Faces that does not fit any Connector name. Connect any unwanted Rules to the Disallowed Rules input of Construct Assembly, or connect unwanted Connector Pairs to the Disallowed Connector Pairs input.

See also workflows and FAQs: 2.5 Combining Connectors with explicit Rules, 1.52 What are Connectors and how do they differ from Rules?.

1.56 Why does Construct Assembly generate so many indifference rules?

Indifference Rule count grows quadratically with the number of Modules that have Unused Faces. For M Modules with Unused Faces, indifference generates up to 3 × M² Rules - M positive × M negative Faces on each of 3 Axes.

With rotation variants enabled, M can be up to 24× the number of original Modules (one variant per cube rotation). The growth is dramatic:

These numbers assume fully asymmetric cubic Modules where all 24 rotations produce geometrically distinct variants and every Face is unused (no explicit Rules or Connectors). In practice the count is often lower because:

• Non-cubic Modules produce fewer fitting variants (some rotations change dimensions and are filtered out by Slot size).
• Every Face covered by an explicit Rule or Connector is excluded from the Indifferent set, which reduces M in the formula.
• Terminator-to-boundary Rules (generated when Require Terminators is on) do not count as covering a Face - a Module Face that only has terminator coverage still receives indifference Rules and is included in M.

How to reduce Rule explosion: add explicit Rules or Connectors to cover more Faces. Even one Connector per Module Face can dramatically reduce the Indifferent set. Construct Assembly warns when indifference generates more than 10,000 Rules.

See also workflows and FAQs: 1.47 How many Modules can the solver handle?, 2.8 Defining Rules from Faces.

1.57 Can I create a Slot that allows all Modules?

Yes. Leave the Allowed Module Names input on Construct Slot unconnected. The Slot is then created in an “allow all” state with an empty Module list and a Total Modules Count of zero, and the component emits a Remark confirming it.

When Construct Assembly runs, it replaces the empty list with the full deduplicated final Module set (including rotation variants that fit the Slot dimensions), assigns uniform Weights of 1.0 to each Module, and sets the Total Modules Count accordingly. This is the shortest path for the common case where every Envelope cell accepts every Module - no List Length, no wiring between Module Names and Slots.

Allow-all Slots preview as white cages with the label All, and Deconstruct Slot reports Entropy of 1.0 for them. Weights connected alongside an empty Allowed Module Names input are ignored - the Assembly decides the final values.

1.58 How do I create a Connector by clicking on a Module face?

Use the Connector From Point component. Wire your Modules and a Point3d marking a location on a Module Face; the component returns one Connector per matching Face using the provided Name, Rotation and Symmetry flags. It is a shortcut for Faces from Point → Connector from Face, sharing the same matching logic as Faces From Point and the same validation as Connector From Face - one component instead of two.

If the Point matches no Face, Connector From Point emits a Warning and produces no Connectors. If the Point matches several Faces (for example, where Modules overlap), a Remark reports the count and one Connector per match is produced.

1.59 What is a Terminator and when should I use it?

A Terminator is a boundary-facing marker placed on a specific Module Face. It declares that the marked Face is allowed to sit against the outer boundary of the Envelope when Require Terminators is enabled on Construct Assembly.

Use Terminators when you want explicit, per-Face control over which Module Faces may appear at the Envelope edge — rather than letting any Face land there. When Require Terminators is on, Construct Assembly synthesizes a one-cell-thick boundary layer around the Envelope and generates adjacency Rules linking each Terminator-marked Face to it. Any Module Face without a Terminator is forbidden from touching the boundary layer; if the Solver is forced to place such a Face against the outer edge, the Assembly will contradict.

Terminators carry no name, rotation, or symmetry — they declare only that a given Module Face is boundary-compatible. Create them with Construct Terminator (from a Face or Module) or Terminator from Point (from a viewport click).

See also: 4.1.5 Construct Terminator, 4.1.6 Terminator from Point, 4.4.1 Construct Assembly.

1.60 What happens when Require Terminators is on but some face directions have no Terminator?

Construct Assembly will still build and emit an Assembly, but the Audit Assembly component will list the uncovered Directions in the Terminator Faces Missing output and flag them as a Warning.

During solving, any Slot on the Envelope boundary whose only remaining Module candidate has a Face pointing outward with no Terminator will hit a Contradiction. To prevent this, supply at least one Terminator for every Face Direction (±X, ±Y, ±Z) — six Directions total. The quickest way is to wire a single Module that Faces all six Directions directly into Construct Terminator, which expands it to all six Faces at once.

Exception — flat Axes: when the grid has extent = 1 in one or more dimensions (e.g. a 10×10×1 grid), those Axes have no neighbours. Construct Assembly automatically skips boundary wrapping, terminator Rules, and self-adjacency on flat Axes, so you do not need to supply Terminators for the collapsed dimension. Only the in-plane Axes require Terminator coverage.

Check the Terminator Faces Covered and Terminator Faces Missing outputs on Audit Assembly to verify coverage before solving.

See also: 4.4.4 Audit Assembly, 4.1.5 Construct Terminator.

1.61 How does Require Terminators differ from manually adding boundary Slots?

Both approaches enforce that specific Module Faces appear at the Envelope boundary, but they work at different levels of control.

Manual boundary Slots (using Add Boundary Layer, creating an “Out” Module, and defining Rules to interior Modules) gives you full authoring control: you design what the boundary layer contains, what geometry it carries, and which Rules connect it to your interior Modules.

Require Terminators is a shortcut: Construct Assembly synthesizes the boundary layer automatically from your Terminator declarations. The synthesized boundary Module carries no geometry and is invisible in the viewport and in Materialize Assembly output.

Use Require Terminators when you simply want boundary enforcement without designing explicit boundary Module types. Use manual boundary Slots when you need specific geometry or custom Rule logic at the Envelope edge.

See also: 4.4.1 Construct Assembly, 1.7 How do I handle boundaries?.

1.62 How do I create Terminators for all faces of a Module at once?

Wire the Module directly into the Face or Module input of Construct Terminator. When a Module is wired instead of individual Faces, the component expands it into all six of its Faces and produces one Terminator per Face. A Remark reports how many Terminators were produced from the expansion.

This is the fastest way to mark an entire Module as fully boundary-compatible on all six sides. You can also use Terminator from Point and place six point tags — one on each Face — or extract individual Faces with Get Module Faces and wire each one into Construct Terminator separately.

See also: 4.1.5 Construct Terminator, 4.1.6 Terminator from Point.

1.63 What does “Some modules lack adjacency rules on non-flat axes” mean?

Before calling the native Solver, the WFC Solver component checks that every Module appears as both a “low” (negative-Direction) and “high” (positive-Direction) neighbour in at least one adjacency Rule on every non-flat Axis. A Module that is missing from one side of the Rules on an Axis can never be placed next to anything in that Direction, which guarantees a Contradiction.

The error message lists the specific Modules and the Axis/Direction where coverage is missing (up to 10 entries). Common causes:

• A Module was added to the library but no Rules were defined for one or more of its Face Directions.
• Require Terminators is on and the grid is flat in one dimension, but the Rules were authored assuming a 3D grid. Because flat Axes (extent = 1) are automatically skipped, Rules on those Axes are inert — but Rules on the remaining non-flat Axes must still provide full coverage.
• Module Rotations generated rotation variants but the Rule set only covers the original Orientation.

To fix the error, ensure every Module has at least one Rule connecting it on each non-flat Axis in both Directions. The Audit Assembly component’s Report output lists orphaned Faces, which often overlap with the gaps reported here.

See also: 4.4.3 WFC Solver, 4.4.4 Audit Assembly, 1.60 What happens when Require Terminators is on but some face directions have no Terminator?.

2. Tips & Tricks

2.1 Start small, scale up

Always prototype on a small Envelope (3×3×3 or 5×5×5) first. Verify that Modules, Rules, and boundary handling work correctly before scaling to production-size Envelopes. Debugging a 20×20×20 Envelope (8,000 Slots) is orders of magnitude harder than debugging a 3×3×3 Envelope (27 Slots).

See also workflows and FAQs: 2.1 Bare minimum, 1.5 Debugging strategy.

2.2 Always run Audit before Solve

The Audit Assembly component catches most setup errors instantly: orphaned Faces, invalid Modules, dimension mismatches, unknown Module Names in Slots. Running Audit Assembly first saves you from chasing down mysterious Solver failures. Wire Audit Assembly in parallel with the WFC Solver and check its Report output before investigating Solver results.

See also workflows and FAQs: 2.18 Audit-driven debugging, 1.5 Debugging strategy, 4.4.4 Audit Assembly component.

2.3 Name Modules descriptively

Use names like frame-corner, panel-solid, void-interior instead of m1, m2, m3. Descriptive names make Rules readable, Audit reports understandable, and occurrence counts meaningful. Remember that names auto-convert to lowercase.

See also workflows and FAQs: 2.6 Working with multiple Modules.

2.4 Use multiple void Module types

Instead of a single empty Module, create purpose-specific void types: void-interior (for empty space inside the design), void-boundary (for the outer shell), void-clearance (for access clearance zones within the design). Each can have different Rules, giving you finer control over where empty space appears. More void types also give the Solver more flexibility, reducing Contradiction frequency.

See also workflows and FAQs: 2.3 Empty Module.

2.5 Use attractor-based weight gradients

Instead of uniform Weights, compute Weights per Slot based on spatial criteria:

• Distance from a point - Use Grasshopper's Distance component and remap the result to a Weight range.
• Distance from a curve - Use Curve Closest Point to create a gradient along a path.
• Z height - Use the Z coordinate of each Slot's centre point to create a vertical gradient.
• Noise - Add Perlin noise or random jitter to Weights for organic variation.

Remap the gradient to a reasonable Weight range (e.g. 0.1 to 5.0). Extremely high Weights can force contradictions. To completely exclude a Module from a Slot, remove it from that Slot's ModuleNames list - a zero Weight still allows the Solver to use the Module if no other option remains during Propagation.

See also workflows and FAQs: 2.9 Weighted Module placement, 2.27 Restricting Modules to specific regions.

2.6 Use Cross Reference for bulk Rule creation

When you want every Module to connect to every other Module on matching Faces, use Grasshopper's Cross Reference component to generate all Module Name pairs. Feed these into RuleFromModules to create Rules for every combination in one step, rather than wiring individual Faces.

See also workflows and FAQs: 2.5 Defining Rules from Faces, 4.6.2 Construct Rules from Modules.

2.7 Test Rules visually before solving

Before running the Solver, use Preview Rule and Preview Rule to inspect your Rules visually. Preview every Rule as a pair of positioned Modules - this immediately reveals Orientation errors, wrong Face assignments, and missing pairings that would otherwise cause mysterious Solver failures.

See also workflows and FAQs: 2.19 Visualizing Rules and Faces, 4.6.8 Preview Rule.

2.8 Bake as block instances for smaller files

The Materialize component creates block instances when baked - each unique Module becomes a block definition and placements are lightweight references. This produces dramatically smaller .3dm files compared to baking individual geometry copies. For an Envelope with 1,000 Slots and 5 Module types, you get 5 block definitions instead of 1,000 geometry copies.

See also workflows and FAQs: 2.16 Materializing results, 2.29 Exporting results for fabrication.

2.9 Use Data Recorder to save multiple results

Connect the Materialize Geometry output to a Data Recorder component. Step through different Seeds, and the Data Recorder captures each result. You can then browse all recorded results without re-solving, making Seed surfing much faster.

See also workflows and FAQs: 2.17 Solver settings.

2.10 Use Add Boundary Layer for irregular Envelopes

When constructing irregular Envelopes (L-shapes, courtyards, organic shapes), use Add Boundary Layer to ensure proper adjacency around irregular Envelope edges. The component adds a layer of boundary Slots around the Envelope, guaranteeing that every edge cell has correct Face-to-Face adjacency with the boundary. Run it after constructing your Envelope to prevent Solver failures caused by missing or ambiguous neighbors.

See also workflows and FAQs: 2.11 Constructing Slots from geometry, 2.24 Sparse grids with intentional gaps, 4.2.3 Add Boundary Layer.

2.11 Understand the Materialize output tree

The Materialize output is a data tree with branch paths {module index, slot index}. To work with specific Module types after materialization:

• Use Tree Branch to extract all placements of a specific Module (by its index in the input Module list).
• Use Flatten to get all geometry in a single list.
• Use Graft if you need per-Slot isolation.

See also workflows and FAQs: 2.16 Materializing results.

2.12 Disable the Solver while editing

The WFC Solver recomputes every time its inputs change. While editing Modules, Rules, or the Envelope, right-click the Solver component and select Disable (or use Grasshopper's Lock Solver) to prevent unnecessary recomputation. Re-enable when you are ready to see results.

See also workflows and FAQs: 1.3 Iterative refinement.

2.13 Proto-results save computation time

If your final Module geometry is complex (dense meshes, heavy Breps), use lightweight placeholder geometry (simple boxes or wireframes) during design iteration. Replace with the final geometry only for the last Materialize step. This dramatically speeds up the preview cycle.

See also workflows and FAQs: 2.22 Proto-results workflow.

2.14 Use Sample Geometry to verify Module content

The Sample Geometry component lets you check what geometry intersects a specific Grid Box. Use it to verify that your geometry lands in the correct cells, especially when Module geometry extends across cell boundaries or when using complex imported geometry.

See also workflows and FAQs: 2.11 Constructing Slots from geometry, 2.1 Bare minimum, 4.4.6 Sample Geometry.

2.15 Compare results with Changed Slots

The Changed Slots component compares two solved Envelopes and identifies which Slots changed. Use it to understand the effect of Rule modifications, Weight changes, or Seed differences. This is especially useful during iterative refinement - you can see exactly which parts of the result were affected by your last change.

See also workflows and FAQs: 2.17 Solver settings, 4.7.3 Changed Slots.

2.16 Use Module Rotations for isotropic geometry

Define one base Module for each tile type, then apply Module Rotations [RotateZ = true, CullDuplicates = true]. All variants share the Module Name, so a single Rule set covers all orientations. This is significantly less error-prone than manually defining directional variants as separate Modules and ensuring their Face Directions are correct.

Note: Module Rotations generates only rotational variants. If your design requires a mirrored Module (e.g. a left-hand and right-hand corner), model the mirrored version separately from scratch and define its Rules independently. See FAQ 1.49 for why automatic mirroring is not supported.

See also workflows and FAQs: 2.7 Automatic Module rotations, 4.5.6 Module Rotations.

2.17 To exclude a Module from a zone, remove it from allowed names

The reliable way to prevent a Module from appearing in a Slot is to remove it from that Slot's ModuleNames list when constructing the Slot. A zero Weight reduces selection probability to zero during Observation but the Module can still be placed if constraint Propagation leaves it as the only valid option. Removing it from ModuleNames guarantees complete exclusion - the Solver cannot place it there under any circumstances.

See also workflows and FAQs: 2.27 Restricting Modules to specific regions, 2.12 Fixing Modules in the Envelope.

2.18 Plan Face roles before modelling geometry

Write a table: for each Module, list what role each Face Index plays (e.g. path, transition, void, boundary). Roles are a design-planning convention - there is no type or role field on the FaceId itself. You implement them by extracting the right index outputs from Get Module Faces and organising them into named lists on the canvas. Verify that every role appears as both source and target somewhere in the system - a role that is always a source but never a target (or vice versa) will cause contradictions. Do this planning before any geometry work - it is much easier to fix a role table than to re-model Modules.

See also workflows and FAQs: 2.5 Defining Rules from Faces, 1.2 Bottom-up: Modules first.

2.19 Let Construct Assembly stamp AllModulesCount

Construct Slot no longer takes an All Modules Count input. Every Slot is created with AllModulesCount = 0 and Construct Assembly stamps every Slot it processes with the size of the final Module set — so every Slot in the Assembly agrees on the same denominator automatically. No List Length wiring or cross-component synchronisation is needed.

The Slot preview reflects the two phases: pre-Assembly it shows only the allowed count (one number in the corner, no / total); post-Assembly it shows the familiar allowed / total form.

See also workflows and FAQs: 2.1 Bare minimum.

2.20 How to allow all indifferent Faces on the boundary

When using Require Terminators on Construct Assembly, every Module Face that may sit against the Envelope boundary must have a Terminator. If your setup has many Modules with Faces that carry no explicit Rules or Connectors (Indifferent Faces), marking each one by hand is tedious and error-prone.

The Used Faces component automates this. Wire your Modules, Rules and Connectors into it — the Unused Faces output gives you exactly the Faces that have no Rule or Connector coverage. Feed that output directly into Construct Terminator and the resulting Terminators into Construct Assembly. Every Indifferent Face is now marked as boundary-safe, so Require Terminators will not reject them.

Step by step

1. Place a Used Faces component.
2. Wire your Modules into the M input.
3. Wire your Rules into the R input (and Connectors into C if you use the Connector workflow).
4. Connect the Unused Faces (UF) output to a Construct Terminator component.
5. Merge these Terminators with any Terminators you already have.
6. Wire the merged Terminators into Construct Assembly’s Terminators input with Require Terminators enabled.

This pattern is safe because Indifferent Faces already connect to every opposing Indifferent Face — marking them as Terminators simply declares that they may also sit against the boundary, which is the expected behaviour.

See also workflows and FAQs: 2.35 Marking unused Faces as Terminators, 4.3.5 Used Faces.

Vocabulary

All terms used in Monoceros 3 documentation and component tooltips, listed alphabetically.