SculptForge / Performance guide / Benchmarks / How fast?
Performance: what we're building
Speed on dense sculpts is our top priority, and it has to hold on modest computers first, not only on a fast desktop. This page lists what we're building toward that: what each piece does in plain words, how it works for the technically curious, and whether it has shipped.
About the numbers. We're re-measuring everything on scans with sculpted detail, so this page has no figures yet. They'll appear here once they're verified, each with the method and the machine. Until then, How fast? has the machines, the limits we know of and the steps to measure your own computer, and the benchmarks page has results you can repeat yourself.
Our low-end tier is simulated: the memory, graphics and core budgets of a modest integrated-graphics laptop, applied on an Apple M1 Pro laptop running Linux. We don't have a real low-end laptop in the test set yet; if you have one, your benchmark results are very welcome.
The pieces
Detail levels above the base mesh
Scans and sculpts far denser than a plain mesh could hold stay editable: the finest detail is stored compactly on top of a lighter base mesh instead of as a full mesh of its own.
How it works
Each point above the top subdivision level stores only a 16-bit height along the surface. The graphics card rebuilds the surface from those heights as it draws. The model is split into clusters of triangles that are culled, uploaded and shaded as units, so a stroke re-sends only the clusters it changed, and only the clusters it changed get new shading.
Since 0.10.1; reworked for big brushes in 0.11.2.
Big brushes move the base
A very big brush on a dense scan moves the lighter base mesh directly, the way it would on a plain mesh, and the fine detail rides along.
How it works
When a Standard, Clay or Inflate dab spans many base edges (and no mask, hidden faces, alpha or layers are involved), it runs the plain mesh's brush code on the base. Detail heights are stored relative to the base, so they follow. Moved triangles are tracked in a bitset filled in parallel, only the runs of moved vertices go to the graphics card, and the dabs still waiting when you lift the pen go through the plain mesh's batched path. The stroke stays one undo step.
Shading that catches up within a frame budget
After big strokes on a dense scan, orbiting stays smoother while the lighting catches up: the view moves first, and the shading finishes around it.
How it works
The re-shading a stroke leaves behind is split into pieces. While the view moves, each frame spends only a few milliseconds on it (the same time cap a stroke uses); when the view stops, the rest is done at once.
Lighting that follows the brush while you drag
With a big brush (160 px or more) on a faster computer (six or more threads), the lighting follows the brush's shape while you drag, so the stroke you see stays closer to the pen. The exact shading lands right behind it.
How it works
Each brush's falloff has a known slope, so during the stroke the new normal is computed directly from the old normal and that slope, without walking the neighbouring triangles. Exact normals are recomputed in the background and after pen-up. Computers with fewer threads keep the previous behaviour.
Big dabs applied together, capped by time
When a frame falls behind a fast stroke, the dabs waiting for it are applied together in one pass instead of one by one. It's in Preferences > Performance as Fast Big Brushes.
How it works
Very big dabs take their plane from an even sample of the vertices under them, and the waiting dabs are fused into one pass, so normals, the picking structure and the copy to the graphics card are updated once a frame instead of once a dab. Since 0.11.2 each batch is capped by time, so no single frame waits too long.
It stays off by default because in our measurements it's faster on some machines and scenes and slower on others. It turns on by default only when it wins on the low-end tier first.
Big scans open faster
Opening a dense scan shows a saved preview at once, then the model before all of its shading is done. A cache saved with the file skips rebuilding the same structures every time it opens.
How it works
The project keeps a small preview image, shown while the scene loads; edits wait until the model is in. The first frame lights each cluster by its flat facets until the detailed shading arrives. The cache holds the mesh's connectivity, the picking structure and the detail levels' attachment data, packed and checked against a hash, and is carried over on save while the mesh's connectivity doesn't change. It makes project files bigger; we're measuring by how much before it ships.
Releases built once, then tested
The packages you download will be the same files our full test suite ran against, not a rebuild made afterwards.
How it works
Each batch of changes builds the release packages beside the continuous-integration run, and the main branch moves forward only when the whole suite and CI pass. A release will then promote the packages already built and tested for the exact tagged commit instead of building them again.
An open benchmark, low-end first
Every speed claim comes from a benchmark you can run yourself, and it has to hold on our low-end tier before it counts.
How it works
sculptforge --benchmark standard-15m (or Help > Benchmark) sculpts the same scene with the
same strokes and orbit on any machine and writes the results to a file. We measure lag from the pen sample to
the frame that shows its dab, how long a stroke takes to finish after pen-up, orbit frame rate and memory.
Runs start only when the machine is idle, and we compare builds in alternating runs.
Tiers, in the order a claim must pass them: the simulated low-end tier (also with only two efficiency cores, for a pessimistic CPU), the Apple M1 Pro laptop itself, then a Windows desktop with an NVIDIA RTX 3060. A gain that shows only on the desktop doesn't count.
Since 0.10.7. How fast? · Results and how to submit yours.
Drawing very dense base meshes with less work
Orbiting a scan whose base mesh alone is very dense is still the slowest case on modest computers. We're researching ways to make it cheaper and will write about it here when there's something to show.