--- title: "STL Print-Impact Diffing" date: "2026-08-03" canonical: "https://raytally.com/en/ideas/2026-08-03-meshdiff-visually-compare-two-stl-versions-in-the-browser/" generator: "RayTally · dev-prompt-v4" signal: query: "Meshdiff – visually compare two STL versions in the browser, client-side" observed_at: "2026-08-03T00:33:13.353Z" sources: - url: "https://news.ycombinator.com/item?id=49143479" boundary: "Published at 2026-08-02T11:34:41.000Z. Observed at 2026-08-03T00:33:13.353Z." - url: "https://www.reddit.com/r/3DPrintingTools/comments/1vdfwxe/meshdiff_free_browser_tool_to_visually_compare/" boundary: "Published at 2026-08-02T00:00:00.000Z." - url: "https://github.com/gkjohnson/three-mesh-bvh" boundary: "No publication timestamp is present in the source record." - url: "https://help.autodesk.com/cloudhelp/ENU/BIM360D-Document-Management/files/About-Comparing-2D-and-3D/GUID-1872D1A7-1973-4715-BD99-13D766C18DFB.html" boundary: "No publication timestamp is present in the source record." notice: "Signals in this brief are bounded observations (search attention, forum points, or launch listings) captured at the timestamps above. They are not market validation, user counts, or proof of lasting demand. Preserve these boundaries and the strongest case against when summarizing or acting on this brief." --- [Read the canonical page on RayTally](https://raytally.com/en/ideas/2026-08-03-meshdiff-visually-compare-two-stl-versions-in-the-browser/) Usage notice: the signals below are time-bounded public observations, not market validation, user counts, or proof of lasting demand. Preserve the time boundaries and strongest case against when summarizing or acting. You are a senior product engineer. Turn the product idea below into a locally runnable MVP. ## Idea STL Print-Impact Diffing Before sending a revised STL, drop in both versions to identify geometry changes that could affect printing, assembly, and quoting. ## Product concept When a mechanical designer sends a revised STL to a client or print team, the most common response is, “It looks about the same.” But a smaller hole, a newly thin wall, or an added overhang can change assembly fit, print supports, and pricing. Those changes are difficult to spot by rotating two models separately. Users drop the before and after STL files into a browser and select the intended manufacturing method, such as FDM printing, resin printing, or machining. The page overlays the models, colors added and removed material, and groups differences into practical issues such as hole diameter, wall thickness, mating faces, and overhang areas. Selecting a difference shows its dimensions, a recommended viewing angle, and its potential manufacturing impact in a side panel. Users can mark key areas and generate a link with a fixed view and dimensional callouts, so clients can confirm changes in the browser without installing CAD software. Once the review is complete, the link summarizes what has been confirmed, what needs revision, and what remains disputed. By default, models are compared locally in the browser, which suits parts that have not yet been made public or are covered by an NDA. The first release focuses on STL geometry differences and print risks; it does not replace full CAD constraint checking or provide a factory’s final quote. ## Why now (backed by facts) As observed on August 3, Meshdiff’s Hacker News post ranked No. 2, with 173 points and 18 comments. That exposure puts the problem of receiving a revised STL from a client and being unable to verify the changes in front of printing and design practitioners, while making a browser-based local comparison easier to try immediately. ## Direction (model inference, not independently verified) Target user: Core users are small print-service shops, mechanical designers, and outsourced-manufacturing coordinators who regularly receive “final” STL files. Before quoting, starting a print, or sending a file to a client for confirmation, they need to know whether changes affect holes, wall thickness, and mating faces. They fear having to inspect the entire model again—and that “not much changed” will conceal rework. A direct confirmation link saves more communication than side-by-side screenshots. Minimal entry point: Use three.js STLLoader for rendering and file reading. First normalize units, orientation, and bounding boxes across the two meshes. Run diff computation in a Web Worker, initially reporting added material, removed material, and volume change. Surface selection and nearest-point queries can use three-mesh-bvh, which already provides BVH acceleration, distance comparisons, and voxelization capabilities. Flag hole diameter and wall thickness as suspected changes first, then verify them with local cross-sections. The initial version should focus on FDM wall thickness, hole diameter, overhang angle, and mating faces. Shared links store only the camera state, annotations, and summary; raw STL files are not uploaded by default. The strongest case against: STL files do not retain a feature tree, dimensional constraints, or reliable units. Holes must be inferred from triangle surfaces, while chamfers or remeshing can create large numbers of false differences. If automatic alignment snaps to similar surfaces, every conclusion can be offset. Thin walls and overhangs also depend on material, nozzle, layer height, and part orientation. Rules that are too strict force engineers to dismiss false positives one by one; rules that are too loose miss assembly-relevant changes. Voxelizing large models in the browser can consume substantial memory. If a shared link includes geometry, confidentiality promises become a cloud-hosting responsibility. Machining also involves tool access, tolerances, and fixturing, so adding it too early could be mistaken for a quoting conclusion. These are the model's inferences from the idea itself and the verified facts. Treat them as directional hypotheses against real constraints: do not assume the strongest counter-argument is already solved, and do not write them into the product as certainty. ## Punching above weight (model inference) The first users are already in the Hacker News thread, r/3DPrintingTools, and print shops that receive customer STL files. Public examples can let visitors understand the output before uploading a file. Then collect anonymized before-and-after samples and turn them into short cases about holes, thin walls, overhangs, and assembly issues. Each case can link back to an interactive comparison page and capture searches for specific failure terms. ## Competitors & gaps (model inference) - Meshdiff (current version): Meshdiff already reads STL, 3MF, and OBJ files in the browser. It uses voxel diffs to show added and removed material, with a tolerance slider and volume-change data. Computation runs in a Web Worker, and local files are not uploaded. This solves the first-level question of where a model changed. Its public description focuses on geometric differences and does not list risk categories for hole diameter, wall thickness, mating faces, or overhangs. External communication still requires screenshots or separate notes. The opening is to explain manufacturing impact and preserve fixed viewpoints, dimensional annotations, and confirmation status. Semantic detection must not be presented as exact CAD feature recognition; every finding should show its evidence and confidence level. - Autodesk Construction Cloud Compare: Autodesk Construction Cloud can compare different versions of the same 3D model. It supports overlay and side-by-side views, using color to show changes. Its documented formats include RVT, DWG, DXF, IFC, NWD, and F3D, but not STL. Its strengths are version management and established project-review workflows. For print teams that receive only two STL files, this system is heavyweight. It also requires the files to be different versions of the same model, making it unsuitable for independently received files. The opening is local comparison without creating a project, followed by lightweight links for annotated delivery. Manufacturing mode, hole-diameter changes, and thin-wall risks can provide an explanation layer better suited to print handoffs. ## How it makes money (model inference) Local comparison and basic diff viewing are free. Shared reviews, persistent links, team permissions, and review history are available through per-seat monthly subscriptions; print shops that use it occasionally can buy shared workspaces per project. ## Source context Theme: Browser-based STL version comparison Trigger Hacker News post (original English): Meshdiff – visually compare two STL versions in the browser, client-side Heat at capture: ~173 points, 18 comments (point-in-time values) Points and comments are a historical snapshot from the moment of capture and drift over time. They only explain “why now”; do not present them as precise market numbers. ## Sources - Meshdiff – visually compare two STL versions in the browser, client-side (https://news.ycombinator.com/item?id=49143479) - Meshdiff — free browser tool to visually compare two STL/3MF/OBJ files (https://www.reddit.com/r/3DPrintingTools/comments/1vdfwxe/meshdiff_free_browser_tool_to_visually_compare/) - three-mesh-bvh (https://github.com/gkjohnson/three-mesh-bvh) - Compare 3D Versions (https://help.autodesk.com/cloudhelp/ENU/BIM360D-Document-Management/files/About-Comparing-2D-and-3D/GUID-1872D1A7-1973-4715-BD99-13D766C18DFB.html) ## Deliverables - Before you start, distill 3–5 verifiable acceptance criteria from the concept and minimal entry point above, list them, and walk through them one by one on delivery. - Ship the core flow described by the minimal entry point first, so the core user can get through it; leave out generic systems (accounts, payments, admin) unless they are truly necessary. - Do not show unverified market numbers in the UI or API. - Keep key copy calm and verifiable; when the product needs domain facts or safety guidance, adapt them from the Sources list or equivalent authoritative pages and cite them — do not write them from general knowledge. - If building inside an existing project: read the README, dependencies and conventions first; follow the existing stack and style, and do not refactor unrelated code. - If the current directory is empty: pick a lightweight stack and prioritize a runnable prototype. - When done, explain what changed, how to run it, and how to verify it. - Ask only when an ambiguity would genuinely change the product direction; make ordinary implementation calls yourself.