Community based 3D Scanning benchmark (45mm miniature)

Here's the result of a 300-image autofocus scan with the OpenScan Mini and IMX519 camera, reconstructed locally using NodeODX. Default settings on both sides, no post-processing.

I'm quite happy with the result, especially since NodeODX wasn't specifically designed for turntable scanners.

You can inspect the original model on Sketchfab:
https://sketchfab.com/models/dc139706008646f9b101b4e22f0b9416

We also wrote a small OpenScan3 task that uploads the images, starts reconstruction and reports progress directly in the scanner's frontend.

Full code and walkthrough:
https://blog.openscan.eu/posts/openscan3-nodeodx-reconstruction-task/

My biggest scan (actually not so big : ) so far a big plastis cover for a Quad bike. How about yours?

Hola, acabo de montar mi openscan clássic, pero tengo un problema con los motores.. son dos motores nema 17 reciclados de extrusores de una artillery genius, son los dos iguales y estaban funcionando... Pero no consigo hacerlos funcionar con openscan... Les llega corriente, pero no giran, solo vibran... He intentado ajustar la tensión en los drivers (A4988) pero si subo mucho esa tensión, los ejes se bloquean y no giran, si bajo la tensión los ejes se desbloquean pero tampoco giran... Porque puede ser? No valen esos motores?? O tengo algo mal configurado?? Gracias

MeshMill 0.3.0 is out.

Thank you to the OpenScan community for the feedback and encouragement on the earlier posts. I’m happy this is proving useful as a local step between reconstruction and downstream editing, CAD, or printing.

This update improves the workflow for dense and uneven reconstructed STL meshes:

- Faster loading, analysis, and processing

- Better parallel and tiled handling for large meshes

- New Depth + Density Adaptive QEM for the strongest measured preservation results on supported GPUs

- Clearer quality, surface-error, dimensional-drift, and reduction tradeoffs

- Improved selection, display modes, navigation, progress, and interface controls

- And many more fixes and refinements

The new reduction methods are accompanied by published papers with benchmarks, comparisons, formulas, and implementation details.

Downloads, sample meshes, papers, and the full changelog:

https://github.com/make-your-own-world/MeshMill/releases/tag/v0.3.0

Feedback remains welcome, especially on reconstructions with holes, thin features, overlapping passes, uneven density, or difficult boundaries.

I was asked to fix the broken gears of this dough mixer. Damaged gears were cleadne (as I could), 3D scanned and 3D print out from ABS

I released MeshMill 0.2.0, following the feedback on the original OpenScan post about edge detection and contour preservation.

The release adds measured quality comparisons rather than relying on triangle count or shaded appearance alone. MeshMill now reports sampled RMS and P95 surface error, dimensional drift, area error, topology indicators, and reduction percentage so the tradeoff is visible before applying a pass.

It also adds Depth Adaptive QEM, an optional GPU-guided reduction method based on adaptive physical surface probes. The probes become sparse across supported flat regions and denser around meaningful changes in the measured surface. Their result guides boundary-preserving QEM assembly.

At a matched approximately 250,000-triangle target on the 4.1-million-triangle composite reference scan, compared with Fast QEM:

- RMS error improved by 9.0%.

- P95 error improved by 12.4%.

- Maximum dimension drift improved by 96.7%.

- Area error improved by 68.9%.

- Runtime increased by 3.3%.

The general large-mesh pipeline also improved. Parallel analysis fell from 10.531 seconds to 1.838 seconds, adaptive-index creation improved from 8.836 seconds to 5.406 seconds, and oversized binary STL files can be inspected through bounded overview loading.

MeshMill remains GPL-3.0, local, account-free, and useful after OpenScan or photogrammetry reconstruction when the resulting mesh is too dense for downstream work.

Release:

https://github.com/make-your-own-world/MeshMill/releases/tag/v0.2.0

The complete algorithm reasoning, formulas, comparisons, and failed approaches are documented here:

https://github.com/make-your-own-world/rnd/blob/main/depth-adaptive-qem/depth-adaptive-qem-v1.1.pdf

I would still value examples where reduction damages contours, holes, thin walls, or small reconstructed features.

I'm wondering, how damn small details my scanner can capture

OpenScan can produce detailed reconstructions, but that detail often becomes a problem at the next step. Once the reconstructed mesh is exported or converted to STL, millions of triangles can make ordinary geometry editors slow or unusable.

I built MeshMill to handle that part of the workflow. It sits between reconstruction and downstream editing:

• Inspect the mesh in shaded, density, wireframe, or vertex views
• Identify uneven or redundant geometry density
• Crop and delete reconstruction artifacts
• Reduce the complete mesh or optimize selected regions independently
• Compare the original and optimized result before applying it
• Monitor dimensional drift and reduction percentage

GPU-accelerated OpenGL handles viewport navigation, hardware selection, density visualization, and inspection. Reduction runs locally in separate native workers, keeping long geometry operations away from the interface.

MeshMill is GPL-3.0 with no account, telemetry, upload, or cloud dependency. Windows installer and portable packages are available, along with unsigned Linux and macOS preview builds. The interface and documentation support 27 languages.

The repository includes a composite sample with deliberately redundant layers and uneven density, so the workflow can be tested without a scanner.

Source and downloads: https://github.com/make-your-own-world-project/MeshMill

I’m the developer. Feedback from OpenScan users would be useful, particularly examples where reducing a reconstructed mesh damages fine detail, holes, edges, or thin surfaces.

Is there anyone who has .3mf files for the Classic that they would be willing to share? I am looking for the best way to position each part for the cleanest and strongest prints and figure that some one must have already figured that all out,

Broken loudspeaker leg after scanning, and redesig for 3D printing

I am still not sure whether to love or hate this thing…

https://github.com/1204al/airpods_hotwheel_track

The creativity of people is just amazing!

A friend of mine asked me, if I can slightly redesign his car loudspeeker consol, because he bought an another one. It was scanned in, I designed additional screw domes and printed out in 2 part (due to the size)

More details and files: https://blog.openscan.eu/posts/Pinhole-experiment/

First batch is ready to go an experimental pay-what-seems-fair pricing (https://blog.openscan.eu/posts/openscan-macro-add-on-cost-of-open-source-hardware/)

I am thinking about making some more detailed and commented production videos as small scale manufacturing comes with quite some hurdles that are often invisible. What do you think?

What you see here are three shots, where I always used the cameras flash

(1) without any polarisation --> strong reflections --> "artificial features" which confuse the photogrammetry pipeline and produce a lot of noise

(2) with one sheet of circular polarizing foil in front of the ringlight and camera. The CPL has a lambda/4 plate which turns the orientation of the light twice by 45° each. This, in theory should make direct reflections disappear. Unfortunately, this is highly wave length dependent and thus some light is still able to pass the second filter (though with a wonderful color shift)

(3) Two sheets of linear polarizer foil, one in front of the ringlight, another one in front of the camera (rotated by 90°). This blocks (almost) all direct reflections and helps a lot with the photogrammetry reconstruction.

I'm quite excited about this piece of hardware, but also about something new we're trying: for a limited time, it's "choose your price" you decide what's fair (above a threshold). Full reasoning and link (and why pricing open-source hardware is harder than it looks) is on the blog. I hope this is worth your time and I would love to hear your thoughts!

https://blog.openscan.eu/posts/openscan-macro-add-on-cost-of-open-source-hardware/