The Problem with Scan Data

Everyone knows SOLIDWORKS struggles with large scan data. 🫣 Even on high-end workstations, the software eventually becomes unusably sluggish when mesh models exceed a certain threshold. But when I looked for hard data on why, I only found folklore: "turn down image quality," "buy a bigger GPU," or "keep meshes small." Nobody had conclusive numbers on where the bottleneck actually lives, or what settings to actually change.

Rather than continuing to guess, I set out to definitively measure performance and usability. Because "feels sluggish" isn't a benchmark, I built an automated utility using the API to capture hard metrics.

Methodology

To ensure apples-to-apples comparisons across different hardware, the utility procedurally generates consistent meshes up to 1GB. This guarantees that the same request produces the exact same file everywhere. We measure several key metrics per size including:

• Import Time: From opening the file to when the UI becomes interactive.

• Display Performance: Orbit frame rate (FPS) under controlled rotation.

• Save Time: Writing the data out as a native part file.

Reference Machine: Threadripper PRO 7975WX (32C/64T), 63.3 GB RAM, SOLIDWORKS 2026 SP3.

Initial Findings

• Finding 1: The Import Mode Decides Everything. Graphics bodies load exponentially faster than mesh bodies. At 500MB, a mesh takes 493 seconds to load; a graphics body takes 90 seconds (a 5.5x difference). This gap widens with file size rather than staying proportional.

• Finding 2: Interactivity Falls Off a Cliff. At 100MB, a mesh body chugs at 0.76 FPS, which is where we as operators really start to feel the software struggle. The same file as a graphics body hits 115.8 FPS (a 152x difference). Graphics bodies stay fluid up to 500MB, while mesh body performance plummets. The trade-off is topology: you can look at a graphics body, but you can't edit it or efficiently derive geoemtry/curves from it. That is a workflow decision, not a hardware one.

• Finding 3: The Hard Usability Limits. After the initial import, Graphics bodies scale effortlessly beyond 500MB. Mesh bodies (ScanTo3D) hit an interactivity wall around 300MB. Surface and solid body conversions collapse completely after a few megabytes (2-5MB), and solid imports only succeed if the mesh is manifold & watertight.

• Finding 4: A Bigger GPU Won't Save You. During the worst frame rate drops (0.16 FPS), GPU utilization peaked at just 61% and VRAM at 3.67 GB. The bottleneck happens long before the data reaches the graphics card. The budget is better spent on memory (Capacity & Speed/Bandwidth) and the sustained top-speed of a single CPU-thread.

• Finding 5: You Are Measuring Your Pagefile. Above 250MB, performance is dictated by pagefile swapping. Even with 64GB of installed RAM, the system woudl still hit 79,333 hard page faults per second. While some additional reasearch is needed to determine why, it is expected that a machine with less ram will hit this wall far sooner.

• Finding 6: Saving is the Sleeper Cost. A 500MB mesh saves as a 777MB part file and takes nearly 25 seconds to write. Plan your disk space and backups around the saved size, not the source file. Expect solidworks to become unresponsive during file saves and utilize ***in-context assembly modeling strategies *** to limit pointless save times.

• Finding 7: Image Quality Settings Do Nothing. Sweeping through every display quality slider produced zero measurable difference outside the noise floor. Since meshes arrive already tessellated into triangles, it is logical that these settings are irrelevant for hte base import; however, they may impact performance if parametrically modeling surfaces/solids into the same file.

Overcoming API Limitations

Getting honest data required working around some serious API quirks:

• Accurate Timing: The API severely under-reported import times (e.g., claiming 81s for a file that locked the UI for 914s). The tool now strictly measures true time-to-interactive.

• Noise Filtering: To filter out ranking by luck, the soem modes of the benchmark repeat conditions and aggressively flags variances into the log file for variances smaller than the scatter noise.

Workflow Recommendations

Based on the initial data, here is how to handle meshes today:

• Import as a graphics body when you only need visual reference. You sacrifice direct interaction but gain vastly more usability at high complexities.

• Keep mesh bodies under 300MB if you need topology. Past that, decimate the entire model before importing rather than fighting the software.

• Decimate HEAVILY before surface/solid conversion. Those modes stop being viable around 2MB. This is a pre-processing requirement, not a hardware limitation.

• Buy memory, not graphics. Disk paging is what ends the run.

• Stop tuning image quality for mesh work. Spend the effort optimizing your import mode instead.

The Next Step: Building the Dataset

To turn these initial findings into a definitive whitepaper, I need a larger dataset. Right now, this is just the opinion of one high-end workstation. By running this benchmark on a variety of setups, we can map out exact hardware recommendations based on data complexity...and vice versa....while predicting the actual ROI of hardware upgrades.

Run MeshMark on your machine: DOWNLOAD NOW 

• It is a single, self-contained executable. No installers, no .NET runtimes, no API redistributable. It attaches directly to your active SOLIDWORKS session.

• The default run tests up to 500MB for both mesh and graphics bodies, taking about an hour.

• Requirements: Have SOLIDWORKS open with ScanTo3D enabled. Expect one prompt partway through to switch ScanTo3D off, and a SmartScreen warning on first launch.

Send back the generated JSON report and log file. Your data will directly contribute to a potential final whitepaper and help us build a real-world performance baseline for the community.