Page MenuHome

Paint line stroke - interpolation steps/aliasing
Closed, InvalidPublic

Description

System Information
Suse Leap 42.2
NVidia GTX 560ti (official drivers)

Blender Version
Broken: 2.78c
Worked: unknown

Short description of error
The paint line stroke doesn't properly interpolate, which causes regular steps/aliasing along the length - most noticeable on shallow angled lines.

Exact steps for others to reproduce the error

  • create a new 1024x1024 blank texture
  • switch to paint mode
  • set paint radius to 8px
  • set stroke method to line
  • draw a set of slightly angled lines

Details

Type
Bug

Event Timeline

I'm thinking this is normal with a low pixel width line.
I wouldn't think it would generate a scalable vector type file.
I'll let someone else decide though.

Paul R (intracube) added a comment.EditedSep 3 2017, 6:10 AM

I'm thinking this is normal with a low pixel width line.
I wouldn't think it would generate a scalable vector type file.
I'll let someone else decide though.

It's not an issue caused by the resolution or scale. Compare with GIMP's paint line tool:


Canvas resolution and zoom scaling are the same for both.

It looks as though Blender is actually drawing diagonal lines as a set of segmented horizontal (or vertical) lines.

A bit of a wild guess, but does the brush rendering code not allow sub-pixel placement? It would explain the stepping effect.

EDIT: Drawing in the 3d viewport gives clean results

Bastien Montagne (mont29) closed this task as Archived.Sep 5 2017, 1:00 PM
Bastien Montagne (mont29) claimed this task.

Thanks for the report, but that is no bug, rather feature/enhancement request. which are not accepted on this tracker.

Paul R (intracube) added a comment.EditedSep 6 2017, 6:25 PM

I can't see how this would be considered either a feature or enhancement.

There should be a baseline of functionality. For a program as established as Blender, it's reasonable to expect a line drawing tool to produce clean results without obvious jaggies/aliasing.

Right now, the line (and curve) tools give poor results in the 2d image editor.

Paul R (intracube) reopened this task as Open.Sep 6 2017, 6:26 PM

Some examples drawn in the 2d editor and 3d viewport:

This is no bug, period. Triaging tracker is heavy and annoying enough task not to have to do it twice.

The crux of this seems to be - "it's not a bug because the code works as intended, therefore it's a feature request" vs "the original design specification has a bug".

(It's possible to have a bug in a software design spec as well as final code)

If we can break this down to clarify:

What are the intended common uses for the paint tool's line and curve modes?
This seems self explanatory, the artist will use it to draw lines/strokes of varying thickness.

Is the tool is being used in an unusual way (corner case issue) for the aliasing to appear?
Drawing medium width lines with the standard in-built brush and most default values has to be one of the most common uses for the line and curve modes.

Is it reasonable to expect aliasing/stepping to this degree?
I don't think most artists would say so. It means the line/curve isn't usable in a significant number of cases.

I'd welcome some feedback on this, but please don't automatically close bugs without giving your reasoning. Certainly not within a few days as this means other people and devs don't have a chance to comment on it.

The issue is that the brush painting code in the image editor does not not work at a sub-pixel level. Supporting that would be good to improve quality, but it's a lot of work and for that reason out of the scope of what we handle in this bug tracker.

We can argue about the semantics of the word "bug", but it's not really about that, more about what we decide to give as a minimum support with limited resources, vs. what goes on the longer term to do list for which we can't promise anything.

The issue is that the brush painting code in the image editor does not not work at a sub-pixel level. Supporting that would be good to improve quality, but it's a lot of work and for that reason out of the scope of what we handle in this bug tracker.

We can argue about the semantics of the word "bug", but it's not really about that, more about what we decide to give as a minimum support with limited resources, vs. what goes on the longer term to do list for which we can't promise anything.

OK, thanks for confirming the cause. I still feel this is a notable issue with the painting tool, but I understand the limited resources.

Could this be transferred to the To Do section?