Questions about Dexelize

Tri-dexel remeshing is a voxel-based technique that rebuilds a surface from depth samples taken along three orthogonal directions (X, Y and Z). Instead of editing the original triangles, it samples where rays enter and exit the solid, then extracts a fresh, watertight mesh from that volumetric representation. This makes it robust to messy input topology that defeats triangle-by-triangle repair.

Dexelize reads and writes STL on both input and output. Models can be in any unit; the tool reads the file's declared units or assumes millimetres. Additional CAD and mesh formats are on the roadmap.

Anything triangulated. Dexelize handles non-manifold inputs, open holes, duplicated faces, folded facets, and inverted normals automatically — so laser scans, photogrammetry output and broken legacy STL files are all valid inputs. Clean CAD exports work too; they simply skip most of the repair stages.

Yes. Real convex feature edges are detected and preserved to sub-millimetre fidelity, while curved regions are smoothed faithfully without corrugation. Concave edges are left at the voxel's natural rounding, which is a deliberate, geometry-safe choice rather than an artefact.

Output is designed to pass the strict defect checks that convergent-body importers run — degenerate, folded, intersection, inconsistent-normal, laminar-slit and open-boundary-edge checks. Every input is analysed before remeshing and every output is verified before save, so what you download is checked against the same rules the importer will apply.

Multi-million-triangle inputs are routine. The practical ceiling depends on available GPU memory; a typical workstation GPU comfortably handles outputs into the high single-digit millions of triangles. Larger parts can be processed at a coarser voxel size, since memory use scales with the voxel grid resolution rather than the raw triangle count.

Memory use is driven mainly by the voxel grid resolution, not by the input triangle count. Finer voxel sizes on large parts use more memory; coarser settings use less. Processing is chunked into tiles so a part does not need to fit in GPU memory all at once — which keeps memory bounded and lets large dies and mould blocks run on standard workstation hardware.

Small parts typically complete in tens of seconds. Large dies and mould blocks at production voxel sizes take from a few minutes to tens of minutes depending on size and detail level. Coarser voxel sizes are faster; finer sizes trade speed for detail.

A CUDA-capable GPU is strongly recommended and is the default path, because the tri-directional ray casting and surface extraction are GPU-accelerated. A CPU-only fallback exists for evaluation and for machines without a suitable GPU, but it is considerably slower and is intended for trying the tool rather than production throughput.

Yes, via the CPU fallback, but with a significant speed penalty compared with GPU processing. The CPU path produces the same geometry; it simply takes much longer. For occasional small parts or evaluation it is workable; for regular production use a CUDA-capable GPU is recommended.

Dexelize targets Windows, Linux and macOS. GPU acceleration depends on having a compatible CUDA-capable GPU; where one is not available, the CPU fallback path is used.

Yes. Dexelize is built around a scriptable command-line interface, so it can be driven from automation and batch workflows — for example, processing a folder of STL files and writing the cleaned results to an output folder.

The desktop edition processes everything locally; nothing leaves the machine. Any hosted evaluation option processes files on a server and deletes them after the job completes. If data handling is critical to your workflow, the local desktop path keeps all geometry on your own hardware.

No. Dexelize is deterministic geometric processing, not AI or machine learning. The same input and settings produce the same output every time — a deliberate design choice for predictability and repeatability in engineering workflows.