SPOLIA — Growing Supports

SPOLIA

A sculpture has to hold itself up twice. Once as an object, standing in a room — and once, briefly and awkwardly, while it is being printed, when it is not yet an object at all but a few hundred half-finished layers of warm plastic. Most software treats the second as a separate, disposable problem: scaffolding, generated in a slicer, snapped off and binned.

This page is about not doing that. Supports in SPOLIA are grown as part of the piece — in the same signed-distance field, smooth-unioned into the same surface, carrying their own block material — so that a strut can be a decision rather than a nuisance. Roman workshops carved struts and tree trunks into marble for exactly the same structural reason, and then made them mean something. So can we.

Live at https://auriea.art/spolia/, in the ≡ menu.

The rule

A printer can lay a new layer slightly wider than the one beneath it, but not much. The usual working figure is 45° from vertical: past that lean, a downward-facing surface has too little underneath it and droops. Spolia measures this exactly the way a slicer does, on the surface normal — -n.y against cos 45° = 0.7071 — and tints the lit render toward red as a face passes it.

A vessel stood upright, heatmap on, no supports yet. Two red bands: the flared lip of the rim, and the underside of the base ring. Everything else on this form is vertical or better, and needs nothing.

Two details worth knowing. The tint is applied to the lit colour, not the albedo — overhangs are by definition the faces turned away from a key light coming from above, so tinting the base colour before shading buried the warning in its own shadow, which is where the first version of this went wrong. And the toggle is view-only: it is not saved into a .spolia file and never reaches an export.

What slicers actually do — and the mistake I made first

The first working version grew a branch upward from a root you tapped on the ground, reaching toward the flagged overhangs. It made a convincing single strut and left most of the piece untouched, and it took a while to see why that was not a tuning problem but a structural one: coverage was contingent on reach. A ring of overhang around a base can never be reached from one point inside it, however good the search — the far side of the ring is always too far sideways for the height available. Clustering the targets and retrying in rounds only papered over it.

PrusaSlicer and Cura both go the other way, and PrusaSlicer's source says so in one line. In src/libslic3r/Support/OrganicSupport.cpp:

using Forest = std::vector<Tree>;

A forest, never one tree. Overhang tips are laid across the entire flagged region at a set spacing — support_tree_branch_distance, generated as a zig-zag infill over the overhang area — and each tip begins its own branch at the surface it has to hold. Branches then descend, and merge with each other on the way down. (PrusaSlicer's organic supports, added in 2.6, are Thomas Rahm's rework of Cura's tree supports.)

Turn it around and the coverage problem evaporates, because it was never really a search problem: you cannot miss an overhang you started from.

Growing downward

So: find the overhangs, thin them to evenly spaced tips, and let every tip fall.

The same vessel, grown. On this piece: 122 flagged surface crossings → 22 tips → 94 capsules, of which 7 reach the build plate. About 20 ms to compute.

Each tip descends in small steps. Three things shape the step:

• Down, always, as the base direction.
• A lean toward the nearest sibling, so branches converge instead of falling as a parallel thicket of separate sticks. This is what produces trunks.
• A push away from the piece when too close to its surface — see below.

When two branches come within a merge radius they become one node carrying both tip counts, and thickness follows the pipe model: a branch's radius is leafR × tips^(1/2.5), so merging two equal branches gives r × 2^(1/2.5) and the trunk thickens toward the plate the way growth rings do, with no manual taper anywhere.

Underneath the base ring: thin twigs at the contact points, merging downward into fewer, fatter legs. Every junction sits below the branches entering it — which turns out to matter more than it sounds.

A branch stops when it reaches the plate, or when the piece itself blocks its descent — in which case it lands there. A support springing from the sculpture's own lower body is not a failure case; it is a puntello.

A support must not need a support

The obvious trap, and the one Auriea named before I hit it: scaffolding that is itself unprintable.

The guarantee is enforced at the step, not checked at the end. Every descent direction is clamped into a cone of 35° from vertical before it is taken. A cylinder leaning θ from vertical presents a steepest underside normal of sin θ, so 35° gives 0.574 — comfortably inside the 0.707 that flags the model, with margin to spare. And because the cone is convex, a run of steps collapsed into a single capsule is still inside it: the vertical components add exactly while the horizontal ones can only partly cancel, so a merged capsule can never lean further than its own steepest step. That is a proof rather than a hope, which matters, because three separate bugs each broke it in a way that looked fine on screen:

Every grown forest is re-checked capsule by capsule afterwards, and the count of violations is reported. It should always read zero — and if it ever doesn't, the clamp is wrong, not that particular tree.

The grown supports with the heatmap switched back on. The branches carry no red at all. What remains is a thin line along the rim and base lips, between the contact points — the same residue a slicer leaves, since it also supports a continuous lip at intervals and bridges the gaps. It is not zero, and it is honest to say so.

Standing off

The first version that covered properly still looked wrong: branches from the rim hugged the neck all the way down and read as wax runs, not struts.

Slicers keep a clearance from the model (xy_min_distance) so branches remain their own object. Spolia now does the same, pushing away along the horizontal gradient of the field only, so the push is sideways off the wall and never argues with the descent. It also walks each new branch clear of its own contact point, since a tip starts life exactly on the surface. The difference is entirely visual and entirely worth it: the struts arch away and read as structure.

The Roman argument

Anna Anguissola's Supports in Roman Marble Sculpture: Workshop Practice and Modes of Viewing (Cambridge, 2018) is a whole book against the idea that a strut is merely technical. Her point is that scholarship has dismissed these elements — especially plain non-figural struts — as "mere safeguards for production and transport", and that close attention to them instead reveals what buyers and carvers actually wanted.

The catalogue of solutions is remarkably close to what a support generator produces: tree trunks and stumps beside a leg; plain rectilinear struts bridging a limb back to the body; pillars, herms and vertical slabs behind a figure; and drapery engineered into a falling mass that happens to carry load.

The plainest form, and the oldest. The Aristodikos kouros (ca. 510–500 BC, Athens NAM 3938) had two short struts bracing its free-carved hands back to the thighs. The hands are long gone; the struts are still there, two blunt stubs at hip height. Purely structural, no pretence otherwise — a puntello in its raw state, and unmistakably the same object as a slicer's support.

The Diadoumenos from Delos (ca. 100 BC, Athens NAM 1826). The knotty 80 cm tree trunk at his left leg is almost detached from the figure and of little consequence to its stability. It carries his mantle and a hanging quiver — which is what names him an archer, possibly Apollo, on Apollo's own island. The support is doing iconography, not statics. Anguissola notes that the statue was entirely gilded, support included.

Silenus cradling the infant Dionysus (Vatican 2292), one of three full-size copies. Two support types in one object: the vine-wrapped trunk that takes the weight of the leaning body, and — at shin height — a plain squared strut tying his lower leg back to it, exactly the kind of bar a modern eye reads as scaffolding someone forgot to remove.

The comparison is the sharp part. The Louvre's version of the same group leaves those extra struts out, which made the carving harder, needed a broader block, and produced a figure whose weight reads across a diagonal rather than sitting in a flat rectangular frame. Same subject, same prototype, different answer to how much support to admit to — and the answer changes the sculpture.

And in the Townley Dionysus at the British Museum, the support is the subject: Ampelus, the boy the god loved, caught mid-metamorphosis into the vine that props up the composition. The strut became the story.

That is the whole design brief for this feature, written down two thousand years early: the support is a compositional choice with a structural floor, not an afterthought.

Which is why a grown forest carries its own block material, chosen independently of the body. Here the same struts are cast bronze against a marble vessel — a metal armature holding stone, the way a museum mount does. Oak, walnut and ebony read as the tree trunk that Roman copyists actually carved; plaster reads as a restorer's fill; and a support in the same marble as the body reads as what it would have been in a Roman workshop — carved from the same block, left in place.

Using it

In the ≡ menu:

• overhang on / off — the heatmap. Try it before and after re-orienting a piece; rotating a form is usually cheaper than supporting it.
• grow supports — covers the whole piece automatically. Says how many supports, how many segments, and how many reached the plate versus landed on the piece.
• add a support — then tap. The tap names a point that should be held up, not a root to grow from; the branch descends from it like any found tip. Hand-placed tips survive a regrow, because they are your decisions and not the algorithm's.
• support material — the same block picker as any fragment.
• clear supports.

The constants, for reference:

What it does not do yet

• The thin red line along a continuous lip between contact points, described above.
• Everything currently runs to the plate on this test piece (onModel: 0). The short rim-to-shoulder strut a Roman workshop would carve happens only where geometry blocks the descent, or where you place one by hand. Making short local struts the preferred solution, the way Anguissola's puntelli are, is the obvious next move.
• Supports are one shared forest, not per-fragment objects, and they cannot yet be dragged with the gizmo or saved into the library as a fragment of their own.
• The capsule budget is a hard 96. Past that the thinnest twigs are trimmed first — reported when it happens, but a trimmed twig means a lost contact point.

Photographs of the ancient sculptures are from Wikimedia Commons, not from Anguissola's book, whose plates are separately licensed: Aristodikos kouros by Gary Todd (CC0); Diadoumenos by Francesco Bini (CC BY-SA 4.0); Silenus by sailko (CC BY-SA 3.0). The Spolia renders were made offline from the same baked fragment atlas and the same grown capsule list the app uses, so they are the real field rather than a redrawing of it.

#ai