ofn-brush-strokes-on-path

[Krikor]

(05-08-2021, 07:16 PM)Ofnuts Wrote:

(05-08-2021, 06:32 PM)Krikor Wrote: It took me a while to understand how to choose values
for Strokes or Spacing (px) depending on the brush and path used. (the brush stroke at the origin of the stroke?).
But now that I am familiar with it, it seems quite satisfactory.

Depends what you want to do (what is called the "use case" in software development jargon). If you want to create dial marks, you likely want a known number of these. If you create rivets on the skin of an airplane, you likely know an approximate spacing and the script's main purpose is to compute the exact spacing required to have regularly space rivets.

My difficulty was with both cases of "use case" (I liked that term!); find the number of strokes and/or the number of spacing (py) to inform the plug-in.

Fortunately, with the use of ofn-path-edits.py (Path summary) and knowing the width of the brush I intend to use, I was able to obtain satisfactory results both to choose the number of strokes and the space (py).

But if the condition "the brush stroke at the origin of the stroke" is changed, I don't know if my method could still be working properly.

But it would just be a matter of readaptation.

[Krikor]

(05-08-2021, 10:55 PM)Krikor Wrote: My difficulty was with both cases of "use case" (I liked that term!); find the number of strokes and/or the number of spacing (py) to inform the plug-in.

It seems that the difficulty still persists, although nothing that would compromise the use of the plugin.

With an 8x1 brush, set the plugin to spacing = 8, to run on a rectilinear path of 2048px.
The result shows an occasional misalignment of the brush.

Not always using the same value of the brush width as spacing in the plug-in will give a gap-free stroke. In some cases not only do some gaps appear, but the height of the brush also changes (while staying within the proportion of the original Brush).

With strokes it is not always easy to find an ideal value, in some cases just one unit is enough to have the brush overlap or an opening between them. Case of the image below - 36 strokes and 35 strokes.

Even so, the visual perception of these occurrences is practically nonexistent without a good zoom of the image. And in cases where you want greater spacing between the strokes, I believe it is even less noticeable.

[Ofnuts]

Can reproduce,  but this isn't the script. When you stroke a path, the brush is centered on the path. If you path has integer coordinates, if falls "between the pixels" so the brush cannot paint fully colored pixels and it has to do approximations. A works around is to put your path anchors on the center of pixels.

But for this specific pattern, it would be much better to stroke in Line mode with a dash pattern, once for the yellow and once for the black.

[Krikor]

(05-11-2021, 08:40 AM)Ofnuts Wrote: Can reproduce,  but this isn't the script. When you stroke a path, the brush is centered on the path. If you path has integer coordinates, if falls "between the pixels" so the brush cannot paint fully colored pixels and it has to do approximations. A works around is to put your path anchors on the center of pixels.

But for this specific pattern, it would be much better to stroke in Line mode with a dash pattern, once for the yellow and once for the black.

I wouldn't know what it means to have "integer coordinates", I can only guess what that could mean.
The path used is a 2048px line, a multiple of the brush width.
In most experiments I used brushes whose widths were multiples of 128px (8; 16; 60; 128).

Oui, I could have achieved this result in different ways, but I wanted to do it using this plug-in.

In the attached .XCF there is a comparison of the result obtained using:
• Brush Stroke on path - 35 stroke;
• Edit - Stroke path (presented a change in the height of one of the strokes);
• Brush Stroke on path - 60 spacing;
• Follow Path with perspective brush;
• Ctrl + Shift Brush;
• Edit - Stroke path.

"A works around is to put your path anchors on the center of pixels." - I have no idea how that would be done. 

[Ofnuts]

(05-11-2021, 12:31 PM)Krikor Wrote: "A works around is to put your path anchors on the center of pixels." - I have no idea how that would be done 

Instead of have your anchor with Y=80, you set you anchor at Y=80.5 (or 79.5). Path anchors don't need to be on pixel boundaries.