Sculpt Mode Performance #81180

New Issue

Status: Prototype implemented in D8983 with all optimizations included for Meshes, but only for some tools and features. Needs to be split into multiple patches and implement all remaining features.

Team
Commissioner: @DanielBystedt
Project leader: @PabloDobarro
Project members: -

Description
Big picture: Improve the performance of Sculpt Mode brushes and tools.

Sculpt performance demo.mov

Use cases:

Edit geometry surface detail in high poly meshes without performance issues

Design:
Remove all unnecessary calculations and updates from the PBVH when an editing operation is active, making all the Sculpt Mode code work only with the relevant vertices per brush step. The PBVH should only be used to get the affected area by the stroke as fast as possible.

Engineer plan:

Get the PBVH code ready to have much smaller leaf node sizes
Store draw buffers in intermediate nodes to reduce the size of the leaf nodes of the PBVH.
Make proxies, bounding box and normal updates optional per tool and per symmetry options.
Do fast bounding box recalculations by updating the bounding boxes when deforming and propagating them from children to parents nodes to the root of the tree.
Implement optional fast normal updates (single loop) for brushes that require them.
Replace per node undo with a per vertex undo, which will also be used to get the original data during the stroke.
Remove BMesh based dyntopo (to be replaced with a better implementation).
Remove all loops over nodes from the code that runs when a stroke is active.
Configure the optimal settings of the scheduler per tool.
Make special tools (Pose, Boundary, Elastic Deform) not use the PBVH for getting the affected area. Cache the affected area of these tools once their data is initialized.

Work plan

Milestone 1 - optional name
Optimize PBVH queries and drawing
Time estimate: 2 - 3 weeks

Milestone 2 - optional name
Rewrite task scheduling and per vertex updates.
Time estimate: 3 - 4 weeks

Relevant links:

**Status:** Prototype implemented in [D8983](https://archive.blender.org/developer/D8983) with all optimizations included for Meshes, but only for some tools and features. Needs to be split into multiple patches and implement all remaining features. --- **Team** **Commissioner:** @DanielBystedt **Project leader:** @PabloDobarro **Project members:** `-` **Description** **Big picture:** Improve the performance of Sculpt Mode brushes and tools. [Sculpt performance demo.mov](https://archive.blender.org/developer/F8920970/Sculpt_performance_demo.mov) **Use cases**: * Edit geometry surface detail in high poly meshes without performance issues **Design:** Remove all unnecessary calculations and updates from the PBVH when an editing operation is active, making all the Sculpt Mode code work only with the relevant vertices per brush step. The PBVH should only be used to get the affected area by the stroke as fast as possible. **Engineer plan:** * Get the PBVH code ready to have much smaller leaf node sizes * Store draw buffers in intermediate nodes to reduce the size of the leaf nodes of the PBVH. * Make proxies, bounding box and normal updates optional per tool and per symmetry options. * Do fast bounding box recalculations by updating the bounding boxes when deforming and propagating them from children to parents nodes to the root of the tree. * Implement optional fast normal updates (single loop) for brushes that require them. * Replace per node undo with a per vertex undo, which will also be used to get the original data during the stroke. * Remove BMesh based dyntopo (to be replaced with a better implementation). * Remove all loops over nodes from the code that runs when a stroke is active. * Configure the optimal settings of the scheduler per tool. * Make special tools (Pose, Boundary, Elastic Deform) not use the PBVH for getting the affected area. Cache the affected area of these tools once their data is initialized. **Work plan** **Milestone 1 - optional name** *Optimize PBVH queries and drawing* Time estimate: `2 - 3 weeks` **Milestone 2 - optional name** *Rewrite task scheduling and per vertex updates.* Time estimate: `3 - 4 weeks` --- **Relevant links**: * #68873 * #73934

Added subscribers: @PabloDobarro, @brecht, @Sergey, @JulienKaspar, @DanielBystedt

Added subscriber: @JulianPerez

Added subscriber: @Gilberto.R

wow

Added subscriber: @Russ1642

Added subscriber: @RobertoRoch

Added subscriber: @TheRedWaxPolice

Added subscriber: @Vyach

Added subscriber: @astroblitz

Added subscriber: @Ravenman13

Added subscriber: @dlc17

Added subscriber: @tiagoffcruz

Added subscriber: @SirPigeonz

Added subscriber: @Basie

Added subscriber: @Grady

Wow!

That difference is HUGE!

I'm hyped about this, can't wait to see it land in Blender.

Wow! That difference is HUGE! I'm hyped about this, can't wait to see it land in Blender.

Added subscriber: @vr_sebas

@Sergey @brecht I'm going to start making patches for master to try to get to milestone 1 as soon as possible. These are the most easy to make changes (they don't require refactor of a lot of code) and we can get quite some performance once they are done.
The idea for Milestone 1 is to reduce the size of the leaf nodes as much as possible. In order to do that, we need to solve two problems:

Move the batches to the middle of the tree (already done in the prototype)
Propagate the update flags (normals, bounding boxes, redraw, proxies...) from the leaf nodes to the root node to have faster partial updates.

We currently have a lot of places were we traverse the entire tree just to get to the leaf nodes and then we loop over the leaf nodes to check if they have a flag enabled (we do this multiple times per stroke step). When reducing the leaf nodes, this issue becomes a huge problem, even with the draw buffers in intermediate nodes as traversing the entire tree just to update the normals of a leaf node with 100 vertices is not great.
The first patches I'm going to make are going to be related to solving this issue. The performance improvement is not going to be noticeable until later (when reducing the size of the leafs), but I think this should be the first step.

@Sergey @brecht I'm going to start making patches for master to try to get to milestone 1 as soon as possible. These are the most easy to make changes (they don't require refactor of a lot of code) and we can get quite some performance once they are done. The idea for Milestone 1 is to reduce the size of the leaf nodes as much as possible. In order to do that, we need to solve two problems: - Move the batches to the middle of the tree (already done in the prototype) - Propagate the update flags (normals, bounding boxes, redraw, proxies...) from the leaf nodes to the root node to have faster partial updates. We currently have a lot of places were we traverse the entire tree just to get to the leaf nodes and then we loop over the leaf nodes to check if they have a flag enabled (we do this multiple times per stroke step). When reducing the leaf nodes, this issue becomes a huge problem, even with the draw buffers in intermediate nodes as traversing the entire tree just to update the normals of a leaf node with 100 vertices is not great. The first patches I'm going to make are going to be related to solving this issue. The performance improvement is not going to be noticeable until later (when reducing the size of the leafs), but I think this should be the first step.

Added subscriber: @Wesley-Rossi

Added subscriber: @FrancoisBasson

Added subscriber: @jmztn

Added subscriber: @JosephEagar

For the leaf nodes, how much smaller are we talking about? The dyntopo code had a pretty significant performance degradation from ->leaf_limit being left at 100. Like Pablo said, this is due to traversing the entire tree in order to get anything done (there are other performance degradations tied to multiple per-vertex uses of GHash, but leaf_limit being 100 was pretty significant in itself).

BTW, remember that splitting your memory into small chunks can be death to cache coherency. Here are a few relevant papers I found with a quick Google search:

http://datamove.imag.fr/bruno.raffin/papers/ID/tvcg10.pdf

For the leaf nodes, how much smaller are we talking about? The dyntopo code had a pretty significant performance degradation from ->leaf_limit being left at 100. Like Pablo said, this is due to traversing the entire tree in order to get anything done (there are other performance degradations tied to multiple per-vertex uses of GHash, but leaf_limit being 100 was pretty significant in itself). BTW, remember that splitting your memory into small chunks can be death to cache coherency. Here are a few relevant papers I found with a quick Google search: http://datamove.imag.fr/bruno.raffin/papers/ID/tvcg10.pdf

I guess 'enter' submits comments if you're not careful. Anyway, here are the other papers:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.108.6906&rep=rep1&type=pdf
https://dcgi.fel.cvut.cz/home/havran/ARTICLES/cgf2011.pdf

I guess 'enter' submits comments if you're not careful. Anyway, here are the other papers: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.108.6906&rep=rep1&type=pdf https://dcgi.fel.cvut.cz/home/havran/ARTICLES/cgf2011.pdf

@JosephEagar Hi! That is what I'm working on in this patch. https://developer.blender.org/D9029
We still don't know how small we can make the leaf nodes, but in order to do experiments with that (and fix some of the current performance issues), we first need to remove from the code all functions that traverse the entire tree to find a leaf node and do the updates (and there are a lot of those), and be able to store the draw buffers at any level in the tree.

For this project I was only considering meshes and Multires, and I was focusing more on having fast strokes with small radius (see https://developer.blender.org/D8983#221492) instead of making brushes that displace a big number of vertices faster. I would say that we want leaf nodes to be as small as possible to be able to discard as many vertices and have more localized updates, but we need to find a good balance.

@JosephEagar Hi! That is what I'm working on in this patch. https://developer.blender.org/D9029 We still don't know how small we can make the leaf nodes, but in order to do experiments with that (and fix some of the current performance issues), we first need to remove from the code all functions that traverse the entire tree to find a leaf node and do the updates (and there are a lot of those), and be able to store the draw buffers at any level in the tree. For this project I was only considering meshes and Multires, and I was focusing more on having fast strokes with small radius (see https://developer.blender.org/D8983#221492) instead of making brushes that displace a big number of vertices faster. I would say that we want leaf nodes to be as small as possible to be able to discard as many vertices and have more localized updates, but we need to find a good balance.

Added subscriber: @kouzanagi

Added subscriber: @Xury46

Added subscriber: @ThomasJohann

Added subscriber: @AngelNavarro

Added subscriber: @jpbouza-4

Added subscriber: @Beryesa

Added subscriber: @AdamJanz

Added subscriber: @ZackMercury-2

Added subscriber: @CarloSchat

Added subscriber: @LethalDumpster

Added subscriber: @ckohl_art

Added subscriber: @Canucklesandwich

Added subscriber: @AndyCuccaro

Added subscriber: @Sychuan

Added subscriber: @Low_Polygon42

Added subscriber: @Edvard-Svensson

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Sculpt Mode Performance #81180