Dynamic Topology doesn't create new topology for grab brush, and causes drastic slow down. #62718

{F6845548}System Information
Operating system: Ubuntu 18.04
Graphics card: Various: 2 x Nvidia 1080 Ti, and Nvidia GTX Titan X amongst them.

Blender Version
Broken: 2.79 Ubuntu stock, 2.79b and 2.80 from Thomas Schiex PPA

Short description of error

When in sculpt mode, if dynamic topology is enabled, the grab brush becomes extremely slow (on my wife's computer it takes 1-2 seconds to redraw the screen when she drags the mouse). On closer inspection, it seems that despite this huge slowdown, dynamic topology isn't actually creating any new topology. Reading the manual, it seems like the grab brush is not supposed to create new topology, in which case I wouldn't expect any performance difference between dynamic topology enabled vs disabled. Better yet might be to remove the dynamic topology option if the grab brush is selected.

Exact steps for others to reproduce the error
Based on the default startup or an attached .blend file (as simple as possible).

Download the attached .blend file, open it.
Attempt to use the grab brush (should already be selected) to extend the neck of the character downwards.
Note that no new topology is created, despite dynamic topology being enabled. Also note that performance is notably slower with dyntopo enabled (it's unusable on my wife's computer (1-2 seconds to redraw the screen), but manageable on mine (looks to be around 10-15 FPS), but in either case, much slower than with dynamic topology disabled.

Added subscriber: @j4m3z0r

Added subscriber: @WilliamReynish

First, what is '2.80 from Thomas Schiex PPA'? Please always test with official nightly builds. It's not clear which version of 2.8 you are using, but be sure to always test with the latest official builds.
The Grab tool doesn't create new geometry by design. Use the Snake Hook tool instead for that.
As for performance, I cannot reproduce that here. Tested on a quite weak laptop with integrated graphics and was able to use the Grab tool smoothly.

This is the "Thomas Schiex PPA": https://launchpad.net/~thomas-schiex/+archive/ubuntu/blender

Fair point on testing on official builds -- apologies for the noise. I just downloaded the official 2.79 binary from blender.org and was able to repro the issue there.

I'd argue that if Grab tool is not supposed to add geometry, then having the option to enable dynamic topology when the grab tool is selected is at least confusing, and it does seem to carry a significant performance penalty on the machines I'm testing on.

I've uploaded a video of the issue from my computer. This is on the 2.79 build from the blender.org website.

Screencast_03-19-2019_02:46:41 PM.webm

You can report bugs for the 2.8 beta. Just make sure you are testing the latest nightly official builds.

As for the Grab tool, this is how it's supposed to work by design. It could change, but this is how it's meant to be. The Dyntopo toggle applies globally to Sculpt mode, not to any specific tool, so it's always visible.

Ok, fair enough. Were you able to watch the video and see the performance degradation I observed? If dyntopo isn’t supposed to apply to the Grab brush, it seems like it shouldn’t be any slower. If it would help, I could repeat the above experiment on the official 2.8 build (the above was the official 2.79 build) and post a video of that. Let me know.

Yes, that's fine.

For better performance, try turning off the wireframe overlay.

I'm not sure I understand your comment "For better performance, try turning off the wireframe overlay" -- in the video above, wireframe is already disabled, isn't it? I also still don't understand why there is a performance difference with dyntopo on vs off if the grab brush doesn't actually create dynamic topology.

I've just downloaded 2.8-beta official build. I'll try that and upload a video if I get the same behavior with it.

Ok, here's a video showing the same behavior on Blender 2.8 beta with the official build from blender.org. Wireframe is disabled, but this doesn't seem to have any impact on performance.

Using Grab without dynamic topology is fast, as soon as dyntopo is enabled, the screen refreshes at a fraction of the speed.

Screencast_03-20-2019_11:55:02 AM.webm

Added subscriber: @YAFU

Hello.
It is not yet clear to me if the performance problem with Dyntopo happens mainly in Linux or in all operating systems.
https://developer.blender.org/T54807

Hi @YAFU, I just booted into Windows 10, downloaded blender 2.8 official packages and repeated the test there.

I still see a difference in performance between dyntopo enabled vs disabled on Windows. It is, however, much smaller than what I see on Linux: Linux sees performance drop to maybe 2-3 FPS, whereas Windows sees a drop to around 15 FPS.

However, I think this is beside the point: if the grab brush doesn't create any topology, why does toggling dyntopo on and off change the performance at all, on any operating system? Perhaps Linux is slower, but if dyntopo doesn't do anything for the grab brush, it should be the same amount of slower, regardless of dyntopo being enabled, right?

I really have no idea about how Dyntopo works and I do not know why Dyntopo is much slower compared to Dyntopo disabled in this case. I have found this answer and I am not sure if that could be the explanation:
https://blenderartists.org/t/sculpting-low-performance-but-low-cpu-usage/611229/2

Anyway as a Linux user, the comparison with Windows that you made makes me sad, it's a lot of difference.
I have tried with your file in Linux and I also get about 2 fps with your file while using Grab brush. i7-3770 CPU.

Added subscribers: @NicholasBishop, @ideasman42, @ErickNyanduKabongo

In #62718#645228, @j4m3z0r wrote:
Hi @YAFU, I just booted into Windows 10, downloaded blender 2.8 official packages and repeated the test there.

I still see a difference in performance between dyntopo enabled vs disabled on Windows. It is, however, much smaller than what I see on Linux: Linux sees performance drop to maybe 2-3 FPS, whereas Windows sees a drop to around 15 FPS.

However, I think this is beside the point: if the grab brush doesn't create any topology, why does toggling dyntopo on and off change the performance at all, on any operating system? Perhaps Linux is slower, but if dyntopo doesn't do anything for the grab brush, it should be the same amount of slower, regardless of dyntopo being enabled, right?

I will assume that you are a kind of new Blender user or a new dyntopo user. This is not a really "bug", this is known dyntopo limitation. Since @NicholasBishop had introduced dyntopo in Blender, we have been having performance problem. Some years ago @ideasman42 and @spy-fi had boost the performance a bit but dyntopo has never performance the same as multires. or basic sculpting.
I will advice to add detail only where needed when using dyntopo, and keep your model as low as possible. you can decimate your model and continue adding more details from the decimated one.
Here is me sculpting a head, note how heavy is my model at the end and compare to yours. -> https://youtu.be/Qt8McFQPOBE

I just installed Windows 7 to do the test. With today's 2.8 buildbot builds, Linux an Windows. Using this file:
Grab_dyntopo_2.8.blend
There is a clear difference in favor of Windows. You open the file and without zooming, you try to make a continuous stroke with Grab brush. In Windows there are a few jumps in the movement, but in Linux directly hangs for a few seconds without showing changes.
Has any developer been able to confirm this problem? Is there any open report about it? The previous report whose link I have shared above seems to have turned into an AMD CPU problem, but I have an intel i7-3770.
By the way, disabling dyntopo, the difference in performance is also in favor of Windows 7.

@ErickNyanduKabongo thanks for your note. Your assumptions are correct: I am a new blender user, and new to dynamic topology. However, I'm also a software engineer and have done some work on computer graphics (in the context of games).

Consequently, I appreciate that more geometry will involve greater computational complexity to manipulate, and that there exist tools to reduce the complexity of the model. I also understand that there is a performance delta between Windows and Linux.

However, none of those factors seem pertinent to the issue at hand.

The sole issue I'm trying to highlight here is this: when using the grab tool in sculpt mode, performance drops drastically when dynamic topology is enabled. For other sculpting tools this makes perfect sense, but quoting from above "The Grab tool doesn't create new geometry by design" (per @WilliamReynish), so I would not expect dyntopo to influence performance at all, in this specific case.

Reframing this: if dyntopo isn't intended to impact the behavior of the grab sculpting tool, shouldn't there be a branch somewhere in the code to wholly disable dyntopo (and eliminate its performance cost) if the grab sculpting tool is active?

Zooming out just a little more on this, whist it seems like a reasonable UI decision to make the grab tool available in sculpt mode (it is certainly more convenient than switching to edit mode and enabling proportional editing or similar), and for the grab tool to not create topology, I do think that surfacing the fact that dyntopo will not do anything in that mode would be helpful: it was surprising to me that no topology was created when dyntopo was enabled. Blender provides other warnings when topology won't be created (because of modifier configurations, for instance), this seems like an analogous case to me. However, I view this UI question secondary. Initially I'd just like to get closure on this question of the performance degradation.

This comment was removed by @j4m3z0r

Yes, you are right that it makes no intuitive sense why the Grab tool would be slower with Dyntopo enabled, given that the Grab tool doesn’t actually use dyntopo.

But, I suspect the technical issue could be because the Dyntopo feature organizes and processes the mesh in a different way that in turn has impact of all tools, even those that don’t add or remove geometry.

In conclusion, it would be great if it were faster. But, as of now I don’t think it is considered to be a bug.

@Sergey anything you want to add?

Added subscriber: @Sergey

@WilliamReynish could we not simply ignore the setting of the dyntopo flag if the user has selected the grab tool? Or is there some subtlety to this that I'm missing?

Added subscriber: @boemak

To be honest, there seems to be something fundamentally different between Windows and Linux in the performance department. Which is a shame, because I am just starting to like KDE. :)

Hi @boemak, I just added some notes to this ticket on the subject of Windows vs Linux performance, however*this// issue impacts both Linux and Windows builds.

Hi James, I saw those and they prompted me to update the case. Maybe Windows just hides the issue better?

Added subscriber: @mont29

Changed status from 'Open' to: 'Archived'

Fact that grab becomes slower when dyntopo is enabled is totally expected, dyntopo uses a much more complex set of data, and as already explained, dyntopo applies globally to a sculpt session, it's not related to which tool is being used.

Performances in general are always possible to improve, but think that report can be archived then, thanks.

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Dynamic Topology doesn't create new topology for grab brush, and causes drastic slow down. #62718