Skip to main content
Build a panelling script that distributes geometry across the surface of a complex mesh, with curvature-aware flow and consistent overlap. This is a demanding task with multiple interacting constraints, and a good showcase for what flagship coding models can do. Time: 15 minutes (advanced) You’ll need: Complete Generate Rhino scripts with AI first. A target mesh in Rhino plus a small mesh box (the unit panel) on a separate layer.
For the deeper physics-based refinement pattern that follows, see this 12 minute walkthrough.

​
What you’re building

Given:
  • A target mesh to clad
  • A small mesh box (the shingle unit)
  • An overlap percentage
The script should:
  1. Generate streamlines across the target mesh that respond to curvature
  2. Space streamlines so shingles in adjacent rows don’t overlap too much or leave gaps
  3. Place shingle geometry along each streamline with consistent overlap

​
Why this is hard

Two constraints fight each other:
  • Flow logic wants lines to follow curvature, lines bunch and spread naturally
  • Panel logic wants uniform distribution, evenly spaced, consistent overlap
Fix one and you break the other. The solution flagship models tend to land on is to grow streamlines incrementally, place one, check it, offset the next from it, rather than generating them all in parallel.

​
1. Set up

Have the target mesh on the canvas plus a small mesh box separately. The script will read the box’s dimensions rather than hard-coding panel sizes. Drop a Code node, set output to Rhino Python, select it, and switch the chat model to Claude Opus.

​
2. Prompt with the “ask questions first” pattern

The “ask questions if you need clarification” line is one of the most useful tricks in this workflow. Opus will come back with things like “rectangular shingle with length, width, thickness?” and “overlap along streamline direction, lateral overlap between streamlines, or both?”, exactly the ambiguities you need to pin down before it writes 700 lines of code.
For this kind of constraint-heavy generative work, expect the script to land at around 1,000 lines. A complete rewrite costs around 500-900 credits (~50 cents). Cheaper models will struggle.

​
3. Run with conservative parameters first

Don’t expect the first run to be perfect. The natural loop:
  1. Run with conservative parameters (small overlap %, small streamline count)
  2. Screenshot the result and paste it back into chat
  3. Describe what’s wrong, e.g. “overlap along the curves is good, but between the curves we aren’t computing properly”
  4. Let Opus diagnose and rewrite

​
4. Split complex scripts into explicit steps

Once the script grows, ask Opus to split it:
Huge quality-of-life improvement. You can validate the streamline layout before committing to generating thousands of shingle meshes.

​
5. Add real-world placement constraints

The base script gets you decent distribution. To push it toward how you’d actually shingle a roof, layer in:

​
Bottom-up placement

Opus will rewrite ~800 lines. You should see more consistent direction between shingles than the base script, though the top of the mesh will still be problematic.

​
Multiple panel types and post-placement relaxation

Screenshot the result and describe what’s wrong:
Model two extra mesh boxes (one longer, one shorter) so you have three panel types. Opus will rewrite (~1,400 lines) with post-placement relaxation and per-panel-type selection.
Opus’s own description of the approach it picks (post-placement relaxation, curvature-based panel selection) is often more sophisticated than what you’d prompt for directly. Read what the model says it’s doing before running. It’s how you learn what’s actually feasible.

​
Smoothing and curvature-matched panel types

At this point Opus is doing selective edits rather than full rewrites, which keeps cost down.

​
6. Use logs as feedback

When relaxation isn’t converging, the script’s own console output becomes useful feedback. Pass Opus:
  • A screenshot showing “good” and “bad” regions
  • The console logs with the overlap error metrics
  • A clear description of the target aesthetic
This is the same debugging loop you’d use writing this by hand, except Opus reads the logs.

​
An honest take on directionality

Halfway through, you may notice your shingles have a visual directionality (a leading edge) that’s making placements look worse than they are. Try the same script with non-directional panels (symmetric meshes), often the orientation problem disappears entirely and the result is noticeably cleaner. This is a design decision, not a code problem. Worth trying before pushing more constraints into the model.

​
What this is and isn’t

What this is: placement logic that respects real physical behaviour, shingles lap over each other, orientations smooth out, panel sizes vary with curvature. What this isn’t (yet): true fabrication awareness. For that you’d need:
  • Unrolling panels to flat sheets for cutting
  • Nesting unrolled panels onto stock material
  • Bending / curvature limits per panel material
  • Fastener / joint geometry
  • Cut files (DXF, SVG) exported per panel
  • Labelling panels for on-site assembly
All solvable with the same pattern (Opus + Rhino Python + iterate with screenshots and logs), but they’re a separate project.

​
Takeaways

  • Use Opus for constraint-heavy generative scripts. Cheaper models will struggle.
  • “Ask questions if you need clarification” up front saves rewrites later.
  • Split complex scripts into explicit steps (preview → commit).
  • Pass screenshots, logs, and target aesthetic together for the best iterations.
  • Test with non-directional panels before assuming orientation is a code problem.

​
Next steps