Jeder kann behaupten, seine Software sei solide. Hier sind die Belege.
Meshory wird von einer einzigen Person gebaut, kostet Geld, und der Quellcode ist geschlossen. Das ist viel verlangt, wenn du es einfach glauben sollst, also verlange ich es lieber nicht. Diese Seite ist der Nachweis: was vor einem Release läuft, was ich gemessen habe, was ich mich geweigert habe zu behaupten und was noch fehlt.
Geschrieben von Petros, der Meshory baut. Mehr über den Menschen dahinter.
Nichts erscheint, bevor es all das durchlaufen hat
Jedes Release, auch die kleinen, muss dieselbe Prüfung bestehen. Keine manuellen Ausnahmen, denn eine Prüfung, die man überspringen kann, ist keine Prüfung.
Die Typen müssen stimmen
TypeScript kompiliert die gesamte Desktop-App fehlerfrei, bevor irgendetwas anderes läuft. Ein Build, der die Typprüfung nicht besteht, erreicht die Testphase nie.
6.987 Unit-Tests
578 Testdateien decken die Scan-Engine, die Datenbankschicht, die Archivindexierung, die Duplikaterkennung, die Lizenzierung und die Oberfläche ab. Weitere 52 sind übersprungen statt gelöscht, und die Zahl oben enthält sie nicht.
298 End-to-End-Tests
Playwright startet die tatsächlich paketierte App mit einer echten Bibliothek auf der Festplatte und bedient sie wie ein Mensch: einen Ordner scannen, ihn durchsuchen, den 3D-Viewer öffnen, Dinge taggen, Duplikate finden, Dateien in den Papierkorb verschieben. 63 Spec-Dateien.
Signiert und notarisiert unter macOS
Jeder macOS-Build wird codesigniert und zur Notarisierung an Apple geschickt, bevor er in die Nähe eines Download-Links kommt. Schlägt die Notarisierung fehl, stoppt das Release.
Auch der Installer selbst bekommt einen Smoke-Test
Die CI installiert die fertige App auf einem sauberen Rechner und startet sie. Ein Release, das kompiliert, aber nicht startet, fällt hier auf und nicht erst bei dir.
Veröffentlichung in zwei Stufen
Builds landen zuerst in privatem Speicher. Nichts erreicht die Download-Seite oder den Auto-Updater bestehender Nutzer, bis ein separater Freigabeschritt läuft.
Ich messe an meiner eigenen Bibliothek, nicht an einem Demo-Ordner
Die Benchmarks der ganzen Bibliothek vom August unten vergleichen dieselbe NAS-Bibliothek auf demselben Rechner, vorher und nachher: 141.696 indexierte Dateien in 8.448 Ordnern, 3,3 TB zum Zeitpunkt dieser Läufe am 2. August 2026. Die Rohergebnisse sind mit Zeitstempel, App-Version und der verwendeten Hardware eingecheckt, damit eine spätere Änderung auffällt, die etwas unbemerkt langsamer macht.
Diese Zahl zählt Dateien, nicht Modelle, deshalb ist sie größer als die 118.270 Modelle, die an anderer Stelle auf dieser Website genannt werden. 6.997 dieser Dateien sind ZIP-Archive, und die 100.874 Einträge darin werden als vollwertige Elemente indexiert, statt als undurchsichtige Blobs liegen zu bleiben. Der Rest der Differenz sind Bilder, PDFs und Readmes, die neben den Modellen liegen. Benchmarks zählen alles, woran der Scanner tatsächlich arbeiten muss.
Die letzten beiden Zahlen stammen aus einem späteren Lauf über dieselbe Bibliothek am 8. August 2026, weil die Läufe hinter der Tabelle älter sind als der Zähler, der sie erfasst. Derselbe Bestand: Beide melden dieselben 141.696 Assets in denselben 8.448 Ordnern. Auch dieser Lauf ist veröffentlicht.
um
Bei der Zeile zum ersten Scan endet die Zeitmessung, sobald die Bibliothek zum Stöbern und Suchen bereit ist. Vorschaubilder, Titelbilder und Duplikat-Hashing laufen danach im Hintergrund, und bei dieser Bibliothek noch lange, nachdem der Scan abgeschlossen ist. Gemessen auf einem Apple M4 Pro, 12 Kerne, 48 GB, in beiden Durchläufen gegen dieselbe schreibgeschützte NAS-Freigabe. Deine Zahlen werden je nach Hardware und Netzwerk abweichen. Das hier sind die, die ich dir zeigen kann. Die Spalte mit der Beschleunigung wird aus den Rohmessungen berechnet, nicht aus den gerundeten Werten daneben. Sie kann daher um den Bruchteil eines Prozents von dem abweichen, was du erhältst, wenn du die angezeigten Werte teilst. Das rohe JSON für jede Zeile ist hier veröffentlicht, inklusive Zeitstempeln, App-Versionen und Rechner.
Weniger Warten auf Vorschaubilder
Die neuesten Verbesserungen bei den Vorschaubildern senken die Verarbeitungszeit um 35,8 % in einer Stichprobe von 768 Assets aus meiner kabelgebundenen NAS-Bibliothek. Jedes ausgegebene Bild war vorher und nachher Byte für Byte identisch.
Die Testdatenbank behielt alle 152.955 Asset-Datensätze, während die Vorschaubild-Warteschlange 500 Dateien in Archiven und 268 lose Dateien umfasste. Beide Versionen enthielten bereits die früheren Optimierungen für Vorschaubilder.
um
Median aus zwei Läufen pro Version, in der Reihenfolge vorher/nachher/nachher/vorher, mit warmen NAS- und Betriebssystem-Caches auf einem Apple M4 Pro, 12 Kerne, 48 GB. Die Zeitmessung umfasst den Start der Worker, Lesezugriffe, das Rendern, das Schreiben der Bilder und die Datenbank-Updates. Scannen, Tagging, STEP-Modelle und die Oberfläche waren ausgenommen. Die komplette Bibliothek wurde mit diesen Änderungen noch nicht gemessen. Zum Messprotokoll.
Was ich mir nicht zu behaupten erlaubt habe
Der Sinn des Messens ist, dass die Messung manchmal Nein sagt. Hier ist ein wörtliches Fazit aus einem meiner eigenen Benchmark-Berichte, über eine Beschleunigung, mit der ich gern geworben hätte:
“Directory read aggregate increased substantially even while archive wall time fell, so these runs do not support a directory read speedup claim.”
Im selben Lauf wurde der erste Scan etwa 11 % schneller und die Verarbeitung von Archiven etwa 18 % schneller, beides echt. Aber die Vorschau-Latenz in der Stichprobe wurde schlechter, und ein Ziel, das ich mir selbst gesetzt hatte, war durch die Daten nicht belegt. Also ist es auch auf dieser Seite nicht belegt. Zahlen, die sich immer nur in die schmeichelhafte Richtung bewegen, sind keine Messungen, sondern Marketing.
Was noch nicht fertig ist
Die Liste, die ich lesen wollen würde, wenn ich entscheiden müsste, ob ich der Software eines anderen vertraue.
Windows-Builds sind noch nicht codesigniert.
Windows zeigt bei der ersten Installation eine SmartScreen-Warnung, und manche Antivirenprogramme stellen den Installer als Fehlalarm direkt unter Quarantäne. Beides verschwindet nur mit einer Codesignatur. Bis es so weit ist, stehen für jeden Build die SHA-256-Prüfsumme und ein VirusTotal-Bericht auf der Download-Seite, damit du die Datei selbst prüfen kannst. macOS ist schon heute signiert und notarisiert.
Der Quellcode ist nicht öffentlich.
Du kannst den Code nicht lesen. Der Rest dieser Seite zeigt deshalb, wie ich versuche, daraus ein faires Angebot statt eines Sprungs ins Blaue zu machen.
Sehr große Einzeldateien können es noch in die Knie zwingen.
Eine einzelne STL über etwa einem Gigabyte kann beim Duplikat-Hashing den Speicher erschöpfen. Das ist ein bekanntes Limit mit gemessener Schwelle, keine Überraschung.
Es ist eine einzige Person.
Wenn ich schlafe, wartet deine Discord-Nachricht bis zum Morgen. Es gibt keinen 24-Stunden-Bereitschaftsdienst, und ich tue auch nicht so.
Du kannst den Code nicht lesen, deshalb schulde ich dir stattdessen das hier
Es läuft komplett auf deinem Rechner.
Meshory lädt deine Modelle nie hoch. Kein Konto, keine Synchronisierung, kein Server zwischen dir und deinen eigenen Dateien. Zieh das Netzwerkkabel, und es funktioniert genau gleich.
Was du bezahlt hast, gehört dir.
Einmalkauf, kein Abo. Die Version, die du gekauft hast, funktioniert weiter, und zwar auch offline.
Das Änderungsprotokoll ist konkret.
Jedes Release sagt, was sich tatsächlich geändert hat und warum, auch bei den Korrekturen, die peinlich waren. 23 davon seit dem 8. Juli 2026
Wer den Fehlerbericht annimmt, behebt den Fehler auch
Fehlerberichte und Funktionswünsche gehen an einen Discord, wo sie direkt bei mir landen, und viele davon schaffen es in ein Release. Die Tag-Filterung gibt es, weil jemand im Discord danach gefragt hat. Die Erkennung des Snapmaker-Slicers gibt es, weil mir ein Nutzer Beispieldateien geschickt hat. Die Hälfte der Release Notes geht auf die Idee von jemand anderem zurück.
Sieh es dir mit deiner eigenen Bibliothek an
Lade es herunter, richte es auf deinen schlimmsten Ordner und beurteile es danach, was es mit deinem eigenen Chaos macht.