Page MenuHome

Texture Paint 'Bleed' is angled along UV edges
Closed, ResolvedPublic


System Information
Windows 10
Nvidia GTX 970

Blender Version
Broken: 2.78a and 2.78c (tested on both of these)

Short description of error
When using the texture paint section of Blender, if the 'Bleed' setting is set to anything above 0, you will see that when painting along an edge of a UV in the 3D Texture Paint mode, the bleed works fine from the first vertex, but is angled towards the next vertex, meaning the bleed isn't consistent at all.

Exact steps for others to reproduce the error

  1. Start with default cube
  2. For quicker purposes, smart UV unwrap the cube with a margin (the error is with any unwrap)
  3. Move into Texture Paint mode
  4. Create a paint slot image texture of any size.
  5. Change the options, bleed setting to anything above 0. To see the bug clearly, use a large number like 8px
  6. Begin drawing along an edge of the cube.
  7. View the UV and texture in the 'UV/image editor' and zoom in, you will see the painted bleed is angled, and fading back to 0px bleed towards the edges of the vertices.

Event Timeline

I encountered the same problem, so I decided to add pictures

This is especially a problem when I need to paint around holes in UV.

Dalai Felinto (dfelinto) lowered the priority of this task from 90 to 30.May 22 2017, 2:28 PM

Please, as per the bug report guideline attach a file even if it's super simple.

Bastien Montagne (mont29) changed the task status from Unknown Status to Archived.May 29 2017, 9:55 AM
Bastien Montagne (mont29) claimed this task.

More than a week without reply. Due to the policy of the tracker archiving for until required info/data are provided.

I've prepared required scene:

Things to notice from this test scene:

Bastien Montagne (mont29) changed the task status from Archived to Unknown Status.May 29 2017, 12:31 PM
Bastien Montagne (mont29) removed Bastien Montagne (mont29) as the assignee of this task.
Bastien Montagne (mont29) raised the priority of this task from 30 to Normal.

Thanks, reopening then.

Any update? This is pretty detrimental to my workflow and a lot of artists i know, haven't seen any changes in 5 months

It's not a bug but the behavior of the feature is a bit cheap.
The way it extends the pixels is as shown in this image (according to my experiments) :

Even with quads, it extends around the hidden triangles with the same method, which explains the non parallelism with the edges. Of course the edge inside the quad (the diagonal) doesn't get extended, as don't all the edges inside a UV island.
You can see it more clearly on these 2 examples (I added yellow lines to show the hidden triangles) :

The big question is : is this method the only possible one to allow fast enough responsiveness or can a better one be developed and work in real-time ?

Since this feature came out in 2.49 I'm guessing the modern computers can handle a better method.

What do you think b3d devs ?

I assigned you because you were assigned to this one It may be the same issue but I'd like to know if you have an answer to my question above.

more information:

System Information
Linux Manjaro 64-bit
GeForce GT 640

Blender Version
Broken: 2.79 RC1 down to 2.76
Worked: 2.75a and previous versions

Short description of error

Up until 2.75a, the texture brush bleed performed on quads using the bisectors of the quads :

but since 2.76 up until 2.79 RC1, it performs on the triangles that compose the quads :

this brought undesirable results such as an uneven thickness of the bleeding :

increasing the bleed value is not a good way to counteract this problem since it increases the chances of bleeding into another UV island or bleeding inside the very island we're painting in, as shown by the white arrows here (a texture stencil was used in the brush to make it visible everywhere) :

Exact steps for others to reproduce the error:

  1. in 2.75a open this file and click on the cube to fill it with paint with the fill brush
  2. observe the image
  3. do the same in any later version
Bastien Montagne (mont29) triaged this task as 50 priority.

No point in keeping twice the same report open…

Also, @ChameleonScales (Caetano), please avoid doing triaging tasks yourself unless you know what you are doing, @Antonis Ryakiotakis (psy-fi) is not currently active and doubt he will handle bug reports currently!


Any news about this ? This functionality is useless this way, which is catastrophic when you need to paint a mask (ex : before exporting to Unreal Engine)

Hi there—I wanted to let you know I took at a look at this bug. I ran into this issue originally when going through the blender cloud game asset tutorials. There are a couple things going on here in the latest blender. I was able to fix one miscalculation for tris but ran into a blocker with quads.

I believe the source of this bug is from the change to move to tri-data only within source/blender/editors/sculpt_paint/paint_image_proj.c. Specifically, this diff from @Campbell Barton (campbellbarton).

For the miscalculation with tris: it appears the bleed calculation was incorrectly using the edge normal with an edge rather than using a point normal. You can compare the difference with the patch and blend file provided here. Both are set to a bleed of 16px.

Note that I fixed the "sawtooth" and corrected the bleed amount by fixing the normal calculation. Unfortuantely, there is still tri overextension for quads as you can see with the following screenshots.

After this change I realized it seems impossible to calculate the proper bleed for quads with tri-data alone. It seems like the bleed calculation is just different for quads and tri. Unfortunately with the change made from that diff we no longer have the quad info. I'm hoping for context for the change but I fear to fix this will require a revert back to using special cases for quads or else find another way to calculate bleed. My guess is that this was a refactor. Thanks for looking at this, and hopefully this helps!

I don't know if this it's related with this kind of errors:

Any news about this? :(

@ChameleonScales (Caetano) Thanks! Any idea if this is going to be solved for 2.8?