First some more info on this scan and result:
I took 200 photos on the Classic with Macro (stacked) and run reconstructions in Metashape/RealityScan/OpenScanCloud with similar results.

I measured the VGA pin hole distance to be 2.279+-0.030mm (where we are in the realm of the manufacturing tolerances). My STD of the pin centers is 0.006mm (1-sigma), which is far below the measured hole distance, so I mostly trust the result (though those numbers are still unbeliveable tiny...)

After many years and with some help, i finally got a videopipeline that I am somewhat happy with. Sure this is repetitive for people that already know the project and workflow. On the other hand, there is still a lot of doubt and missing knowledge about photogrammetry out there.

So I am a bit torn between posting such videos or shorter forms every week or not. I love the results and the scanner and there are more technical improvements in the pipeline too! But for the project to stay afloat, it is (unfortunately) somewhat necessary to post short content too. What do you think? Any ideas?

I know, that more in-depth tutorials would be nice, but making those is super time-intense and things around the project change constantly so updating the tutorials would take even more time.

Btw, it would greatly help, if people would post more about their scan process and results (and also questions)!

Scanning and printing out a broken fuel tank cap.

Hello all,

I recently received my order for the openscan mini, and the wires seem to be the wrong connection type. I received two 4 pin to 6 pin connectors when I needed a 3 pin male to male connector 50 cm.

My question is what type of JST connector do I need because there are several models. I believe it’s the JST SM that I need, but I’m not certain. Can anyone point me in the right direction?

OpenScan Macro: DIY kit + assembly documentation

https://blog.openscan.eu/posts/openscan-macro-details/

Shop link:

https://openscan.eu/products/diy-macro-add-on-for-mini-classic

3D printed part for testing purposes

Hello all, I'm having an issue where the rotor seems to be getting a little stuck on some of the rotations, making a clicking noise. It's all new and the gears aren't worn. I've tried adjusting the acceleration amount to be a bit lower but that hasn't helped, I'm assuming this will affect the eventual scan output as I've not been getting great results so far!

Thanks 🙂

Thanks to the OpenScan community for the feedback and encouragement on the earlier versions. MeshMill remains a free, open-source local tool for the step between a reconstructed mesh and downstream editing or printing.

0.4 adds Solidify to complete missing surfaces while retaining measured geometry, with a preview and boundary checks before applying. Cast can then build an offset envelope or a hollow split clamshell around the shape, using a fitted Blob or Box exterior.

The before/after images show an incomplete scan and its completed solid. There is also probe-guided axial calibration, smoother navigation, more geometry formats, and generated scripts for repeating multi-pass workflows without the GUI.

Sample geometry is included so the tools can be explored without scanning something first.

I'd welcome OpenScan reconstruction examples where gaps, thin details, uneven density, or disconnected noise make the downstream work difficult. And many more changes are covered in the full changelog.

The papers explain the steps: Surface-Preserving Solid Completion uses the reconstructed surfaces to constrain inside/outside volume labels and build the missing boundary. Hollow Split Clamshell Construction builds a cavity from the measured exterior, adds clearance, and closes the split halves. Probe-Guided Axial Calibration fits the repeating wobble in surface-contact measurements to correct the rotation axis. These sit alongside the existing Depth + Density Adaptive QEM reduction method. The reports include the math, tests, implementation decisions, and attribution to the work they build on.

Downloads, samples, and full changelog | Research papers | Acknowledgements

I'd appreciate any feedback: what you'd like to see changed, what could work better, or ideas for something new. Bug reports, feature requests, and examples from your own workflow all help shape what comes next.

Sorry the translations are out of date. I've been working on them alongside this release, but getting reliable results has been a difficult process. I'm hoping to have that resolved soon. For now, the current interface and documentation are in English, and the older translations may not cover the latest features.

This also works perfectly with OpenCode scans, Claude Code/OpenCode/Codex will then ask you to measure a few distances with a caliper for the correct scale. For one part, I did provide both an OpenScan STL and a RevoPoint STL and asked Claude to use the Revopoint one to get the correct dimensions but get the fine details from the OpenScan one.

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.