brush lag in texture painting #58465

New Issue

System Information
Operating system: Windows 10
Graphics card: GTX 1080Ti

Blender Version
Broken:
2.80 0f5b53ba4d

Short description of error
When painting textures in 3D viewport brush lags very much, so that it is not even possible to draw a circle. In Texture editor it works fine.

Exact steps for others to reproduce the error
The same issue with any mesh. Does not matter how many polygons. increased brush spacing also does not help. Painting_Lag.mp4
Attaching short video with this issue.

**System Information** Operating system: Windows 10 Graphics card: GTX 1080Ti **Blender Version** Broken: 2.80 0f5b53ba4dc **Short description of error** When painting textures in 3D viewport brush lags very much, so that it is not even possible to draw a circle. In Texture editor it works fine. **Exact steps for others to reproduce the error** The same issue with any mesh. Does not matter how many polygons. increased brush spacing also does not help. [Painting_Lag.mp4](https://archive.blender.org/developer/F5782132/Painting_Lag.mp4) Attaching short video with this issue.

Added subscriber: @SarunasAtkocaitis

#62227 was marked as duplicate of this issue

#60965 was marked as duplicate of this issue

#60155 was marked as duplicate of this issue

I also noticed, that if the brush size is much smaller, then the issue disappears, or even with larger brush the lag is not so bad. the worst lag is with medium size brush..

Added subscriber: @ZedDB

I get this as well. I wouldn't think that the projection calculation of the brush in 3D space onto a plane would be this slow.

Added subscriber: @TheX

Added subscriber: @brecht

I'm not seeing any poor performance, please attach a .blend file so we're sure to be testing the same setup?

It might also be a threading issue, try changing Render > Performance > Threads to 1 or other values to see if it makes a difference.

Projection painting code is very different than our 2D painting code, the bottleneck here may not be in the 3D viewport, so not necessarily an issue for @fclem.

I'm not seeing any poor performance, please attach a .blend file so we're sure to be testing the same setup? It might also be a threading issue, try changing Render > Performance > Threads to 1 or other values to see if it makes a difference. Projection painting code is very different than our 2D painting code, the bottleneck here may not be in the 3D viewport, so not necessarily an issue for @fclem.

For me it happens with any blend file (just tested again with latest builds). I have also tested it on few different PCs (one pc with amd ryzen 1700 CPU/GTX 1080Ti and another with amd ryzen 2700x/GTX 1080Ti)
Blender 2.79 has also the same issue for me.
Sorry, but I could not find (Render > Performance > Threads to 1) option.

For me it happens with any blend file (just tested again with latest builds). I have also tested it on few different PCs (one pc with amd ryzen 1700 CPU/GTX 1080Ti and another with amd ryzen 2700x/GTX 1080Ti) Blender 2.79 has also the same issue for me. Sorry, but I could not find (Render > Performance > Threads to 1) option.

@SarunasAtkocaitis you have to switch to cycles for that option to be visible.

Here is a simple test file:
paint_test.blend

@brecht ah, I see. I guess I was too hasty with the assign then. How should we assign this to (if any)?
If I set the threads to 1, the issue becomes even more apparent. If I try to draw in a circle, the 2D painting code is able to keep up quite well, but the 3D viewport seems to struggle quite a bit.
Do you know if we handle the poll rate of the mouse differently in the 2D viewport than in the 3D viewport?

@SarunasAtkocaitis you have to switch to cycles for that option to be visible. Here is a simple test file: [paint_test.blend](https://archive.blender.org/developer/F6188573/paint_test.blend) @brecht ah, I see. I guess I was too hasty with the assign then. How should we assign this to (if any)? If I set the threads to 1, the issue becomes even more apparent. If I try to draw in a circle, the 2D painting code is able to keep up quite well, but the 3D viewport seems to struggle quite a bit. Do you know if we handle the poll rate of the mouse differently in the 2D viewport than in the 3D viewport?

@ZedDB
Thanks for adivice.
I have switched threads to 1 and it actually fixed the issue it draws without the lag, but if I put anything else then 1 to the thread count it starts lagging again.

@ZedDB Thanks for adivice. I have switched threads to 1 and it actually fixed the issue it draws without the lag, but if I put anything else then 1 to the thread count it starts lagging again.

@SarunasAtkocaitis interesting, I guess it might just be that I have a really crappy CPU (AMD bulldozer) that I get other results. (Or could also be different under Linux than in Windows)

Added subscriber: @stevewarner

I can confirm as well that setting rendering threads to 1 resolves the issue but setting rendering threads to anything above 1 causes problems.

Added subscriber: @OscarFranco

I can't find the thread option and I'm having performance problems in the viewport when trying to paint, to the point it's difficult to even make a line.
I have no problem when painting on the Image editor, it behaves smoothly.

Win10 64b
Geforce GTX 1060 3GB
blender-2.80-18e5540a48b6-win64

I can't find the thread option and I'm having performance problems in the viewport when trying to paint, to the point it's difficult to even make a line. I have no problem when painting on the Image editor, it behaves smoothly. Win10 64b Geforce GTX 1060 3GB blender-2.80-18e5540a48b6-win64

Added subscriber: @Parabox

Added subscriber: @fclem

Removed subscriber: @fclem

The Thread option will only be visible if you're using Cycles as your renderer. So switch your rendering engine and you'll be able to reduce your threads. After that, you can switch back to Eevee and it should work fine.

Hi, I used 1 thread in the performance options and the stroke is a lot smoother but still persist a little lag, also this happens in sculpt mode. I used a subdivided cube for the test (No Dyntopo) and this is the result

Hi, I used 1 thread in the performance options and the stroke is a lot smoother but still persist a little lag, also this happens in sculpt mode. I used a subdivided cube for the test (No Dyntopo) and this is the result ![Untitled.png](https://archive.blender.org/developer/F6780531/Untitled.png)

Added subscriber: @WilliamReynish

Cannot reproduce this issue on macOS, even on a low specced laptop. What resolution is your texture?

texpaint_macos.mov

Cannot reproduce this issue on macOS, even on a low specced laptop. What resolution is your texture? [texpaint_macos.mov](https://archive.blender.org/developer/F6780558/texpaint_macos.mov)

Added subscriber: @antoniov

I have tested in a very new PC with Windows 10:

Intel i9 16 threads
32 GB Ram
RTX2080 TI

I get lag painting textures in a simple cube, and I think the PC is able to run a very heavy work, so it looks there are some bottleneck.

@brecht I could run a Visual Studio performace profiler session to find where is the time used.

I have tested in a very new PC with Windows 10: Intel i9 16 threads 32 GB Ram RTX2080 TI I get lag painting textures in a simple cube, and I think the PC is able to run a very heavy work, so it looks there are some bottleneck. @brecht I could run a Visual Studio performace profiler session to find where is the time used.

Hi, I can confirm that the performance improves a lot by setting the threads to 1.

Here the result in VS2017. I hope this help you.

Here the result in VS2017. I hope this help you. ![image.png](https://archive.blender.org/developer/F6780624/image.png)

![image.png](https://archive.blender.org/developer/F6780632/image.png)

![image.png](https://archive.blender.org/developer/F6780641/image.png)

Added subscriber: @Jeroen-Bakker

This seems to be a duplicate of {#51133}?

@Jeroen-Bakker Yes, it's duplicated...you can merge it.

Closed as duplicate of #51133

Added subscriber: @TheBlenderWorrior

a few tips to better the performance
Set Threads to 1
turn off (Disable) modifiers while painting, (If you need them back just turn them on and try to set their values as low as possible while painting, but again turning them off or disabling gives you the best, )
If its still laggy, try paiting click by click, hold the mouse for a sec while clicked once, if you move the mouse the brush will keep painting even while lagging, and thats why sometimes it lags even more than you expected

a few tips to better the performance Set Threads to 1 turn off (Disable) modifiers while painting, (If you need them back just turn them on and try to set their values as low as possible while painting, but again turning them off or disabling gives you the best, ) If its still laggy, try paiting click by click, hold the mouse for a sec while clicked once, if you move the mouse the brush will keep painting even while lagging, and thats why sometimes it lags even more than you expected

Added subscriber: @UrbenLegend

I am still getting this issue with Blender 2.81a. Texture painting lags when using large-radius brushes or when painting onto large textures (> 2048). I tried setting Threads to 1 but that made no difference for me.

My issue is a bit different from the original. Performance is worse when painting in the Image Editor instead of the 3D viewport. I wouldn't mind the lag if it didn't also interfere with the input, but it's causing what should be perfectly curved lines to look like they're instead made up of smaller straight lines.

I am still getting this issue with Blender 2.81a. Texture painting lags when using large-radius brushes or when painting onto large textures (> 2048). I tried setting Threads to 1 but that made no difference for me. My issue is a bit different from the original. Performance is worse when painting in the Image Editor instead of the 3D viewport. I wouldn't mind the lag if it didn't also interfere with the input, but it's causing what should be perfectly curved lines to look like they're instead made up of smaller straight lines.

Added subscriber: @zincr0

This also happens in linux, tested with ubuntu 18.

However, with small brushes increasing the threads does improve the performance, also, the default brush stroke in 2.81a is "Space", a very "laggy" brush compared with the "Dots" stroke for the new users.

This also happens in linux, tested with ubuntu 18. However, with small brushes increasing the threads does improve the performance, also, the default brush stroke in 2.81a is "Space", a very "laggy" brush compared with the "Dots" stroke for the new users.

Added subscriber: @jesaro

This problem still happens in blender 2.82, and 2.90 alpha, i'm trying looking for a solution but i can't find anything,

Added subscriber: @KidTempo

This problem seems to be continuing in 2.90 alpha. In my case changing threads, brush size, or any of the other advice did not work. Lag started a few hours ago and has gotten progressively worse with each stroke to the point where Blender is not responsive for several seconds each time I make a stroke in the viewport. Memory usage is not abnormal, and I can still paint in the image editor without problem.

Added subscriber: @Supertanker13

For me, the lag happens when painting over areas where there is backwards-facing geometry under it (trying to paint fingers are a great pathological case), and worsens depending on how many surfaces (backwards or forwards) are stacked under the mouse pointer area. Blender will stop responding to the point where Windows will gray out the screen and consider the app non-responsive.

I did some informal testing:

It happens on a similarly-spec'd Ubuntu 18.04 LTS machine, so this is not a Windows-specific issue.
Blender appears CPU bound when waiting; I locked the affinity to one core and then watched it peg the core at 100% for almost a minute waiting to respond--about the same amount of time it takes when allowing it to have multiple cores. When affinity is loosened and Blender is not responding, Blender uses ~30% CPU on my 8-virtual-core machine without pegging a particular core.
Thread adjustments did not help.
RAM usage is normal

What info can I track down to help? Is there a way to see what hotspots Blender is stuck on when it's in this state via debugger or profiler?

Tested versions: 2.82, 2.83 LTS

Tested machines:
Xeon E3 1276 V3
32GB RAM
nVidia GTX 1070
Windows 10

i7-3770k
24GB RAM
nVidia GTX 1070
Ubuntu 18.04 LTS

For me, the lag happens when painting over areas where there is backwards-facing geometry under it (trying to paint fingers are a great pathological case), and worsens depending on how many surfaces (backwards or forwards) are stacked under the mouse pointer area. Blender will stop responding to the point where Windows will gray out the screen and consider the app non-responsive. I did some informal testing: 1. It happens on a similarly-spec'd Ubuntu 18.04 LTS machine, so this is not a Windows-specific issue. 2. Blender appears **CPU bound** when waiting; I locked the affinity to one core and then watched it peg the core at 100% for almost a minute waiting to respond--about the same amount of time it takes when allowing it to have multiple cores. When affinity is loosened and Blender is not responding, Blender uses ~30% CPU on my 8-virtual-core machine without pegging a particular core. 3. Thread adjustments did not help. 4. RAM usage is normal What info can I track down to help? Is there a way to see what hotspots Blender is stuck on when it's in this state via debugger or profiler? Tested versions: 2.82, 2.83 LTS Tested machines: Xeon E3 1276 V3 32GB RAM nVidia GTX 1070 Windows 10 i7-3770k 24GB RAM nVidia GTX 1070 Ubuntu 18.04 LTS

Added subscriber: @MarkusKruse

Added subscriber: @kouzanagi

HI,

It's laggy in 2.83 it's worse in 2.90 thread adjustments did not help.

intel xeon w3690
Nvidia GTX 1080

HI, It's laggy in 2.83 it's worse in 2.90 thread adjustments did not help. intel xeon w3690 Nvidia GTX 1080

Added subscriber: @pauanyu_blender

Added subscriber: @moisessalvador

Here's my proposal on how to improve the performance as well as brush behavior, which was already bad before 2.9. https://blender.community/c/rightclickselect/hncbbc/ Basically, it's about having the option for the brush falloff to be just a sphere instead of a projected 2d tube, in line with the other brushes. The projected tube paints all accros, and this forces the user to use Occlude, which is what kills the performance.

Added subscriber: @RomanW

Hello,
I also had the same problem, my brush was lagging in texture paint, both in EEVEE and Cycles.
Though I fond a solution that works for me which is to use orthographic mode only.
Modifying the number of threads for render didn't work for me.

I'm running Blender on a Windows 7 64 bits PC, with an Intel core i5, 16go RAM, NVIDIA GeForce GTX 970

Hello, I also had the same problem, my brush was lagging in texture paint, both in EEVEE and Cycles. Though I fond **a solution that works for me** which is to use orthographic mode only. Modifying the number of threads for render didn't work for me. *I'm running Blender on a Windows 7 64 bits PC, with an Intel core i5, 16go RAM, NVIDIA GeForce GTX 970*

Added subscriber: @skarkkai

Added subscriber: @Eevee-1

This comment was removed by @Eevee-1

*This comment was removed by @Eevee-1*

Added subscriber: @Lupus_Dei

Hello team, I had the same issue with Blender 2.93 (Linux Manjaro, Ryzen 9, 16 gb ram, rtx 2060)
I got the texture painting working by changing the stroke from Space to Airbrush under Brush settings->Stroke->Stroke Method.
Rate .01
JItter 0 (Select the JItter pressure option if you have a tablet)
JItter unit to Brush.

Hope this can fix the issues of some of you.

Hello team, I had the same issue with Blender 2.93 (Linux Manjaro, Ryzen 9, 16 gb ram, rtx 2060) I got the texture painting working by changing the stroke from Space to Airbrush under Brush settings->Stroke->Stroke Method. Rate .01 JItter 0 (Select the JItter pressure option if you have a tablet) JItter unit to Brush. Hope this can fix the issues of some of you.

Added subscriber: @WOAS

Operating system: Windows-10-10.0.19044-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1060 3GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 511.79
Blender: version: 3.0.0, branch: master, commit date: 2021-12-02 18:35, hash: `rBf1cca3055776`

Still getting very bad performance in 3.0.0 specifically when doing either very big radius strokes or moderately fast strokes. Render Properties>Performance>Threads>1 didn't change anything

``` Operating system: Windows-10-10.0.19044-SP0 64 Bits Graphics card: NVIDIA GeForce GTX 1060 3GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 511.79 Blender: version: 3.0.0, branch: master, commit date: 2021-12-02 18:35, hash: `rBf1cca3055776` ``` Still getting very bad performance in 3.0.0 **specifically** when doing either very big radius strokes or moderately fast strokes. Render Properties>Performance>Threads>1 didn't change anything

Added subscriber: @Karolina-Gasiorowska

same for me in 3.2.0. changing the threads didn't help either, tried most recommendations people suggested here but nothing really made a difference.

( Windows 10 Education 10.0.19042, Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz, 3600 Mhz, 8 Core(s), 8 Logical Processor(s), NVIDIA GeForce RTX 2070, 64GB RAM).

same for me in 3.2.0. changing the threads didn't help either, tried most recommendations people suggested here but nothing really made a difference. ( Windows 10 Education 10.0.19042, Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz, 3600 Mhz, 8 Core(s), 8 Logical Processor(s), NVIDIA GeForce RTX 2070, 64GB RAM).

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

brush lag in texture painting #58465