Geometric search explained: how shape-based CAD search works

Type a few words into a search engine and it finds pages it has never seen phrased quite that way, because it is matching meaning rather than exact text. Geometric search — also called shape search or shape-based similarity search — does the same thing for 3D parts. Instead of matching filenames or part numbers, it matches the shape of the part itself, returning components that look and measure like the one you are holding, regardless of what anyone named them. This article explains how it works, why it succeeds where text search fails, and what separates a good implementation from a frustrating one.

The problem geometric search solves

Traditional CAD and PLM search relies on metadata: filename, part number, description, and whatever attributes someone entered when the part was saved. That works only when three things are true — the part was named consistently, the metadata was filled in correctly, and you already know what to type. In a real library that has grown for years across multiple teams and naming conventions, none of those reliably holds. The part you need is in there, but it is called BRKT-447-REVC in a folder named for a project that shipped in 2014, and no keyword you can think of will surface it.

Geometric search removes the dependency on all of that. It looks past the label to the thing itself: the geometry. If two parts are shaped alike, it finds them as a match, even if their filenames, part numbers, and metadata have nothing in common — and even if one is a STEP file and the other an STL.

How it works, step by step

Under the hood, a geometric search engine turns each 3D model into a compact mathematical description of its shape, then compares those descriptions instead of comparing the raw geometry. The pipeline generally has four stages.

1. Normalization

A part can be modelled at any position, any orientation, and sometimes any scale. Two identical brackets might sit in completely different coordinate frames. Before anything can be compared, the engine normalizes each model into a canonical pose — centring it, aligning it to a consistent set of axes, and accounting for scale — so that the same shape always produces the same description regardless of how it happened to be saved. Handling rotation, translation, and scale invariance correctly is one of the central technical challenges of the field.

2. Signature extraction

Next, the engine reduces the normalized shape to a geometric signature — a fixed-length numeric descriptor, sometimes called an embedding or feature vector, that captures the essence of the form. Older methods used hand-designed shape functions: distributions of distances between surface points, curvature histograms, spherical harmonics. Modern methods convert the surface into a point cloud or mesh and pass it through a trained deep-learning network that has learned, from large collections of shapes, which features distinguish one form from another. The output is the same in spirit: a string of numbers where similar shapes produce nearby vectors.

3. Indexing

Each part’s signature is stored in an index built for fast nearest-neighbour search across a high-dimensional vector space. This is what makes the search feel instant: rather than comparing your query against every part one by one, the index lets the engine jump straight to the region of “shape space” where similar parts live. A well-built index returns ranked matches from a library of hundreds of thousands of parts in tens of milliseconds.

4. Ranking

When you query — by dropping in a model, sketching a profile, or describing the part — the engine computes the query’s signature and measures its distance to every candidate in the index. The closest matches come back first, each with a similarity score, often refined by secondary checks on properties like volume, bounding box, and the count of faces and edges (the part’s topology). The result is a ranked list: most similar at the top, presented in a 3D viewer so the engineer can judge the matches visually.

Shape, scale, and topology — three axes of similarity

“Similar” is not one thing, and a good engine lets you distinguish between kinds of similarity:

• Shape is the form itself — the silhouette and surface geometry, independent of size.
• Scale is the absolute size — two parts can be the same shape but one twice as large, which matters enormously for whether they are interchangeable.
• Topology is the structural makeup — how many faces, edges, holes, and features the part has, and how they connect.

A true duplicate matches on all three: same shape, same scale (volume and bounding box within a tight tolerance), same topology (matching face and edge counts). A design alternative might match on shape but differ in scale. A family member might share topology but vary in proportion. Surfacing these distinctions is what turns a similarity engine from a novelty into a decision tool.

Why machine learning changed the game

Geometric search is decades old — the academic literature on shape retrieval goes back to the early 2000s, and commercial engines have existed since the mid-2000s. What changed recently is the quality of the signatures. Hand-designed descriptors were brittle: they worked on the shapes their authors anticipated and failed on the ones they did not. Learned embeddings, trained on large and varied collections of 3D models, generalize far better — they capture subtle structural similarity that earlier methods missed, and they degrade gracefully on shapes they have not seen. The effect is that modern geometric search is accurate enough, on messy real-world libraries, to be trusted for consolidation decisions rather than just suggestions.

What separates a good implementation

The core algorithm is necessary but not sufficient. In practice, whether geometric search actually gets used comes down to a handful of practical properties:

1. It works on raw files where they live. If the engine can only search parts already migrated into a particular PLM, most of a company’s geometry — sitting on file servers — stays invisible. The valuable version points at the file server directly.
2. It is format-neutral. Real libraries are a mix of STEP, STL, OBJ, native CAD, and more. An engine that handles only one format finds only a fraction of the duplicates.
3. It accepts natural-language and example queries. Sometimes you have a model to match; sometimes you only have a description. Supporting both — “flat aluminium bracket with four mounting holes” as readily as a dropped-in STEP file — is what makes it usable at the point of design.
4. It can run on-premise. For aerospace, defense, and other sensitive libraries, the geometry cannot leave the network. An engine that requires uploading parts to a vendor cloud is simply unavailable to the customers with the biggest libraries.

From search to reuse

Geometric search is the enabling technology, but the value shows up one step downstream. Once a library is searchable by shape, two things become possible that were not before: an engineer can check “do we already have this?” in seconds before drawing a new part, and the organization can scan the entire library to find the duplicate clusters already in it. The first prevents new proliferation; the second cleans up the accumulated cost. Both rest on the same foundation — a library that finally understands its own geometry.