What our run established
Our run on September 27, 2026, tested commit 1476fd0, not today's default branch. The build succeeded in 31 seconds, and the test command failed after 10 seconds. Installation had already succeeded in 29 seconds.
Our sandbox record includes success flags, exit codes, elapsed time, timeout status and command-output tails. Installation and build returned zero; tests returned one, without timing out. These outcomes establish command results, not a working image-to-mesh session. We did not verify GPU inference, generated mesh quality, packaged installers, desktop automation or export.
The raw test footer says "Ran 53 tests in 1.601s" and "FAILED (errors=2)". That is a suite-specific footer, not a verified count of all unique tests in the repository. The attached aggregate tests field is null. Stored parser summaries do not establish exhaustive unique coverage, and no new execution or complete-log reconciliation was performed.
The tail also contains registry messages about incomplete registrations for pending-update and pending-token, alongside missing-environment and other recovery messages. It does not identify the two failing test cases or establish their cause. Those messages cannot justify attributing both errors to registry reloads.
The recorded npm audit total is 8 advisories: 4 high, 3 moderate and 1 low. These are dependency advisories, not proof of exploitable application vulnerabilities or a security assessment. Scan coverage is unknown because the record has no scannedPackages field.
The MrKeyoor testing methodology explains command outcomes and their limits. Its current text provides provenance context; it does not establish which methodology version governed this September run.
What the desktop workflow provides
The commit-pinned README describes installing an extension from its GitHub URL, downloading its model, and connecting Image, Generate Mesh and Add to Scene. It also documents workflow validation and in-app mesh smoothing and decimation. These are documented capabilities, not features exercised by our sandbox.
Modly's documented CLI controls a running desktop app. That makes it relevant to scripts around a workstation workflow. The README explicitly separates backend-only helpers from proof that the Electron/Desktop bridge is ready. Treat a successful backend command as a narrower result than successful desktop generation.
AMD support has changed in the documentation
The current README documents AMD GPU support through ROCm on Linux and Windows. It says Radeon detection steers extensions to ROCm PyTorch wheels without requiring a separate ROCm installation. The README at our measured commit does not contain that platform note, and our run did not test AMD hardware. Current documentation therefore supports trying the documented AMD path, but supplies no measured compatibility result from our sandbox.
Both README versions target Apple Silicon for macOS. Before downloading weights, check the requirements of the exact extension and model variant you intend to use. Broad operating-system support does not establish that every extension works on every GPU.
Choose the interface or the model pipeline
Hunyuan3D 2.0 separates bare-mesh generation from texture synthesis. Its repository documents code, a Gradio app, an API server and a Blender addon. Choose that direct route when you want to work with its shape and texture pipelines rather than manage models through Modly. Hunyuan3D also belongs to Modly's extension ecosystem, so the model family can complement the desktop app rather than replace it.
InstantMesh provides a command-line route from images to 3D meshes. Its repository also documents a local Gradio demo and recommends a Python, PyTorch and CUDA environment. Choose it when a focused reconstruction pipeline fits your task and you are prepared to manage that environment. We did not compare its output quality, speed or installation reliability with Modly.
How to read the ratings
These editorial ratings use a five-point rubric: 1 means substantial documented obstacles, 2 means limited readiness, 3 means a usable documented path with material gaps, 4 means strong supporting evidence within the dimension, and 5 requires broad validation. They are not benchmark results. Setup considers the build and the remaining runtime work; documentation considers user instructions and authoring gaps; community considers visible participation; maturity considers the beta release and our failed test command. Community participation does not measure adoption or support response time.
Before committing an asset workflow
Start with one extension on your intended workstation. Download its weights, generate from a representative image, restart the app, reopen the model and export a mesh for inspection in your target tool. This is an acceptance check to perform, not a sequence our sandbox completed. Use its outcome to decide whether Modly belongs in your workflow.