A revised STL often arrives with a short note: not much changed. That is not enough for a print shop or mechanical designer who still has to decide whether the new file changes supports, fit, wall thickness, or the quote.
Rotating two models in separate viewers can reveal large edits. It is much worse at finding a slightly smaller hole, a newly thin wall, or a changed mating face. A useful comparison tool should therefore answer more than where did the triangles change? It should explain what those changes may affect.
Start with the manufacturing decision
The first screen should ask what the model is being reviewed for: FDM printing, resin printing, or another bounded workflow. That choice gives the diff practical categories.
A narrow first version could report:
- added and removed material;
- volume change;
- suspected hole-diameter changes;
- newly thin walls;
- changed mating faces;
- overhang areas that may alter support requirements.
Each finding should retain a fixed camera angle and dimensional callout. The reviewer can mark it as confirmed, needs revision, or disputed, then send a browser link instead of another set of screenshots.
Keep private files local by default
STL files frequently represent parts that are unpublished or covered by an NDA. The comparison can run in a Web Worker so the original geometry stays in the browser. Shared review links can store camera state, annotations, and the decision summary without uploading the raw models.
For an implementation starting point, three.js can handle rendering and file loading. A BVH such as three-mesh-bvh can accelerate nearest-point and surface-distance queries. The pipeline still needs explicit normalization for units, orientation, and bounding boxes before any comparison result is trustworthy.
The difficult part is confidence, not coloring
STL does not retain a feature tree, dimensional constraints, or reliable units. Remeshing and chamfers can produce noisy differences. Automatic alignment can snap to the wrong similar surface. Print risks also depend on material, nozzle, layer height, and orientation.
That means the product should not pretend to recover exact CAD intent. Every semantic finding needs evidence, a confidence level, and an easy path back to the raw overlay. It should support review, not claim to replace CAD constraint checking or a factory quote.
Why this workflow was worth examining
A browser-based STL comparison project reached the Hacker News front page in early August. At RayTally's August 3 observation boundary, the post ranked No. 2 with 173 points and 18 comments. That is a point-in-time attention signal, not proof of market size. The related maker discussion also described the concrete handoff problem: a customer sends a revised STL and the recipient cannot quickly tell what changed.
The product opportunity is the layer after the geometric diff: turn changes into manufacturing-impact questions and a review record that both sides can understand.
Read the full source-linked product brief on RayTally. It includes the original signal snapshot, implementation entry point, strongest counterargument, competitors, and cited sources.
