Selectors and topological naming: how Solid Vibes stays robust

The "topological naming problem" is the reason many parametric models break when you edit an early feature. A fillet that referred to "edge 42" suddenly refers to a different edge, or to nothing, because the kernel renumbered topology after an upstream change.

Solid Vibes avoids the problem by never storing indices at all.

The approach

A Recipe step that acts on faces or edges stores a selector: a description of which faces or edges, by meaning. When the model rebuilds, the selector is evaluated against the new geometry. If the design still has "the edges of the top face" or "cylindrical faces of radius 1.7 mm", the step still finds them.

When you click something in the viewport, the pick is converted to a selector for you. The face or edge IDs the viewer uses are valid for one build only and never persisted.

Face selectors

A face selector is a list of filters, combined with AND, plus an optional pick and a human description.

pick narrows a multi-match to all, largest, smallest or first.

Edge selectors

pick can narrow to all, longest, shortest or first.

Why this holds up

Meaning outlives numbering. "Convex edges of the top face" stays true when you widen the part, add a hole elsewhere, or reorder unrelated features.

createdBy ties selections to design history. "Faces created by the pocket step" follows that feature even if the pocket moves.

Positional filters are a fallback. nearest and containsPoint anchor to a place. They are great for imported geometry, which has no history.

Fillet and chamfer safety

OpenCascade can fail on fillets across tangent edges, for example around the rounded corners of an extruded rounded rectangle. Solid Vibes therefore:

• excludes tangent-continuous edges from fillets and chamfers by default (the notTangent filter),
• guards every step so a failure is isolated to that step,
• runs builds in a worker that can be recycled, because the kernel can occasionally abort. A crashed build is reported as a kernel exception on the failing step and the worker restarts, instead of taking down your session.

Debugging a selector

When a step turns red or acts on the wrong thing, check:

1. How many did it match? Build results report how many faces or edges each selector matched. Zero is the selector_empty case.
2. Is it too narrow? A precise radius filter fails if the radius changed. Loosen it with a tolerance, or select by createdBy.
3. Is it too broad? Add convexity, inPlane or extreme to narrow, or pick.
4. Did the feature it depends on move? Check whether the step creating the target (referenced by createdBy) still exists and is not suppressed.
5. Read the description. Selectors carry a short human describe label such as "top rim". If the label no longer matches the highlighted geometry, the selector has drifted.

You can ask the agent to explain:

Which faces or edges does this step select now, and why? If it matches nothing, propose a more robust selector.

Writing selectors by hand

In script view, selectors appear as readable structures. Prefer (in order):

1. Semantic and feature-based: createdBy plus a shape filter.
2. Semantic and geometric: extreme, normal, convexity, radius.
3. Positional: nearest, containsPoint, mainly for imported bodies.

Avoid over-specifying. A selector with five filters is five ways to break.

Imports

Imported STEP bodies have faces but no creation history, so createdBy does not help. Use geometric selectors (normal, extreme, inPlane) or positional ones. Keep the import step early and stable.

Try it

On a model with fillets:

Explain the selectors on each fillet in this Recipe in plain language, and tell me which ones would break if I changed the base width, and which ones are safe.